Cryptomining Malware on WordPress: Why Your Server Is Maxed Out
By Glenn Lyvers · Updated · 5 min read
If your site has gotten quietly, persistently slow, your host has warned you about CPU usage, or a resource graph shows the server working hard around the clock with no matching spike in visitors, cryptomining malware is one of the more likely explanations. It's a hack with no visible payload — no defacement, no spam pages, nothing Google flags — which is exactly why it tends to run for weeks before anyone notices. Here's how it gets there and how to actually get rid of it.
The symptom that gives it away
Most WordPress hacks announce themselves: a defaced homepage, a Google blacklist warning, spam showing up in search results. A cryptominer wants none of that attention — its entire value to the attacker is CPU time, harvested quietly for as long as possible. So the tells are all performance-related: pages that used to load fast now drag, your host emails about "excessive resource usage" or throttles your account, or a server monitoring tool shows CPU pinned near 100% at times when your actual traffic doesn't come close to explaining it. If any of that sounds familiar, it's worth ruling in or out before you assume it's just "the site got popular."
How miners get installed
The entry point is almost always one of the usual suspects, not something exotic: a vulnerable plugin or theme with a known, unpatched hole; a stolen or brute-forced admin password; a nulled theme or "free" premium plugin with the payload built in (see my nulled themes guide); or, on shared hosting specifically, cross-contamination from a different, already-compromised account on the same server. That last one matters because it means a clean WordPress install and strong passwords aren't always enough — the attacker got in through a neighbor, not through you.
Where to look
Once installed, a miner needs to (1) run continuously and (2) survive reboots and cleanup attempts, which means it leaves a specific set of fingerprints:
Cron jobs. Check both WordPress's own scheduled tasks (via a plugin like WP Crontrol) and the server's real crontab — a launcher that restarts the miner every few minutes is standard, and it's often the only thing keeping the process alive.
Disguised binaries. Look in wp-content/uploads, temp directories, and any world-writable folder for executable files with innocuous names (xmrig, kworker, or a random string trying to look like a system process) that have no business being there — uploads directories should never contain executables at all.
Outbound connections. Miners phone home to a mining pool. If you or your host can check outbound connections, unfamiliar traffic on ports associated with mining pools (often 3333, 4444, 5555, or 8080) alongside a process consuming heavy CPU is close to a confirmed diagnosis.
Unfamiliar processes in general. On a VPS or dedicated server, top or htop sorted by CPU will usually show the culprit directly — a process you don't recognize, running as the web user, eating a full core.
Cleaning it out
Kill the process, then immediately find and remove whatever restarts it — the cron entry, the scheduled task, or the watchdog script — before you do anything else, or it will simply relaunch. Then work backwards through the entry point: update the vulnerable plugin or theme that let it in, rotate every password and API key associated with the site, and check for the backdoor files that so often accompany this kind of access; my backdoor removal guide covers exactly that hunt. On shared hosting, ask your host directly whether other accounts on the same server have been flagged — if the entry point was a neighbor, your own cleanup won't be the end of it.
Why it keeps coming back if you only kill the process
This is the mistake I see most: someone finds the process, kills it, watches CPU drop, and considers the job done. A day or a week later it's back, because the launcher — the cron entry or watchdog — was never removed, or because the original vulnerability that let it in the first time is still open for a second visit. Treat a miner exactly like any other reinfection risk; my reinfection guide walks through why cleanups fail and what actually makes them stick.
If chasing down cron jobs and outbound connections isn't something you want to spend an afternoon on, this is squarely the kind of job my malware removal service handles — process, launcher, entry point, and hardening, in one pass.
Common questions
How is cryptomining malware different from a regular WordPress hack?
A defacement or spam-redirect hack wants your visitors; a cryptominer wants your server's CPU and doesn't care about your visitors at all. That's why it's often missed for weeks: there's no ugly warning page, no Google blacklist notice, nothing a visitor would ever see. The only symptoms are performance-related — slow load times, a host resource-usage warning, or a suspiciously busy server when traffic doesn't justify it.
My host suspended me for 'resource abuse' — is that the same thing?
It's one of the most common causes. Shared hosts monitor CPU and process counts per account and suspend anything that consistently exceeds its plan's limits, without necessarily telling you why. A mining process running around the clock will trip that threshold reliably, so a sudden resource-usage suspension on a site that hasn't changed is worth checking for a miner before assuming it's just growth.
Can I just kill the mining process and move on?
No — killing the process without finding what launched it just buys you a few minutes. Miners are almost always paired with a cron job, a scheduled task, or a watchdog script that respawns the process the moment it's killed or the server reboots. You have to find and remove the launcher, not just the running process, or it comes straight back.
Does cryptomining malware steal data too?
Not by design — its goal is CPU cycles, not your database. But the vulnerability or stolen credential that let a miner in is exactly the same kind of access an attacker would use to steal data, plant a backdoor, or install other malware. Finding a miner is a strong signal to check for other unauthorized access, not proof that nothing else happened.
Will a security plugin like Wordfence catch it?
Sometimes, if the miner or its launcher touches PHP files Wordfence scans. But many miners run as standalone binaries outside the webroot, or are triggered by cron rather than by a WordPress file at all, which puts them outside what a WordPress-focused plugin can see. Server-level process and cron auditing catches what file scanning alone misses.