CVE-2026-43641 is an unauthenticated command-injection flaw in Softaculous Virtualizor’s billing-module handler. Virtualizor is a commercial web control panel for provisioning and operating VPSs, containers and hypervisors such as KVM, Xen, OpenVZ and Proxmox. That puts it in the hands of hosting providers, cloud operators, datacentres and enterprises running their own virtual-server estates—often with one master controlling many physical nodes.
The payoff is unusually direct: a remote attacker can run commands as root on the Virtualizor host. From there, they may control the management plane and the VPS instances it administers. The detailed disclosure documents laboratory root-shell execution, but there is no confirmed exploitation in the wild or campaign attributed to CVE-2026-43641 as of September 25, 2026.
A pre-login callback reaches a shell command
The bug sits in a callback intended for billing integrations. A request parameter can invoke the billing-module update path before normal authentication succeeds. An attacker supplies crafted serialized data in the billing_data POST field, then uses the uid value to inject shell syntax. That value ultimately reaches proc_open() through Virtualizor’s vexec() helper without the needed validation.
The authentication change is worth studying because it shows the bypass plainly. In vulnerable 3.2.9 Patch 7, from_billing_module alone reaches the callback; patched builds require a successfully validated API call first:
// 3.2.9 patch 7: reached with act=login, no credentials
if (optGET('from_billing_module')) {
update_data_for_billing_modules(optGET('from_billing_module'));
exit();
}
// 3.2.9 patch 9 / 3.3.0: $temp = apicall_validate() earlier in the pre-auth block
if (!empty($temp) && optGET('from_billing_module')) {
update_data_for_billing_modules(optGET('from_billing_module'));
exit();
}The patch also converts uid to an integer before it reaches the command path. The known practical conditions narrow the attack surface somewhat: an eligible, suspended type-2 user using in-house billing and meeting the required balance condition must exist, and the database must use non-strict SQL mode. The researcher reports that production Virtualizor’s bundled MySQL configuration uses non-strict mode by default.
Patch now, then investigate exposure
The fix is in 3.2.9 Patch 9, released September 1, and was re-tested in 3.3.0, released September 9. The public Patch 9 note does not describe this vulnerability, and no dedicated vendor advisory naming CVE-2026-43641 could be confirmed. Upgrade affected management servers promptly to Patch 9 or 3.3.0, restrict public access to the panel and its billing callbacks, and review web, API and host-command logs for suspicious callback requests and unexpected root activity.
Patch 7 and Patch 8 were confirmed vulnerable. Whether 3.0.0 is affected cannot be stated confidently: the CVE record’s prose and structured version data contradict each other, and testing did not establish every older release.
A public demonstration raises the operational stakes
A public technical proof of concept exists in the disclosure, including the request path, prerequisites and a successful root-shell result. The researchers also describe an exploit module, but its source code or a compiled download could not be confirmed as public. CVE-2026-43641 is not in CISA’s Known Exploited Vulnerabilities catalogue.
For teams that run Virtualizor, this is a management-plane patch, not a routine application update. Confirm the installed build, patch the master before spending time on downstream guests, and use SecAlerts to monitor the software actually in your stack for new vulnerabilities affecting it.
