CloudPanel site hacked? How to find malware, clean up and lock it down
Spam pages in Google, visitors redirected to strange sites, a hosting abuse email, or the server suddenly at 100% CPU: these are the classic signs of a hacked site. Don't panic, and don't just delete the one bad file you found. Attackers almost always leave more than one way back in. This guide gives you a calm, ordered way to deal with it on a CloudPanel server.
Step 1: Contain it
Step 2: Find what changed
Recently changed PHP files (adjust the date to a few days before you noticed the problem):
PHP files where they don't belong, such as upload folders:
Typical malware patterns (this finds suspects, not proof; read each file):
Cron jobs you didn't create (check the site's Cron Jobs tab and):
Processes and connections that look wrong (crypto miners are common):
Users: check CloudPanel's user list, the site's SSH/FTP users, and the WordPress admin users ().
Step 3: Find out how they got in
Cleaning without closing the hole means you'll be hacked again next week. The usual entry points:
Step 4: Clean up (or restore)
Best option: restore a clean backup from before the hack, then update everything right away. See How to restore a site from a CloudPanel backup. Check the backup's date against the first bad file you found; a backup taken after the break-in is infected too.
No clean backup? For WordPress:
Step 5: Change every password
Assume everything stored on the server was read: CloudPanel users (clpctl user:reset:password), SSH/SFTP users, database passwords (update the app's config afterwards), WordPress admins, API keys and SMTP passwords in config files. Also generate new WordPress salts in to log everyone out.
Step 6: Make it harder next time
If you're not sure whether a file is malicious, post the file name and a few lines (never passwords) in this section and ask.
Sources: WP-CLI: verify-checksums · Google: help for hacked sites
More CloudPanel troubleshooting
Applies to CloudPanel v2 on Ubuntu and Debian, October 2026. Replace with your domain and with your site's user name.
Spam pages in Google, visitors redirected to strange sites, a hosting abuse email, or the server suddenly at 100% CPU: these are the classic signs of a hacked site. Don't panic, and don't just delete the one bad file you found. Attackers almost always leave more than one way back in. This guide gives you a calm, ordered way to deal with it on a CloudPanel server.
Step 1: Contain it
- Take a copy of the hacked state first (you'll want it to see what happened): Code:
tar -czf /root/hacked-$(date +%F).tar.gz /home/siteuser - Put the site behind Basic Auth or block all visitors except your IP in the site's Security tab, so it can't infect visitors or send more spam while you work. See CloudPanel site security.
- If the server sends spam or attacks others, your provider may suspend it. Tell them you're cleaning it up.
Step 2: Find what changed
Recently changed PHP files (adjust the date to a few days before you noticed the problem):
Code:
find /home/siteuser/htdocs -name '*.php' -newermt '2026-10-01' -type f | head -100Code:
find /home/siteuser/htdocs -path '*uploads*' -name '*.php'Code:
grep -rlE 'eval\(base64_decode|gzinflate\(base64|str_rot13\(|assert\(\$_(POST|GET|REQUEST)' /home/siteuser/htdocs | head -50Code:
crontab -l -u siteuser
crontab -lCode:
ps aux --sort=-%cpu | head -15
ss -tnp | grep -v '127.0.0.1' | head -30Code:
wp user list --role=administratorStep 3: Find out how they got in
Cleaning without closing the hole means you'll be hacked again next week. The usual entry points:
- An outdated plugin, theme or app with a known vulnerability (by far the most common).
- A stolen or weak password: WordPress admin, SSH, SFTP or the CloudPanel login.
- An unpatched PHP version. Make sure PHP is current, for example against PHP2Shell (CVE-2026-109618/109619).
Code:
grep -E 'POST' /home/siteuser/logs/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head -20Step 4: Clean up (or restore)
Best option: restore a clean backup from before the hack, then update everything right away. See How to restore a site from a CloudPanel backup. Check the backup's date against the first bad file you found; a backup taken after the break-in is infected too.
No clean backup? For WordPress:
- Replace core files: and check withCode:
wp core download --force --skip-content.Code:wp core verify-checksums
- Reinstall every plugin from the official source: and check withCode:
wp plugin install $(wp plugin list --field=name) --force. Premium plugins that aren't on WordPress.org must be downloaded fresh from the vendor.Code:wp plugin verify-checksums --all
- Replace the theme with a fresh copy.
- Go through and delete everyCode:
wp-content/uploadsfile there.Code:.php
- Check by hand for added code.Code:
wp-config.php
Step 5: Change every password
Assume everything stored on the server was read: CloudPanel users (clpctl user:reset:password), SSH/SFTP users, database passwords (update the app's config afterwards), WordPress admins, API keys and SMTP passwords in config files. Also generate new WordPress salts in
Code:
wp-config.phpStep 6: Make it harder next time
- Turn on automatic updates for plugins you trust, and remove plugins you don't use.
- Allow SSH and port 8443 only from your IPs, and use SSH keys.
- Use 2FA for CloudPanel and WordPress admins.
- Keep off-server backups with a few weeks of history, so you can go back further than the infection.
- Ask Google to review the site in Search Console once it's clean, if it was flagged.
If you're not sure whether a file is malicious, post the file name and a few lines (never passwords) in this section and ask.
Sources: WP-CLI: verify-checksums · Google: help for hacked sites
More CloudPanel troubleshooting
- Installation failed: common install errors
- Can't log in: port 8443, password and 2FA
- Site shows 403 Forbidden or 404
- Too many redirects or mixed content after SSL
- PHP extension missing / enable ionCube
- WordPress asks for FTP or can't update plugins
- Varnish showing old pages or breaking logins
- Restore a site from a backup
- SSH or SFTP login fails
- Node.js app shows 502 or keeps restarting
- clpctl errors: not found, wrong user, quoting
Applies to CloudPanel v2 on Ubuntu and Debian, October 2026. Replace
Code:
example.comCode:
siteuser
