SURIQ
WHMCS is the billing and provisioning control plane for a large slice of the hosting industry: the software that takes the payment, opens the ticket, and, through server modules, tells the control panel to spin up an account. It is internet-facing by design and it holds the customer database, order history, payment-gateway configuration, and frequently the API credentials to the servers behind it. So when WHMCS says an unauthenticated attacker can run code on that host, the honest translation is not "a web app has a bug." It is "a stranger can take the control plane of a hosting business."
On September 3 2026 WHMCS released version 9.0.8 and 8.13.7 to close two unauthenticated flaws. The one that should move your maintenance window tonight is CVE-2026-67399, remote code execution reachable with no login and, per the vendor, no workaround.
What WHMCS patched
The advisories describe two separate problems, fixed in the same release. The first is the code-execution flaw. WHMCS states that an unauthenticated user can submit a forged payload that the application handles without adequate restrictions, and that under specific conditions this leads to arbitrary code execution on the server. In plain terms: attacker-controlled data is turned back into live objects the code trusts, a class of bug known as insecure deserialization or object injection. No account, no user interaction, network-reachable. Those are the properties that make it the priority.
The second, CVE-2026-67398, is narrower but still ugly: an unauthenticated attacker can pull a customer's full contact record, their name, mailing address, email, and phone number, through the 2Checkout payment-gateway integration under specific conditions. It only bites installations that run the 2Checkout module, and unlike the RCE it has an interim mitigation.
| Detail | CVE-2026-67399 | CVE-2026-67398 |
|---|---|---|
| Impact | Unauthenticated remote code execution, full host compromise | Unauthenticated disclosure of customer personal data |
| Precondition | Network access to the WHMCS install | The 2Checkout payment gateway is active |
| Affected | 9.x before 9.0.8; 8.x before 8.13.7 | 9.x before 9.0.8; 8.x before 8.13.7; WHMCS 4.5 and later |
| Fixed in | 9.0.8 and 8.13.7 | 9.0.8 and 8.13.7 |
| Interim workaround | None. Update is the only fix. | Deactivate the 2Checkout module until patched |
Why an unauthenticated WHMCS bug is worse than a typical web flaw
Neither advisory carries a CVSS number, and it does not need one to tell you where this sits. Think about what a WHMCS host actually reaches. The billing database is customer identity and transaction history. The gateway configuration is money movement. The server and provisioning modules hold credentials into cPanel, Plesk, DirectAdmin, and virtualization backends, because that is how WHMCS automates account creation. Code execution on that host is a pivot point into all of it. This is the same reason a control-panel flaw earns more of your attention than an equally-scored bug in some standalone app: the platform sits above other systems and lends its trust to them.
That is also the difference between this and the customer-data flaw. The 2Checkout leak is a real privacy and compliance problem, but it is bounded, it exposes records. The code-execution flaw is unbounded, because once code runs as the WHMCS user, the records, the gateway secrets, and the downstream credentials are all in scope, and so is a quiet persistence mechanism the next visitor never sees.
The window is pure patch speed
The line in the CVE-2026-67399 advisory that matters most is that there is no customer-side workaround. You cannot toggle off a module or drop a firewall rule to neutralize it the way you can with the 2Checkout flaw. Your exposure is therefore a direct function of one variable: how many hours pass before you install 9.0.8 or 8.13.7. Billing platforms are exactly the systems operators are slowest to touch, because an unplanned change to the thing that invoices customers feels riskier than the vulnerability does. That instinct is backwards this week. WHMCS reports no known exploitation and says the issues came through its security program, which buys you a head start, not immunity. Deserialization advisories draw exploit-writers precisely because the payoff is code execution, so treat the quiet as the interval before public interest, not the absence of it.
Patch today, then hunt for what the window let in
Update to 9.0.8 (on the 9.x line) or 8.13.7 (on the 8.x line) now; those are the only builds that carry both fixes. If you run the 2Checkout gateway and cannot patch this instant, deactivate that module first to shut the data-leak path, then patch. That is the vendor guidance and it is correct as far as it goes.
Here is what the advisories do not tell you: a patch closes the door, it does not tell you whether someone already walked through. Because CVE-2026-67399 is unauthenticated and internet-facing, you have to assume any exposed install was reachable by scanners the moment the fix signaled a target. So after you update, look. Check the WHMCS document root and writable directories for files that were not shipped by the product, especially PHP that postdates your last legitimate change. Review the staff and administrator user list for accounts you did not create. Diff your hook and template directories against a known-good copy. Pull the web-server and WHMCS activity logs for the pre-patch window and look for unusual POST requests to endpoints that should not accept unauthenticated input, and for outbound connections the host has no reason to make. Rotate the credentials WHMCS holds, gateway API keys and any server-module passwords, if you find anything at all, and consider rotating them regardless given what the flaw exposes. A fixed build cannot un-run code that already ran.
This is the pattern with platform software: the score tells you how bad the bug is, but the blast radius is decided by what the platform is wired into. WHMCS is wired into your customers, your money, and your servers. Patch it like it is all three, because it is.