Why is every site on my CloudPanel server infected?
When several sites on one CloudPanel server are infected, there are two common explanations: each site shares the same weakness, such as an outdated plugin or a reused password, or the attacker gained broader access than one site user and moved across. CloudPanel runs each site as its own system user, which limits spread, but it does not help if the weakness is shared or the attacker reaches root.
Which explanation applies decides the clean-up. If it is a shared weakness, you must fix it on every site, or the untouched ones re-infect the cleaned ones. If the attacker has root, you also have to look for persistence that no website scan will find. That is why we clean the whole server together.
For a plain-English walkthrough of the checks, see our guide to cPanel and CloudPanel malware clean-up.
Where does malware hide on a CloudPanel server?
On CloudPanel, malware usually hides in the site web roots under /home/{site-user}/htdocs/{domain}, in site-user crontabs, in /tmp and /dev/shm, and, after a root compromise, in system services, cron and rogue users. These are the places we check, and the order matters: persistence first, payloads second.
| Location | What we look for |
|---|---|
| Site web roots | Obfuscated PHP, webshells, PHP files in uploads, injected JavaScript, modified core files |
| Site-user crontabs | Scheduled downloads that reinstall malware |
/tmp, /dev/shm, /var/tmp | Executables, miners and reverse shell tooling |
| systemd units | Recently added services with system-looking names |
Linux users and authorized_keys | Accounts and keys you did not create |
| Nginx vhost configuration | Injected redirects or proxy rules |
| CloudPanel admin users | Panel accounts you did not create |
If you are comfortable on the command line, these read-only commands are a safe first look:
# crontab for every CloudPanel site user (read-only)
for u in $(ls /home); do echo "== $u"; crontab -l -u "$u" 2>/dev/null; done
# executables in memory-backed and temp directories
find /tmp /dev/shm /var/tmp -type f -perm -u+x 2>/dev/null
# outbound connections and the processes behind them
ss -tupn state establishedRecord what you see rather than deleting it. The evidence is what lets us find how the attacker got in.
Is the CloudPanel admin panel itself at risk?
Yes, because the panel is a way to control the whole server. It is usually reachable over HTTPS on a dedicated port (8443 by default), so if it is open to the whole internet it is exposed to password guessing and to any vulnerability in the panel software. A panel admin account you did not create is a serious sign of compromise.
- Restrict access. Limit the panel port and SSH to your own IP addresses in the firewall.
- Audit panel users. Remove any admin you do not recognise and use strong, unique passwords with multi-factor authentication where available.
- Keep it updated. Install CloudPanel and operating system updates; panel vulnerabilities have been disclosed in the past.
- Review SSH keys. Check the keys attached to site users and to your own account.
We review all of this as part of the clean-up, and our Harden playbooks apply the firewall and SSH changes for you.
How does PatientZero clean a CloudPanel server?
We connect over SSH, deploy the scan engine to /opt/patient-zero/scan-engine and run two scan profiles across every site user. The Forensic scan (dfir-fast) looks for indicators of compromise on the server; the Malware sweep (malware-intelligence) checks site files and databases for malicious code. We then clean in a fixed order so nothing reinstalls itself.
- Break persistence. Remove malicious cron entries, services and processes first.
- Quarantine payloads. Move webshells and injected files out of the web roots, recording hashes as evidence.
- Restore known-good code. Reinstall WordPress core, plugins and themes from official sources and clean the database.
- Find the way in. Use access logs and file timestamps to identify the vulnerable plugin, stolen login or exposed service.
- Harden and monitor. Close the entry point, lock down SSH and the panel, and watch for changes.
See the Forensic scan and Malware sweep pages for what each profile checks. You receive a technical report and a plain-English summary you can share with clients or insurers.
Should you clean the CloudPanel server or rebuild it?
If the compromise was confined to website files, a thorough clean-up and hardening is usually enough. After a confirmed root-level compromise, a rebuild onto a fresh server with verified site files migrated across can be safer, because you cannot fully trust a system the attacker controlled. We advise on which applies once we have seen the evidence.
Unlimited removal covers clean-ups on every plan; fair use applies to full server rebuilds, which we scope with you. Our broader server malware removal page covers the root-compromise case in more depth.
What should you do first if your CloudPanel server is hacked?
Contain it without destroying evidence. Snapshot the server through your provider if you can, restrict SSH and the panel to your own IP address, change passwords and SSH keys from a device you trust, and do not delete files until the evidence has been captured.
- Snapshot the server. This preserves evidence and gives you a rollback point. Do not treat it as a clean backup.
- Restrict access. Limit SSH and the panel port to known IP addresses in your provider firewall.
- Rotate credentials from a clean device. Panel admins, SSH keys, site users, databases and your provider console.
- Record, do not repair. Save the output of basic checks rather than acting on it yourself.
- Call for help. 01932 593642 or start emergency triage.