All Activity

@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.

The click-tracking through the cart-restoration link is the detail that stands out to me, since it turns the reminder emails into something measurable rather than just a sequence. Curious whether the five steps can be spaced independently per product or only globally, and whether there's any cooldown so a customer who already completed checkout mid-flow stops receiving later emails. The 1.0.2 note about IonCube Loader 15 and WHMCS 9.1 support is also useful to see spelled out.

Just a quick update, today we released Lara v9.1.0, which is fully compatible with WHMCS v9.1.0. The new version ensures PHP v8.2 to v8.4 compatibility.

Yes, the marketplace account is created once you agree to the EULA on the latest version, no opting out. No EULA agreement, no upgrade.

excuse me, but wat Marketplace accounts is a requirement now even for installations not using it? Out of all the stupid things WHMCS has done, this is probably the most stupid. Well, maybe right after voiding the lifetime licenses.

Okay so the above isn't an issue. Can someone answer this because its confused me a little. Clients Account Details Language. What is the purpose of that option I assumed it was so client could select their preferred language seems its not for that. Does it have another purpose is it linked to support so staff can see clients preferred communication Language

Wild guess it's related to the new forced marketplace accounts requirement, and not worth their time to backport it.

I came here to mention this very same thing. Given the significant number of problematic changes in 9.x AND that 9.1 was only released 10 days ago, this is an unreasonable expectation. If the WHMCS devs had done a better job preparing 9.x such that there weren't endless bugs reported for months after, I can see this being more reasonable. However that's not how things panned out. I also would like to request that WHMCS 8.13 remain actively supported until at minimum your planned release date for WHMCS 9.2 so that your customers can feel more comfortable with the 9.x upgrade prior to ending support for 8.x. I would estimate that this would be June 2027.

Hello, Is anyone else having issues with client Languages on version 9.1.0 When clients are selecting there preferred language its saving but visually it stays as the system's default language. Admin language change seems to be functioning correctly.

Welcome to WHMCS in 2026. No care for the user, their focus is 99% pleasing Webpros/shareholders.

i was updating to the latest release and lo and behold! a effin EULA that says that it will force create a account i (we) never wanted. this and the price increase.. i will push at work to look at another product..

On v9 the supported way is to reissue the invoice rather than edit it. It takes a minute once you've done it a couple of times: 1. Open the unpaid invoice and click Duplicate Invoice. The copy is created as a Draft with the same line items, invoice date, due date and payment method. 2. Edit the Draft copy (new price, description, whatever changed), then click Publish, or Publish & Send Email if you want the client to get the corrected one straight away. 3. Go back to the original invoice and Mark Cancelled. Don't forget to fix the price at the source too, otherwise the next renewal invoice comes out with the old amount again. On the client's service (Products/Services tab) update the Recurring Amount, and if the product price itself changed, update the product pricing as well. If you really want the old behaviour back, it's still there for now: Configuration > System Settings > General Settings > Invoices > Invoice Immutability, pick one of the "Immutability disabled" options. That's also what triggers the "Invoice immutability is disabled" banner you saw. WHMCS says that option will be removed in a future release, so I'd get used to the duplicate, publish, cancel routine instead of building your workflow around editing.

We've deliberately remained on WHMCS 8.13 due to the numerous issues with version 9. We've been closely monitoring the WHMCS End of Life (EOL) schedule, where the end-of-support date for version 8.13 has been listed as "TBD" for a long time. When I checked the page today, I was genuinely shocked to discover that the status had changed: support for WHMCS 8.13 is now scheduled to end on December 1, 2026 - roughly one month from now. I checked the page earlier this month, and the date was still listed as TBD. Furthermore, the latest available snapshot on the Internet Archive, dated September 30, 2026, confirms that the status was still TBD at that point. Announcing the end of support for a major software version with only around one month's notice is completely unreasonable. This is particularly concerning given the significant issues that still remain with WHMCS 9, which are precisely why we've continued to run version 8.13 in the first place. Customers need adequate notice to plan, test, and execute a major upgrade - especially when the proposed upgrade path involves a version that continues to present substantial problems. Changing the EOL status from "TBD" to a firm date so close to the deadline, without meaningful advance notice, is simply unacceptable.