iServerSupport Talk to an engineer

WordPress Site Redirecting to Spam? How to Find the Malware on a cPanel Server

If your WordPress site redirects visitors to spam, the infection is usually in a few predictable places. Here is how we find and verify it on a cPanel server.

Bug icon representing malware hidden inside a hacked WordPress site

The most frustrating version of this problem is the one the site owner cannot reproduce. You open your own site and it looks normal. A customer opens it from a phone, arriving from Google, and lands on a fake prize page. Redirect malware is written to hide from logged-in administrators and from direct visits, so the first lesson is that "it looks fine to me" proves nothing. What follows is the order we work in when a WordPress account on a cPanel server is sending visitors somewhere they never asked to go.

Do these three things before you touch a file

Cleaning too early is how people lose evidence and, worse, miss the way the attacker got in. Start by taking a copy of the account, either a cPanel backup or a snapshot of the site files and database, and store it off the server. Next, put the site in maintenance mode or suspend it if it is actively harming visitors, because a redirecting site can get flagged by Google within days. Finally, note the date of the first report. That date tells you which files to treat as suspicious, since anything modified close to it deserves attention.

Look for PHP files where none should exist

The wp-content/uploads folder holds media. It should not contain executable code, so any PHP file there is a strong signal. This single check finds a large share of infections:

cd /home/ACCOUNT/public_html
find wp-content/uploads -type f -name "*.php"

Do not delete anything yet. Copy suspicious files somewhere safe for review first, and read them before you decide. Then widen the search to files changed recently across the whole site, which catches modified core and theme files too:

find . -type f -name "*.php" -mtime -14 -printf '%TY-%Tm-%Td %p\n' | sort -r | head -40

Compare WordPress core and plugins against known-good copies

If you have shell access and WP-CLI installed, WordPress can check its own files against the official checksums, which is far faster and more reliable than reading code by eye:

wp core verify-checksums --path=/home/ACCOUNT/public_html
wp plugin verify-checksums --all --path=/home/ACCOUNT/public_html

Any file that has been changed or added to core will be listed. Replace core with a clean download rather than editing infected files in place. Leave wp-config.php and the wp-content directory alone during that replacement, since they hold your settings and content. Premium plugins and themes that are not in the official repository cannot be checked this way, so reinstall them from the vendor.

Search for the usual malicious patterns

Obfuscated code leans on the same few functions again and again. A recursive search will not prove a file is malicious, but it narrows thousands of files to a reviewable handful:

grep -rEl "eval\(base64_decode|eval\(gzinflate|str_rot13\(|assert\(\$_(POST|REQUEST)" --include=*.php .

Expect some false positives from legitimate plugins. Read each hit in context. Also check the places attackers like to hide a redirect so it runs on every request:

cat .htaccess
grep -R "auto_prepend_file\|auto_append_file" . --include=.user.ini --include=php.ini
ls -la wp-content/mu-plugins/

An auto_prepend_file pointing at a strange path, unfamiliar rules at the top of .htaccess that redirect based on the visitor's referrer or user agent, or a file in mu-plugins that you never installed, are all common. Must-use plugins load automatically and do not appear in the normal plugin list, which is exactly why attackers use them.

Check the database, not just the files

Some infections keep their payload in the database and only write a PHP file at request time, so a file scanner comes up clean while the redirect carries on. Look at the options table and for unexpected administrator accounts:

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp option get siteurl
wp option get home
wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%' LIMIT 20;"
wp cron event list

An administrator you do not recognise, a siteurl that differs from the real address, script tags inside option values, or scheduled events that reinstall malware every few minutes all point to an infection that will return after a file-only cleanup.

Find out how they got in

Removing the malware without closing the entry point guarantees a second visit, often within days. The domain access log is where the answer usually is. Look for POST requests to files that should never receive one, especially inside uploads or plugin directories, around the date of the first report. In practice the cause is most often an outdated plugin or theme with a known vulnerability, a stolen administrator or FTP password, or another infected site sharing the same account. If other WordPress installs live under the same cPanel account, check them too, because cross-site infection is routine. Our guide on securing a WordPress website covers the hardening to apply once the site is clean, and the same bot-heavy traffic described in our post on AI crawler bots hitting your server is a reminder to watch access logs more closely than most owners do.

After cleaning: rotate everything

Assume every credential on the account was seen. Change the WordPress administrator passwords, the cPanel password, FTP and SSH credentials, and the database password, then update wp-config.php to match. Regenerate the authentication salts so existing logins are invalidated:

wp config shuffle-salts --path=/home/ACCOUNT/public_html

Update WordPress core, every plugin and every theme, and delete anything you are not using. If the site sends mail, review the outbound queue too, since infected accounts are often used for spam as well, as described in our guide to finding a spammer on a cPanel Exim server.

Ask Google to re-check the site

If Search Console shows a security warning, request a review only after you are confident the site is clean and the entry point is closed. A review requested too early and rejected delays recovery. A clean site, a fixed vulnerability and rotated credentials are what a reviewer is looking for.

Hand-cleaning a hacked site is slow, and missing one file means starting again. If you would rather have someone find the infection, remove it, close the way in and confirm the site is clean before it goes back online, our WordPress malware removal service does exactly that.

WordPress malware removal

Suspect your WordPress site is infected?

We find the infection, remove it, close the entry point and check the site is clean before it goes back online.