All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Security Update - SolusVM WHMCS Module update required immediately
George_Fusioned
Member
This just landed in my inbox - 4 days after the PR was published on GitHub:
We are writing to inform you of a security vulnerability affecting the SolusVM WHMCS module (solusvmpro.php) applicable for SolusVM 1. A security update is now available, and immediate action is required on every WHMCS installation running this module.
Affected component: SolusVM WHMCS module (solusvmpro.php), all versions prior to 4.2.2
Affected deployments: All WHMCS installations using the SolusVM 1 moduleRequired action
Upgrade the SolusVM WHMCS module to version 4.2.2 immediately. Download: [LINK]
Verify the upgrade by checking the module version in your WHMCS admin panel once completed.
If you operate the module in Admin mode and cannot patch, switching to Reseller mode reduces but does not eliminate exposure and should be treated only as a temporary mitigation option.
For update assistance, contact us at SolusVM immediately.
We strongly recommend taking immediate action to help protect your customers and infrastructure.
(yeah, the link doesn't work)
For everyone else, the patch has been public here for 4 days:
https://github.com/solusio/SolusVM-WHMCS-Module/releases
What the bug is (since the email doesn't say): a cross-tenant IDOR (SVM-4189) in solusvmpro_Custom_ChangeRescueMode. The pre-patch code used an attacker-controlled GET parameter as an array key, so any logged-in client could overwrite vserverid (or hostname / rootpassword / bootorder / etc.) and act on another customer's VM. Legitimate values are only rescueenable or rescuedisable anything else is exploitation.
Because the diff has been sitting on a public repo for 4 days before anyone was emailed, you should assume the exploit is in the wild and check your access logs:
zgrep -hiE 'rescueAction|ChangeRescueMode|changerescuemode' <your_access_logs_location>
Anything where rescueAction is not rescueenable or rescuedisable should be treated as malicious until proven otherwise.
Gripe, since I'm here: the responsible flow is to notify operators with a patch window first, then publish. Pushing a fix for a cross-tenant auth bug straight to a public repo with no advisory and no CVE, and emailing operators 4 days later, is a textbook example of how not to do coordinated disclosure.
