cPanel Malware Scan Tutorial (2026): Detect, Quarantine, and Clean Infected WordPress Accounts in WHM

A single compromised WordPress plugin can turn your hosting VPS into a spam cannon or a redirect farm. The fastest way out is to stop guessing and use a tight loop. Scan, confirm, quarantine, clean, then close the hole that let the malware in.

This cPanel malware scan tutorial walks through a repeatable workflow for WHM/cPanel on AlmaLinux/Rocky/CentOS Stream-based servers. It also includes CLI commands for when the GUI crawls.

The steps below assume you manage a cPanel server (or a VPS running WHM). If you’re building from scratch, start with a clean, maintained base.

managed VPS hosting from HostMyCode works well if you want cPanel plus patching and baseline hardening handled. You still keep root access.

Before you scan: contain the blast radius (5-minute triage)

Don’t start a full scan while the server is sending spam or injecting redirects. Contain the incident first. This limits reputation damage and keeps scan results readable.

• Check for outbound spam quickly (Exim):

exim -bpc
exim -bp | head
grep -R "cwd=/home" /var/log/exim_mainlog | tail -n 20

• If the mail queue is exploding, temporarily rate-limit or block outbound SMTP at your edge firewall (port 25) until you identify the source account.
• Capture a snapshot/backup before cleanup. If the server is unstable, a fast snapshot can save you later.

If you want a structured backup routine (rotation, encryption, and restore checks), use this internal guide: cPanel backup configuration tutorial.

Pick your scanning approach (ImunifyAV/360, ClamAV, and “cheap signals”)

On cPanel servers, you’ll usually lean on three layers of detection:

1. ImunifyAV / Imunify360: the best mix of signatures, heuristics, and a usable quarantine workflow in WHM.
2. ClamAV: signature-based. Common on budget stacks. Still useful, but expect more manual validation.
3. Cheap signals: log spikes, suspicious PHP functions, strange cron entries, new admin users, or a sudden burst of file changes.

If you host multiple customer sites, consistent CPU and NVMe I/O makes scans faster and less disruptive. A right-sized HostMyCode VPS helps you avoid scans that time out during peak traffic.

Step 1: Identify the infected account(s) fast

Start with symptoms and narrow the scope. Your goal is to find which home directories deserve attention first.

Do that before you spend hours scanning the entire server.

Check web server logs for redirect patterns and PHP dropper paths

On cPanel with Apache, common log locations include:

• /usr/local/apache/domlogs/DOMAIN.TLD
• /usr/local/apache/domlogs/DOMAIN.TLD-ssl_log

# Example: look for suspicious redirects and injected JS patterns
DOMAIN="example.com"
LOG="/usr/local/apache/domlogs/${DOMAIN}"
grep -E "(base64_decode|gzinflate|eval\(|fromCharCode|document\.write)" -n "$LOG" | tail -n 50

If you run Nginx in front of Apache, you may also have Nginx logs.

For a clean Nginx front-end layout (multiple sites, SSL, real IP logging), see: VPS reverse proxy setup tutorial.

Find recent file changes in a user’s public_html

# Replace USERNAME
USER="cpuser"
find "/home/${USER}/public_html" -type f \( -name "*.php" -o -name "*.js" \) -mtime -3 -printf '%TY-%Tm-%Td %TT %p\n' | sort | tail -n 80

Pay attention to:

• Random file names in wp-includes/ or wp-admin/ (WordPress core should look familiar and consistent)
• .ico, .jpg, or .png files that are actually PHP (confirm with file)
• New files in wp-content/uploads/ with .php extensions

Step 2: Run the malware scan (WHM first, CLI second)

Run scans in this order. Start with suspected accounts. Go server-wide only if you still can’t find the source.

Option A: ImunifyAV/Imunify360 in WHM

1. Log in to WHM as root.
2. Go to ImunifyAV or Imunify360 (menu name depends on your license).
3. Scan the specific user(s) first. Avoid “scan everything” unless you have spare CPU.
4. Review detected items. Choose Quarantine instead of “Delete” until you verify what you’re looking at.

Rule of thumb: quarantine first. Then clean with evidence.

Blind deletions break sites. They can also erase clues about the entry point.

Option B: ClamAV from the shell (targeted scan)

If ClamAV is installed, keep it targeted. You’ll get quicker runs and logs you can actually read.

# Update signatures
freshclam

# Scan a single account (replace USER)
USER="cpuser"
clamscan -r -i --log=/root/clamav-${USER}-$(date +%F).log "/home/${USER}/public_html"

If you need full coverage of the user account (mail, temp files, hidden directories), scan /home/USER.

Expect more false positives. Also expect a longer runtime.

Step 3: Quarantine safely (without wiping evidence)

Once you confirm a file looks malicious, move it out of the web root. Leaving it in place “for later” rarely works. Bots come back.

# Create a quarantine directory owned by root
mkdir -p /root/quarantine/$(date +%F)/
chmod 700 /root/quarantine

# Example: quarantine a suspicious file
SUSPECT="/home/cpuser/public_html/wp-includes/wp-login.php"  # example path
cp -a "$SUSPECT" "/root/quarantine/$(date +%F)/"

# Then remove or neutralize the live copy
mv "$SUSPECT" "${SUSPECT}.quarantined"

If you’re updating a customer or keeping an internal incident record, grab a hash:

sha256sum "${SUSPECT}.quarantined"

Step 4: Clean WordPress the boring way (core, plugins, themes)

The cleanups that stick are usually the least exciting. Replace known-bad and unknown code with known-good code. Then tighten access.

Don’t try to “sanitize” every suspicious line by hand.

Replace WordPress core files

From the account shell (or as root), run this inside the site’s document root:

cd /home/cpuser/public_html

# Keep wp-config.php and wp-content
# Download fresh WordPress core
curl -L https://wordpress.org/latest.tar.gz -o /tmp/wp-latest.tar.gz

tar -xzf /tmp/wp-latest.tar.gz -C /tmp/

# Replace core directories/files (careful not to overwrite wp-content)
rsync -a --delete --exclude wp-content --exclude wp-config.php /tmp/wordpress/ ./

Audit plugins and themes

• Delete anything nulled/pirated. If it came from an unofficial ZIP site, treat it as compromised.
• Remove inactive plugins you “might use later.” Old code is a common reinfection path.

If WP-CLI is available, inventory is quick:

wp plugin list --path=/home/cpuser/public_html
wp theme list --path=/home/cpuser/public_html

Need help with stuck updates or permission breakage after cleanup? This internal walk-through focuses on the problems you’ll actually hit: WP-CLI troubleshooting tutorial.

Find and remove common malware loaders

These strings show up constantly in PHP malware and droppers:

• base64_decode, gzinflate, str_rot13
• eval(, preg_replace with /e (older patterns), assert(
• Long single-line PHP files with random variable names

cd /home/cpuser/public_html

grep -R --line-number --binary-files=without-match -E "base64_decode\(|gzinflate\(|str_rot13\(|eval\(" . | head -n 60

Don’t delete on a single match. Some security plugins use these functions legitimately.

Use matches to rank what you review first.

Step 5: Check persistence points (cron, .htaccess, wp-config.php, users)

Most “mystery reinfections” come from persistence. You removed the obvious payload, but a backdoor stayed behind. It rebuilt the infection.

Inspect user crons

In WHM: Home » System Health » Cron Jobs (names vary). Look for curl/wget tasks that don’t belong.

From CLI, you can inspect a user’s crontab if you have shell access:

crontab -u cpuser -l

Red flags:

• curl http:// or wget http:// to unknown domains
• Base64 blobs inside the cron command
• Jobs running every minute that aren’t real application tasks

Review .htaccess for injected redirects

find /home/cpuser/public_html -name .htaccess -maxdepth 4 -print -exec tail -n 60 {} \;

Injected rules often target mobile user agents. They may also trigger only on a search-engine referrer. That’s why customers say “it only happens sometimes.”

Validate wp-config.php and admin users

• Make sure wp-config.php doesn’t include remote code or strange require statements.
• Rotate WordPress admin passwords. Remove unknown admin accounts.
• Rotate database user password (update it in wp-config.php).

Step 6: Fix permissions and ownership (a common reinfection enabler)

Loose permissions don’t magically create malware. They do make it easier for a compromised plugin to drop shells across the account.

Typical safe defaults for a WordPress site on cPanel:

• Directories: 755
• Files: 644
• wp-config.php: 600 or 640 depending on PHP handler

# Run as root; replace USER and path
USER="cpuser"
SITE="/home/${USER}/public_html"

chown -R ${USER}:${USER} "$SITE"
find "$SITE" -type d -exec chmod 755 {} \;
find "$SITE" -type f -exec chmod 644 {} \;
chmod 600 "$SITE/wp-config.php" 2>/dev/null || true

If you use PHP-FPM or suPHP variants, confirm your handler requirements before forcing permissions.

It’s easy to “fix security” and end up with a wall of 403 errors.

Step 7: Close the entry point (patching, WAF, and safer defaults)

Cleaning is only half the job. If you don’t remove the original weakness, you’ll see the same infection again.

Update OS + cPanel + EasyApache packages

# Run as root
/usr/local/cpanel/scripts/upcp --force

yum update -y  # AlmaLinux/Rocky/CentOS Stream

If updates happen irregularly, set a maintenance window. Include backups and a rollback plan you’ve already tested.

This tutorial walks you through proving recovery works: VPS restore drill tutorial.

Add a web application firewall for WordPress traffic

A WAF doesn’t replace patching. It buys you time by blocking common exploit payloads while you clean up and update.

For ModSecurity + OWASP CRS on hosting stacks, follow: Web Application Firewall tutorial.

Harden HTTP security headers (after malware removal)

Security headers won’t stop PHP malware on the server. They do reduce browser-side abuse and tighten mixed-content behavior once the site is clean.

Use this guide for safe WHM defaults: cPanel security headers setup guide.

Step 8: Confirm the server is clean (and not still leaking spam)

Before you call the incident closed, run a verification pass. You want proof the payload is gone. You also want proof the server isn’t still sending mail it shouldn’t.

• Re-scan the cleaned account(s).
• Check the mail queue again:

exim -bpc
exim -bp | head

• Check outbound connections for suspicious processes:

ss -tunap | head -n 50
lsof -i -n -P | grep -E ":25|:465|:587" | head

• Spot-check key pages from a clean browser profile and from a mobile user agent.

If the VPS is struggling during scans or rebuilds, fix resource pressure first. Under load, tools time out and logs go missing.

This guide helps you isolate the bottleneck: VPS performance troubleshooting tutorial.

Step 9: Customer-facing remediation checklist (resellers and shared hosting ops)

If you host client sites, consistency matters. A clear checklist reduces back-and-forth. It also prevents the “it’s hacked again” ticket next week.

• Reset WordPress admin passwords and remove unknown admin users.
• Update all plugins/themes and remove unused ones.
• Replace nulled themes/plugins with licensed versions.
• Rotate FTP/SFTP passwords (and disable plain FTP if possible).
• Enable 2FA for WordPress admin and for cPanel where supported.
• Confirm contact forms aren’t abused for spam (captcha or rate limits).

Common pitfalls that waste hours

• Cleaning files but leaving a cron backdoor. The site looks normal for a day, then reinfects at 03:00.
• Only scanning public_html. Attackers often stash payloads in hidden directories under the user home.
• Deleting everything flagged. False positives happen. Quarantine first.
• Ignoring mail reputation. If spam went out, you may need deliverability cleanup (SPF/DKIM/rDNS) after remediation.

Summary: your repeatable “scan to clean” workflow

Most cPanel WordPress infections follow a predictable pattern. Contain spam and redirects. Scan the suspected account.

Quarantine instead of deleting. Restore known-good WordPress core. Audit plugins and themes. Remove persistence points.

Then patch and harden so the same exploit can’t land again.

If you’re hosting client sites, scans need CPU headroom and stable storage. Run WHM on a HostMyCode VPS. Or move to managed VPS hosting if you want ongoing maintenance handled while you focus on customers.

FAQ

Should I run a full-server malware scan or only scan one cPanel account?

Start with the suspected account. It’s faster and produces clearer results. Run a full-server scan if you see cross-account symptoms or can’t identify the source.

Is it safe to delete infected files immediately?

Prefer quarantine first. You may need evidence for customer communication, and false positives can break sites. Once validated, delete and replace with known-good code.

Why does the site keep getting reinfected after I clean it?

Most reinfections come from persistence points: cron jobs, hidden PHP shells in uploads, stolen admin credentials, or a vulnerable plugin left installed. Treat cleanup and hardening as one task.

Can I clean WordPress by only reinstalling the plugin that was hacked?

Usually not. Replace WordPress core, review all plugins/themes, and verify wp-config.php plus cron and .htaccess. Attackers rarely leave only one change.

What should I check if the server IP got listed after a malware incident?

Confirm outbound spam has stopped, then review your mail authentication (SPF/DKIM/DMARC and rDNS) and monitor the queue. If you run your own mail stack, repair deliverability before resuming campaigns.