Active Threat: cPanel Auth Bypass Weaponized Against MSPs and Gov Networks
Just caught the latest intelligence from Ctrl-Alt-Intel regarding the active exploitation of the recently disclosed cPanel vulnerability. While we've discussed the patching requirements in other threads, it looks like a previously unknown threat actor is now aggressively weaponizing this flaw.
The campaign is specifically targeting government and military entities in Southeast Asia, alongside MSPs and hosting providers in the Philippines, Laos, Canada, South Africa, and the U.S. This isn't just opportunistic scanning; the targeting is precise.
If you manage cPanel instances—especially for MSP clients—I highly recommend checking for signs of initial access or webshells. The actor appears to be bypassing authentication to establish persistence.
Here is a quick Splunk query to hunt for suspicious cPanel login attempts where the user agent is missing or mimics a browser (common in this exploit chain):
splunk index=web sourcetype="access_combined" cpanel_uri="/login/" | stats count by src_ip, http_user_agent
| where http_user_agent="-" OR match(http_user_agent, "(Mozilla|curl|Wget)")
| sort - count
Has anyone observed follow-on activity after the initial compromise? I'm curious if others are seeing data exfiltration tools typical of espionage campaigns or if this is leaning towards ransomware deployment.
We saw a similar pattern hitting our honeypots last week. The actor seems to be exploiting the auth bypass to drop a webshell almost immediately. We've been blocking IP ranges from SE Asia, but given the jump to Canadian and US targets mentioned in the report, geo-blocking alone won't cut it.
We recommend updating your WAF rules to block requests to /usr/local/cpanel/ endpoints that don't originate from your known admin IPs. Also, verify your /usr/local/cpanel/logs/access_log for any POST requests that resulted in a 200 OK without a valid session cookie.
As an MSP owner, this is my worst nightmare. We patched immediately when the vulnerability dropped, but we have a few legacy clients on 'End of Life' builds that can't upgrade without breaking their custom PHP apps.
We've isolated those specific instances behind a VPN and disabled public WHM access entirely. It's a hassle for the clients, but it's better than explaining why they were breached by a state-sponsored actor. For those stuck on old builds, restricting cpdavd and non-essential ports via your firewall is a decent temporary mitigation.
The detection logic is solid, but don't forget to check for process anomalies on the backend. The exploit chain we analyzed involved spawning a Perl child process from the cpanel user context.
You can use this one-liner to check for suspicious Perl processes running under the cpanel user that aren't standard uptime checks:
ps -u cpanel -o pid,cmd | grep perl | grep -v "checkperl" | grep -v "cpsrvd"
If you get output, you might already be owned.
Good catch on the Perl processes. To complement that, ensure you're hunting for recently modified files in the web root and temp directories, as the actor often drops obfuscated shells immediately upon bypass. You can hunt for these IOCs using a simple find command:
find /usr/local/cpanel/base /tmp -name "*.php" -o -name "*.pl" -mtime -1
Building on Rachel’s process observation, don’t overlook established network connections. If the auth bypass drops a shell, it will likely attempt outbound C2 communication. I recommend checking for sockets owned by the cpanel user. On Linux, you can quickly audit active connections with:
ss -tunp | grep 'cpanel'
This is often faster than correlating file hashes if the payload is purely memory-resident or obfuscated.
Since the bypass grants administrative control, I recommend auditing your cPanel API logs specifically. Attackers often use these endpoints to maintain persistence or create mailers before dropping a webshell. Check for high-frequency API calls originating from unusual IPs or user-agents:
grep "cpanel__api" /usr/local/cpanel/logs/access_log | awk '{print $1, $12, $13}' | sort | uniq -c | sort -rn | head -20
Excellent points on persistence and C2. To catch the entry mechanism itself, I suggest auditing the access_log for the specific API endpoint patterns used in this bypass. Since it’s an auth bypass, you might see 200 OK responses for accounts that weren't actively logged in via the UI. This helps distinguish the exploit from credential stuffing. You can hunt for these anomalies with:
grep "POST /-api/" /usr/local/cpanel/logs/access_log | grep " 200 "
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access