WordPress slow: could it be a hack?
Site suddenly crawling, CPU pinned at the top, your host warning you about resource usage? Beyond a performance issue, it could be a cryptominer or a hidden botnet.
A slow WordPress is rarely exciting to diagnose. Nine times out of ten, it’s one plugin too many or an overloaded host. But sometimes a site that suddenly drags and a server under heavy load are hiding something else: a hack that hijacks your CPU to mine cryptocurrency or attack other sites. Here’s how to tell the difference before you tear everything apart or pay for a pricier host for nothing.
ordinary slowness, the kind that has nothing to do with a hacker
Before you suspect an intrusion, rule out the ordinary causes. They explain the vast majority of slow sites.
- Too many plugins, or badly coded ones that fire extra queries on every page.
- A saturated shared host: you share the server with hundreds of other sites, and one of them is hogging all the resources.
- No cache. Without a caching plugin (WP Super Cache, W3 Total Cache, or your host’s own cache), every visit rebuilds the page from scratch.
- Heavy uncompressed images, autoplay videos, a bloated theme.
- A database that’s never been cleaned, swollen with revisions and stale transients.
What these causes have in common: the slowness is steady and tracks your traffic. The site drags when it’s busy and breathes at night. Nothing odd in your host’s graphs. If that’s your situation, a good caching plugin and a hosting upgrade often fix the problem in an afternoon.
suspicious slowness, the kind that smells like an intrusion
The picture changes completely when an attacker uses your server for their own purposes. Now the load no longer follows your traffic. Three scenarios come up again and again.
The cryptominer. A script installed on your server mines cryptocurrency (often Monero) using your CPU. The result: the processor pinned at 100% around the clock, including at 4 a.m. when nobody’s visiting the site. It’s the most telling pattern.
The attack relay. Your site becomes a soldier in a botnet. It’s used to launch denial-of-service attacks (DDoS), credential stuffing, or brute force against other WordPress sites. What you mostly see is abnormal outbound traffic, not necessarily a huge CPU load.
The mailer on a loop. A script sends mass spam from your server. The CPU climbs, the mail queue blows up, and your domain ends up on blocklists. First visible symptom: your own emails stop arriving.
In all three cases, the attacker got in through a hole (an outdated plugin or theme, a weak password) and left a backdoor to come back. The slowdown is just a side effect of their activity.
the signs that should put you on alert
Here’s what separates an infection from a simple performance issue:
- CPU spikes during off-hours, with no connection to your actual traffic.
- An email from your host about resource usage, a CPU quota overage, or a temporary account suspension.
- Scheduled tasks (cron) you never created.
- Heavy outbound traffic when your site only serves pages.
- On a VPS or dedicated server, unknown processes running, especially
xmrig, random names, or a script launched from a/tmpfolder. - Recent files you didn’t upload, especially
.phpfiles tucked into folders that should never contain any.
A single one of these signs proves nothing. Several at once, and it’s serious. These symptoms often overlap with the other signs of a hacked site: strange redirects, fake posts, a Google warning.
how to investigate in practice
You don’t need to be a sysadmin to run a first diagnosis. A few checks are enough.
look at the resource graphs
Every serious host exposes CPU, memory, and traffic curves in its panel (cPanel, Plesk, or an in-house interface). Look for spikes that don’t line up with your visit hours. A flat, high load 24/7 is a bad sign.
list the scheduled tasks
An unknown cron is a classic of infections. If WP-CLI is available:
wp cron event list
Spot the hooks with odd names or the runs spaced very closely together. The code behind a suspicious cron often hides in the wp-config.php file or in a must-use plugin (wp-content/mu-plugins/).
look for PHP files where they have no business being
The wp-content/uploads folder should only contain media. A PHP file inside it is almost always malicious.
find wp-content/uploads -name "*.php"
If this command returns anything at all, you’ve probably found one of the attacker’s entry points.
scan the site
A scanner (Wordfence, or a server-side tool like ImunifyAV) catches known malware signatures. It’s not foolproof, but it points you in the right direction fast.
on a VPS, watch the processes
If you have SSH access to a dedicated server or a VPS, run top or htop and look at what’s eating the CPU. A mining process like xmrig jumps right out. Note its name and the path it’s launched from; that helps you trace it back to the source.
how to clean up (and why a simple kill isn’t enough)
Killing the mining process or deleting the visible cron will give you ten minutes of relief. Then it all starts back up, because the backdoor is still there and relaunches the script.
A proper cleanup goes in this order:
- Back up the current state (files + database) before touching anything. Even infected, it’s your safety net.
- Find and remove the backdoors and injected scripts. This is the step that takes method: you have to find and remove the backdoor, or the rest is pointless.
- Reinstall the WordPress core with a clean version, remove the shady plugins and themes, replace modified files with healthy copies.
- Harden: change every password (admin, database, FTP), revoke sessions, update everything, disable file editing from the admin.
As long as the backdoor is still there, you’re cleaning symptoms, not the cause. For the full walkthrough, see the complete guide for when WordPress is hacked.
faq
My CPU is at 100%, does that mean I’ve been hacked? No. A traffic spike, a greedy plugin, or a heavy WordPress task can max out the CPU. What gives away an infection is a high load during off-hours, with no visitors to justify it.
My host suspended me for overuse. What do I do first? Ask them for the logs or the details of what triggered the alert. Many hosts point straight at the script or process at fault, which saves you a ton of time hunting for the backdoor.
I’m on shared hosting, I can’t see the processes. How do I check?
Without SSH access, lean on the resource graphs in the panel, the cron list (wp cron event list), a scan, and the search for PHP in uploads. That covers most cases.
Not sure about your diagnosis? WP-Detox starts with a free scan that says clearly whether your slowness comes from an infection or just a performance problem. If it’s a hack, we remove the backdoor and the mining script, reinstall a clean core, and harden the site, usually in about thirty minutes. Full backup before any action, €149 all-in, refunded if we can’t fix it.