CVE-2026-43641: Virtualizor Billing Hook Is Unauthenticated Root - Patch to 3.2.9 Patch 9

The Situation

On 22 September 2026, VulnCheck published three CVEs against Softaculous Virtualizor, the commercial VPS/hypervisor panel that sits on a lot of KVM, OpenVZ, and LXC nodes (and talks to WHMCS). The flagship is CVE-2026-43641: unauthenticated OS command injection in the billing-module handler. NVD's English description is blunt - a crafted billing_data POST field reaches proc_open() via vexec(), and the result is root on the host and every guest it manages.

VulnCheck is the CNA. Scores they published (not NVD-assigned):

CVE	Class	CNA CVSS 4.0	GHSA CVSS 3.1
CVE-2026-43641	Unauthenticated command injection (CWE-78)	9.3 CRITICAL	9.8
CVE-2026-43642	Unauthenticated PHP object injection (CWE-502)	9.2 CRITICAL	-
CVE-2026-43643	Unauthenticated cross-tenant balance write (CWE-639)	8.7 HIGH	-

NVD published all three on 22 September 2026. Status as of this writing: Deferred. There is no CISA KEV entry for any of them (catalog JSON pulled 2026-09-29).

Floor: treat 3.2.9 Patch 8 and earlier as remotely root-executable by an anonymous client, per VulnCheck's re-test. Fixed in 3.2.9 Patch 9 (2026-09-01) and 3.3.0 (2026-09-09). VulnCheck re-tested both patched builds on 20 September and confirmed the three sinks closed.

Softaculous's public Patch 9 changelog does not name these CVEs. It lists a Security Analyzer task and a Proxmox VNC bugfix. Do not wait for the vendor blog to say "CRITICAL RCE." The CNA write-up and the NVD records are the patch signal.

Why This Is a Hypervisor Problem, Not a PHP Nuisance

Virtualizor is not a WordPress plugin. The admin panel on TCP 4084/4085 is the control plane for the node. VulnCheck's decoded EMPS config is the part operators should remember: the admin index.php php-fpm pool runs as root. A web bug here is not www-data. It is uid=0 on the machine that holds every tenant disk, every WHMCS-provisioned VPS, and the panel database.

The entry, as VulnCheck describes it: the pre-auth redirect that is supposed to bounce anonymous hits to the login page does not fire when act=login. That is the one act a login page has to accept. With from_billing_module also set, the request falls through into update_data_for_billing_modules() with no session, no API key, no slave credentials.

From there:

43641 - a uid taken from unserialized POST data is concatenated into a shell string and handed to vexec() → proc_open(). VulnCheck verified /tmp/x reading uid=0(root) in lab. They also state this path is not precondition-free: in-house billing, an eligible currently-suspended account, and MySQL non-strict sql_mode. They downloaded the current EMPS installer stack and report it ships MySQL 5.5.62 with empty default sql_mode and no override in my.cnf - i.e. the production default, not a lab toy.
43642 - native unserialize() of attacker-controlled billing_data with no allowed_classes. VulnCheck is explicit: the primitive is real and unauthenticated; a working POP chain is not demonstrated in stock code.
43643 - the whmcs branch of the same handler runs an unauthenticated UPDATE users SET cur_bal …. Lab check they published: 777.00 → 0.00 on one request. Independent of sql_mode.

We are not reconstructing payloads. If you need the mechanism, read VulnCheck. If you need the box not to be rootable from the WAN, patch and lock the admin ports.

What to Do Now

1. Inventory version and admin ports

Virtualizor CLI (documented since 3.2.0.8; --version / --update since 3.2.9):

virtualizor --version
ss -lntup | grep -E ':4084|:4085'

Admin UI: Configuration / Updates also shows version + patch. You want 3.2.9 Patch 9 or later, or 3.3.0+. Anything at Patch 8 or below on the 3.2.9 line is in VulnCheck's "still vulnerable" set.

If virtualizor is not on PATH, it is usually /usr/local/virtualizor/ - confirm on the node rather than guessing a second binary.

2. Patch this node, then the fleet

virtualizor --update
virtualizor --version    # must show 3.2.9 Patch 9+ or 3.3.0+

On the master, push slaves:

virtualizor --update-all

Vendor docs: logs in /var/virtualizor/log/upgrade_bg. A successful CLI exit is not the check - --version on each slave is.

UI path: Admin panel → Updates → run the update (Admin API act=updates with update=1 is the same job).

3. Take 4084/4085 off the internet

VulnCheck's closing line is the standing control, patched or not: keep admin panel ports 4084/4085 off the public internet or behind an allowlist. End-user panel is 4082/4083. Those are not a substitute for the admin lock.

# example: nft/iptables/ufw - allowlist your NOC / WHMCS egress only
ufw allow from 203.0.113.10 to any port 4085 proto tcp
ufw deny 4084
ufw deny 4085

Replace the sample IP. If WHMCS talks to Virtualizor, the billing box's IP belongs on that allowlist or the integration breaks - that is expected.

4. After the patch

Re-read --version on every master and slave. One leftover Patch 8 slave is still a root shell.
If you do not use in-house billing, that shrinks 43641's stated preconditions; it does not retire 43643 (WHMCS branch) or 43642 (unserialize). Patch anyway.
Hunt is not specified by the vendor. VulnCheck does not claim in-the-wild use. Still look at 30 days of admin-port access logs, unexpected files under /usr/local/virtualizor/enduser/, new root cron, and new authorized_keys. Absence of a KEV row is not "nobody knocked."

What We Don't Know Yet

Honesty section, because the primary sources leave these open:

Not in CISA KEV as of 2026-09-29. VulnCheck's disclosure does not claim exploitation in the wild. We are not inferring it.
NVD status: Deferred for all three. The 9.3 / 9.2 / 8.7 figures are VulnCheck CNA CVSS 4.0. GHSA-x23m-fhhv-vj5x also lists a CVSS 3.1 9.8 on 43641. NVD has not assigned its own 3.x as of this pull.
Vendor changelog silence. Patch 9's public post does not mention CVE-2026-43641/2/3. VulnCheck decoded ionCube on Patch 9 / 3.3.0 and described the actual code change (apicall_validate() on the hook, (int) on uid, allowed_classes => false, email/uid ownership check on the WHMCS write). We did not re-decode the panel.
CVE text vs NVD affected. The CVE English string says "before 3.2.9 (Patch 9) and 3.0.0". NVD's affected block marks version 3.0.0 as unaffected. We are not resolving that conflict. Floor the 3.2.9 line at Patch 9 and 3.3.0 as VulnCheck re-tested; if you still run a 3.0.x tree, ask Softaculous in writing.
Preconditions. 43641 needs in-house billing + an eligible suspended account + non-strict SQL mode, per VulnCheck. They argue those are production defaults on EMPS. We have not surveyed live nodes to measure how common that trio is.
43642 - no stock gadget in the audit. Untrusted deserialize is still a vulnerability; it is not a demonstrated RCE in the write-up.
No KEV ransomware flag because there is no KEV row.

If a KEV entry appears, treat any internet-facing 4084/4085 on Patch 8 or earlier as compromised-until-proven-otherwise, not merely unpatched.

Sources

VulnCheck - "Virtualizor: The Login Parameter That Skips the Login" (published 2026-09-22), vulncheck.com/blog/virtualizor-billing-hook-unauthenticated-root-rce
NVD - CVE-2026-43641 (published 2026-09-22; CWE-78; CNA CVSS 4.0 9.3; status Deferred as of 2026-09-29)
NVD - CVE-2026-43642 (CWE-502; CNA CVSS 4.0 9.2)
NVD - CVE-2026-43643 (CWE-639; CNA CVSS 4.0 8.7)
GitHub Advisory - GHSA-x23m-fhhv-vj5x (CVE-2026-43641; CVSS 3.1 9.8 listed)
Virtualizor - 3.2.9 Patch 9 release post (2026-09-01), virtualizor.com/blog/virtualizor-3-2-9-launched-release-candidate-patch-9/
Virtualizor - 3.3.0 release post, virtualizor.com/blog/virtualizor-3-3-0/
Virtualizor docs - CLI (virtualizor --version, --update, --update-all), virtualizor.com/docs/admin/virtualizor-cli/
CISA Known Exploited Vulnerabilities catalog JSON - no entry for CVE-2026-43641 / 43642 / 43643 as of 2026-09-29