All Activity

Hi Slim, The date is wrong and nobody has edited anything. We are part-way through moving the blog to a new platform. The page you landed on is the new one and it is not finished: the original publish dates have not come across yet, so every post on it is showing 21 October 2026. That is why you saw so many sharing the same day. The live blog is still blog.whmcs.com, and the dates there are correct. On the part that matters, whether that security alert is current: it is not. It is from 8 March 2024. It was never about the WHMCS software itself, it concerned three third-party vendors and their extensions and themes. Here it is with its real date on it: https://blog.whmcs.com/133747/security-alert An unfinished page presenting a two year old security post as last week's news is not something to leave reachable, particularly this week. I have put it to the team today to either get the dates right or take that page down until the migration is finished. Thanks for calling it out.

Thank you!, if you have a bug tracker number, please send to me, I will personally take a look at it, I am very keen to get WHMCS 100% compliant for the markets that require it.

Your maths checks out. 520.00 x 0.0476752 = 24.7911, Stripe rounds that to 24.79 EUR, and 24.79 / 0.0476752 gives exactly the 519.98 you're seeing, so the recorded amount looks like it's being rebuilt from the rounded settlement figure rather than taken from the charge itself. A few things I'd do to pin it down and stop it piling up: 1. Check Billing > Gateway Log for that payment. It shows the data the module actually received and processed, so you can see whether the amount it recorded came from the charge or from the balance transaction (the settlement side). That's the evidence WHMCS support will want. 2. Open a ticket with WHMCS and include the invoice ID, the Stripe PaymentIntent ID, the gateway log entry and your example above. Since the charge currency equals the invoice currency, the expected behaviour is to record the gross charge (520.00) and only convert the fee, so it's worth getting it logged as a bug against 9.1.0 rather than waiting for a hotfix to appear. 3. If your Stripe account supports it, add an MXN settlement currency (a payout bank account in MXN). When the charge and settlement currencies match, there's no conversion round trip, so the recorded amount and fee come through without the rounding drift. Availability depends on your Stripe account country, so check Settings > Payouts in Stripe. 4. To find the ones already affected, filter Billing > Transactions List by the Stripe gateway since your switch date and compare against invoice totals, or run a quick query on tblaccounts joined to tblinvoices for Stripe payments where amountin differs from the invoice total by less than 1. The small leftover balances can be cleared by adding a manual payment for the difference or crediting it, so the invoices stop sitting as Unpaid or triggering overdue reminders. Also keep in mind that the fee being converted back the same way means your fee reporting in MXN is slightly off too, which matters if you reconcile against Stripe payouts in EUR.

Can someone clarify if this is current or has someone jiggered with the post dates on your blog.? https://www.whmcs.com/blog/security-alert/ - dated 21st Oct 2026. The dates on the blog appear to have quote a few n the 21st - so I would guess someone has stuffed the dates - these should be corrected asap. if this particular security incident is current, we need to know.

That's good to hear at least 🙂

Ive just upgraded from 8.13.7 -> 9.1 on two sites. The immutability issue still needs work - Ive filed one bug report already. However, with it off, WHMCS seems to be as solid as 8.13.7.

Hi everyone, After switching from the legacy Stripe module to Stripe Dynamic Payments, we started noticing small differences between the amount customers actually pay and the payment amount recorded in WHMCS. This did not happen with the previous module. Environment: WHMCS 9.1.0 PHP 8.4 Official Stripe Dynamic Payments module “Convert To For Processing” set to “None” Stripe settlement currency: EUR Here is one example: Invoice total: 520.00 MXN Amount successfully charged in Stripe: 520.00 MXN Stripe exchange rate: 1 MXN = 0.0476752 EUR Gross settlement amount in Stripe: 24.79 EUR Payment amount recorded in WHMCS: 519.98 MXN Transaction fee recorded in WHMCS: 32.09 MXN (1.53 EUR in Stripe) The discrepancy can be reproduced by converting the rounded EUR settlement amount back to MXN: 24.79 / 0.0476752 = 519.976843… → 519.98 MXN The fee calculation matches too: 1.53 / 0.0476752 = 32.092156… → 32.09 MXN This suggests that the module may be reconstructing the payment amount from the rounded settlement amount instead of using the original amount charged in the invoice currency. However, we have not confirmed this in the module’s implementation. In this particular example, the invoice shows as Paid with a zero balance, despite the ledger recording 519.98 MXN against a 520.00 MXN invoice. We have also noticed small outstanding balances on other payments since switching modules. Has anyone experienced this with Stripe Dynamic Payments? Is this a known issue, and is there a hotfix or configuration change to prevent it? When the charge currency matches the invoice currency, should WHMCS record the original gross charge amount and convert only the transaction fee? We would prefer to keep Dynamic Payments enabled, so any guidance would be appreciated.

Ola Miguel 👋

I hear you all, and on this one I'm going to take a step back and give a bit more time. 8.13 support is extended to 31 December 2026. The docs will be updated, and the notice goes out by email to everyone early next week. After that date our focus is fully on 9.x, so please plan your upgrades around it. @DennisHermannsen please send me the EU invoicing issues you found, I want to make sure they're looked at.

As @DennisHermannsen mentioned, I didn't even know about this until I checked the documentation for EOL updates. When I saw the updated timeline, I honestly thought it was a typo. I would have expected at least 90 days' notice for an update of this size. Please kindly reconsider. Thanks.

I don't think that's the entire reason. Version 9.0 was forced into GA way quicker than any version and it was full of bugs. I appreciated WHMCS decision to extend support for version 8.13 indefintely. We tried running v9.0 on a dev installation but even without any customization, we had a lot of issues. Stuff that were outright illegal and stuff that broke invoicing for EU business. We don't appreciate being given only 1 month of warning - and I'm generous when I say we were given a warning. The only reason I know support for v8.13 ends in ~1 month is because I check the docs regularly. There is no way we can make sure we're running v9 in 1 month. Usually, we're pretty quick to upgrade, but the fact that v9 was originally shipped with so many issues is concerning - so we need a lot of time making sure everything is working correctly; not just customizations, but also invoicing.

Hi The email to notify everyone is about to be sent out, it's currently with the GTM team to go out The main downfall of keep using 8.13.x is of course security updates, we did a major security focus earlier in the year so we have launched quite a lengthy amount of updates over the past few months Carlos

@WHMCS Carlos I appreciate the extension to keep 8.13.x going because IMO it's the most stable of the actively supported versions. Being given 1 month to upgrade DURING the start of the busy Holiday season and End of Year is not easy at all. Aside for no more bug fixes or security updates, what's the downfall to continuing to use v8.13.x ? Where was the email to alert your users? Everyone is different and I can't imagine all of your users constantly check the Documentation or the Forums.

Hi everyone, We emailed licence holders about this on 21 October, the day PHP shipped the fixes, and again on 28 October. The full write-up went on the blog today. The forum is the last place I can put it in front of you, so here it is again. On 21 October PHP fixed two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619. Both can allow unauthenticated remote code execution. They are in PHP itself, not in WHMCS code, which is why there is no WHMCS patch for them. That last part is the bit I want to be careful about. "No WHMCS patch needed" does not mean nothing to do. If your server is running an unpatched PHP, your WHMCS install is sitting on it. Three things, in order: Check what PHP you are actually on. Utilities > System > PHP Info. Then check that your WHMCS cron runs on the same PHP version as the web server. On a lot of installs it does not, and the cron one gets forgotten. Update PHP. Fixed in 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Restart PHP-FPM or Apache afterwards, then go back to PHP Info and confirm it took. If you are on 8.1 or older there is no upstream release, so you need a patched package from your host or your distribution. If someone else runs your server, ask them to confirm they have done it. Do not assume. Update WHMCS. This does not fix the PHP flaws, nothing in WHMCS can. It fixes separate WHMCS security issues, which is its own reason to do it. Current releases are 9.1.0, 9.0.9 and 8.13.7. 8.12 and earlier are end of life and are not getting security fixes. WHMCS Cloud customers: we patched this automatically, with no downtime. Nothing for you to do. If you genuinely cannot patch today, set session.upload_progress.enabled=0 in php.ini or your FPM pool and restart every worker. ini_set() and .user.ini do not count here. On 23 October PHP published a related issue, CVE-2026-115560, and the guidance is to leave that setting off until the next bugfix release even once you are patched. The full write-up, including which PHP versions each WHMCS release supports and the rest of the mitigations, is here: https://blog.whmcs.com/133799/php-cve-2026-109618-and-cve-2026-109619-our-response-and-what-whmcs-customers-need-to-do If something specific is blocking you from patching, open a ticket, or reply here and I will pick it up. Carlos

Well, not keeping me on 8.13, but yeah, that forced marketplace account notion should be removed from *all* versions.

Your slowlog pretty much tells the story. With Dynamic Field Translations on, every product field read goes through DynamicTranslation, which loads the stored translations and runs them through HTMLPurifier. A duplicate copies a lot of translatable fields (name, description, configurable options, custom fields), and from that trace it looks like it purifies the same translated HTML over and over. With long HTML descriptions or several languages that easily runs past 300 seconds. Since the same action takes seconds with the setting off, it's a core issue, not something in your Nginx or FPM config. What I'd do while you wait for a fix: 1. Workaround: switch Dynamic Field Translations off under Localisation, duplicate the product, then switch it back on. The translations live in the database (tbldynamic_translations), so turning the setting off doesn't delete them, it just stops WHMCS reading them. Afterwards, check whether the new product picked up the translated name and description. If it didn't, add them on the copy by hand. 2. See how big the translation data is. Run SELECT COUNT(*) FROM tbldynamic_translations; and look at the size of the longest translation values. If you find thousands of rows, or descriptions with big pasted HTML (inline styles, base64 images), that's what HTMLPurifier is choking on. Cleaning up that HTML in the base language and the translations can bring the time down a lot. Take a DB backup before touching that table. 3. If you want to confirm it's slow rather than stuck, raise request_terminate_timeout in the pool and fastcgi_read_timeout in Nginx to something like 900 for one test run. If it eventually finishes, you know it's the per-field purification cost and not a loop. 4. Open a ticket with WHMCS support and attach that slowlog trace plus the two timings (more than 300s with the setting on, a few seconds with it off). That's an easy reproduction for them, and it's the only way it ends up in a maintenance release.

Hi Dennis, and everyone following this thread. The date did not come out of nowhere, so let me give you the history, and then the part we genuinely got wrong. 8.13 went GA on 7 May 2025. Our published Long Term Support policy gives a minor version Important and Critical updates for one year, and 8.13's end of life was listed on docs.whmcs.com as 31 May 2026. We did not hold that date. Customers asked us to keep 8.13 alive, and the reason behind almost every request was 9.0 making invoice immutability and credit notes mandatory, with no way to turn them off if you run cash-basis accounting or manage credit notes in a third-party system. That was a fair objection. Everyone who asked was given the same answer: we would hold 8.13 until 9.1, because 9.1 was where the fix was going. That is what we did. 8.13 has had around 18 months of support instead of the 12 the policy sets out. 9.1 shipped on 20 October and carries that fix. Invoice immutability is now a three-state control at General Settings > Invoices: - Full compliance: immutability enforced, billing notes generated. This is the default. - Immutability disabled, billing notes still generated. - Immutability disabled and billing note generation turned off entirely. The third state puts you back on the pre-9.0 behaviour, and it applies to the API as well as the admin area. So 1 December is us doing what we said we would do, on the release we said we would do it on, and I am holding it. I cannot run two release trains indefinitely: every fix has to be made on the oldest supported branch and carried forward, and that time comes straight out of the 9.x work this thread is really asking for. Where we did fail you is in telling everyone. The people who asked for the extension were told the terms. Everyone else got "TBD" sitting on a page for six months and then a date appearing with no announcement in front of it. If you were not one of the people in those conversations, your reading of this is entirely reasonable, and that is on us. So, one commitment. No more TBD. Every supported version carries a real end of life date on the documentation page, and if we change one you will hear it from us here, with the reason, rather than finding it in a page diff. The TBD is what turned a decision we made in April into a surprise in October, and that is the part I am fixing. One practical note if you upgrade: check General Settings > Invoices first. The setting does not guess what you want. If something else in 9.0 or 9.1 is keeping you on 8.13, message me here directly and I will look at it. Carlos

/images/whmcs_blog.png On October 21, 2026, the PHP project released security updates for two critical vulnerabilities: CVE-2026-109618 and CVE-2026-109619. According to PHP, both vulnerabilities can allow unauthenticated remote code execution. This means an attacker could run code on a vulnerable server without logging in. Because WHMCS runs on PHP, these vulnerabilities may affect your WHMCS installation. The vulnerabilities are in PHP, not in the WHMCS code itself. In this post, we'll go over what the...View the full blog post

Yes, we have the same problem there, invoices with a promo code are still being charged the full price. (WHMCS 9.0.8)

Following the general availability of WHMCS 9.1, we've continued releasing compatibility updates across our modules. Proxmox VE VPS & Cloud For WHMCS 4.4.2 now supports WHMCS 9.1 Stable and PHP 8.4. An updated Proxmox Proxy version is also available for customers using that component. More Modules Ready for WHMCS 9.1 Our latest compatibility updates also include: cPanel Extended For WHMCSPassword Manager For WHMCScPanel Manage2 For WHMCSServer Allocator For WHMCSClient Area Designer For WHMCSSocial Media Login For WHMCSLogin-Free Payments For WHMCS Additional modules are being updated and tested. Planning Your WHMCS 9.1 Upgrade? Before upgrading your production environment, please verify that all installed modules, themes, and integrations are compatible with WHMCS 9.1. If any component is not yet confirmed compatible, we recommend waiting for a supported release. Useful links: Proxmox VE VPS & Cloud For WHMCS View All WHMCS 9.1 Compatible Modules Read Our WHMCS 9.1 Compatibility Article ModulesGarden Team

It's not really meant as a "switch my client area right now" control, which is why it looks like nothing happens when you save it. On the client profile, that Language field is the client's saved preference, and WHMCS uses it in a few places: 1. Emails. This is the big one. When WHMCS sends that client an email, it uses the translated version of the template for their language if one exists. Open any template under Configuration > System Settings > Email Templates and you can add a translated subject and body per language. If no translation exists for that language, the default template goes out, so a lot of people set the field, see English emails and assume it's broken. 2. Login. When the client logs in, their session picks up the saved language, so the client area loads in it (as long as that language file exists in /lang and the language menu is enabled in General Settings > Localisation). 3. Staff side. You can see and change it from the client's profile in the admin area, so yes, it's handy for support to know what language to reply in, but WHMCS doesn't translate tickets for you. If you want clients to be able to switch on the fly, that's the language dropdown in the client area (Enable Language Menu), which is separate from the saved preference. Quick test: set a test client to a language you've translated one template for (for example the Client Signup Email), then use Send Email from their profile. If it arrives translated, everything's working as intended.

Hi! I'm a PHP/Laravel Developer specialized in developing custom WHMCS modules , extends functionality of companies existing modules , Fixing OOPs bugs and also create module which connect you AI Tool with WHMCS using MCP. (Under NDA) Now I'm Providing Services To Hosting Companies For Automate Their Manual Tasks , Providing solutions of their Problems. Here's my Portfolio: https://huzaifaazeem.com/

I came across this and found the issue only occurred if you have the Chrome password manager set to store your admin username and password. For some reason Chrome is seeing the ticket status box as a username field and automatically jumps to this to populate it with your admin username. I tried a few workarounds but the only thing that fixed it was by telling Chrome to forget the admin username/password for the install.

The point about the service mainly covering core upgrades and one custom theme matches what I'd expect too. For your staged path, I'd ask the provider directly whether 8.13.6 and 8.13.7 can be applied before 9.1, since that sequencing is unusual and may not be part of a standard upgrade. Compatibility of custom hooks, order-form themes and local addons likely needs a separate developer review, and registrar/payment gateway modules deserve the same scrutiny. Get written confirmation of scope and what happens if something breaks before contracting.

Soon there will be an entry fee payable each time a client or admin needs to sign in.