CyberPanel Security Incident: Malware Cleanup and Server Hardening

In late October 2024, a critical vulnerability in CyberPanel (CVE-2024-51567) let attackers run commands as root without authentication, through a flaw in how the panel's upgrademysqlstatus endpoint handled requests. Within days, automated worms were scanning the internet and dropping ransomware on unpatched servers. A few client servers I manage were running CyberPanel and got hit before I could patch them.

What the cleanup looked like

The first step on each affected server was pulling it off the network, or at minimum blocking inbound traffic at the firewall, before doing anything else. You don't want an active infection making more outbound connections while you're working. From there:

• Checked /usr/local/lscp and the web roots for unfamiliar files and recently modified timestamps
• Found and removed the dropped malware binaries and cron persistence entries

• Reviewed /etc/crontab, user crontabs, and systemd timers for anything that didn't belong
• Checked for new SSH keys in authorized_keys and any new user accounts

• Ran ImunifyAV across the full filesystem to catch anything missed manually

Patching and hardening

Once each server was clean, I applied the official patch CyberPanel released for the vulnerability, then went further:

• ModSecurity with the OWASP Core Rule Set in front of the panel, to catch this class of attack even if a future vulnerability slips through
• ImunifyAV running scheduled scans, so a re-infection gets flagged within hours instead of weeks later
• CSF (ConfigServer Security & Firewall) locked down to only the ports and source IPs that actually need access to the panel

The lesson from this one

CyberPanel's admin port (8090) should never be open to the entire internet. Restricting it to a VPN or a small allowlist of IPs would have stopped this particular worm regardless of the underlying vulnerability. That's the change I made across every server afterward: panel access goes through a VPN, full stop.