Recommended Services
Supported Scripts
How to recover a hacked cPanel account and clean malware

Finding a defaced homepage, a Google “This site may be hacked” warning or a suspension notice for sending spam is a bad moment, and the instinct is to delete the infected file and move on. That almost never works. Attackers who compromise a cPanel account nearly always leave several ways back in: a hidden PHP backdoor, a malicious cron job, an extra SSH key or a rogue admin user. Clean only the visible symptom and the site is reinfected within hours. This guide gives you a methodical process to contain, clean and harden a hacked cPanel account.

Signs Your cPanel Account Has Been Compromised

  • Unfamiliar files or recently modified PHP files you did not change
  • Redirects to spam or pharma sites, usually only for visitors arriving from Google or on mobile
  • Sudden traffic or CPU spikes, or “508” errors (see Fix 508 Resource Limit Reached)
  • Outbound spam: your mail queue is full or your IP appears on a blacklist
  • Browser or Google Search Console security warnings
  • New WordPress administrators, or password-reset emails you did not request

Step 1: Contain a Hacked cPanel Account

  1. Take the site offline or into maintenance mode, or block public access with .htaccess, so visitors are not served malware while you work.
  2. Take a full backup of the infected account first. You need it for forensics and in case you delete something needed. Label it “infected”.
  3. Change every credential immediately: cPanel password, FTP and SSH accounts, database passwords, WordPress admin passwords, email accounts and API tokens. Do this from a clean computer, because a keylogger may be how the account was taken.
  4. Log out all sessions. In WordPress, change the salts in wp-config.php, which invalidates every login cookie.

Step 2: Scan and Identify Infected Files

If your host runs Imunify360 or ImunifyAV you can scan directly from cPanel (see Imunify360 free with IAMEM Hosting). Otherwise ClamAV or Linux Malware Detect (Maldet) work from SSH:

# Linux Malware Detect
maldet -a /home/username/public_html

# ClamAV
clamscan -ri --exclude-dir=mail /home/username/public_html

Scanners miss custom obfuscated code, so back them up with manual checks.

Find recently changed files

# PHP files modified in the last 7 days
find ~/public_html -type f -name "*.php" -mtime -7 -ls

# PHP files hiding in uploads (there should be none)
find ~/public_html/wp-content/uploads -type f -name "*.php"

Search for common malicious patterns

grep -rIlE "eval\(base64_decode|gzinflate\(base64|str_rot13\(|FilesMan|c99shell|r57shell" ~/public_html --include=*.php

Treat every match as suspicious, but verify before deleting: a few legitimate plugins use base64_decode. Look at the file path, owner and modified date.

Compare against clean copies

For WordPress, WP-CLI can verify core and plugin files against the official checksums:

wp core verify-checksums
wp plugin verify-checksums --all

Any “File doesn’t verify” result for core means tampering. Replace core with a fresh download: wp core download --force --skip-content.

Step 3: Hunt for Persistence

This is the step that separates a real cleanup from a temporary one.

Where to lookCommand or locationWhat to check
Cron jobscrontab -l or cPanel » Cron JobsEntries you did not create, especially wget/curl piping to sh
SSH keys~/.ssh/authorized_keysUnknown public keys
WordPress userswp user list --role=administratorRogue admin accounts
.htaccess filesfind ~/public_html -name .htaccessRedirect rules, auto_prepend_file directives
Config overrides.user.ini, php.iniauto_prepend_file or auto_append_file loading malware
Mu-plugins and drop-inswp-content/mu-plugins/, wp-content/*.phpFiles you do not recognise
Databaseswp_options, wp_postsInjected <script> or <iframe> tags
Other sitesAddon and subdomain directoriesNeglected installs are the usual entry point

An important detail: cPanel accounts are a single trust domain. If one abandoned WordPress install under an addon domain was the entry point, the attacker can write to every other site in the account. Scan all of them, and delete anything you no longer use.

Step 4: Clean and Restore

You have two options.

  1. Restore from a known-clean backup, dated before the infection began. This is the safest route. Then immediately apply all updates before going live, otherwise the same vulnerability will be exploited again.
  2. Clean in place. Reinstall WordPress core, reinstall every plugin and theme fresh from official sources (never reuse the copies on the server), remove unrecognised files, and clean the database.

Never “restore” a backup without checking when the compromise started. Backups taken after the infection simply restore the malware.

Step 5: Find How They Got In

If you skip this, the cleanup is pointless. Check the access logs around the first modified file’s timestamp:

# Requests to a suspicious file
grep "shell.php" ~/access-logs/* | head

# POST requests to PHP files in uploads
grep "POST" ~/access-logs/* | grep "/wp-content/uploads/" | grep ".php"

The usual causes are an outdated plugin or theme with a known vulnerability, a nulled (pirated) theme, weak or reused passwords, and exposed wp-config.php backups. Update or remove the vulnerable component.

Step 6: Harden the Account

Block PHP execution in uploads by adding this to wp-content/uploads/.htaccess:

<FilesMatch "\.(php|phtml|php5|phar)$">
    Require all denied
</FilesMatch>

Step 7: Request Review and Monitor

If Google flagged your site, fix it first, then request a review in Search Console » Security Issues. If your IP was blacklisted for spam, see our guide to getting delisted from Spamhaus and Barracuda. Watch logs and file-change reports for at least two weeks after cleanup.

Frequently Asked Questions

Can I just delete the infected files?

Rarely. Malware usually exists in many places, including the database, cron jobs and other sites in the same account. Deleting visible files without finding the entry point and persistence mechanisms leads to reinfection.

How long does cPanel malware cleanup take?

A single small WordPress site can be cleaned in a few hours. Accounts with many addon sites or a long dwell time can take a day or more, plus the monitoring period afterwards.

Should I rebuild the server?

Only if you suspect root-level compromise. On shared hosting, a compromised user account does not normally affect the server, but VPS owners with exposed root or SSH credentials should treat the whole server as compromised.

Will a free malware plugin protect me?

Plugins help detect changes but cannot fully protect you if the attacker already has file access. Combine server-level scanning, patching, strong authentication and backups.

Leave a Reply

Your email address will not be published. Required fields are marked *