Key takeaways
- WordPress malware lives in site files and the database; server malware lives on the operating system underneath.
- Server-level persistence, such as cron jobs, systemd services, rogue users and reverse shells, survives a WordPress clean-up and reinstalls the site malware.
- Malware that returns minutes or hours after cleaning is the strongest sign the problem is bigger than WordPress.
- A WordPress security plugin only sees WordPress; it cannot see a crontab or an outbound connection.
- Clean in the right order: break server persistence first, then clean the sites, then fix the entry point.
What is the difference between WordPress malware and server malware?
WordPress malware is malicious code inside your website: infected plugin or theme files, injected JavaScript, rogue administrator accounts and spam in the database. Server malware is malicious code on the machine that runs the website: scheduled tasks, services, users, SSH keys, reverse shells and miners. They often arrive together, because a WordPress weakness is a common way onto the server.
The difference matters because they are cleaned in different places. Removing WordPress malware does nothing about a cron job on the server that downloads it again, and a clean server does nothing about an infected plugin.
How do the two compare?
| WordPress malware | Server malware | |
|---|---|---|
| Where it lives | Plugin, theme and core files, wp-content/uploads, the database | Crontabs, systemd units, /tmp and /dev/shm, users, SSH keys, system binaries |
| Typical examples | Webshells in uploads, injected redirect scripts, SEO spam, rogue admins | Cron re-download loops, reverse shells, cryptominers, rogue VPN nodes |
| What it affects | One site | Every site on the server, and the server itself |
| Usually found by | Site scanners and plugins, file comparison with official copies | Server-side forensic checks: processes, connections, scheduled tasks, accounts |
| Survives a WordPress reinstall? | No, if you replace core, plugins and themes and clean the database | Yes |
How can you tell which one you have?
The clearest sign of server-level malware is reinfection: you clean the site and the same files reappear within minutes or hours, often under new names. Other signs are several unrelated sites affected at once, unexplained CPU use, outbound connections to addresses you do not recognise, and users or SSH keys you did not create.
- Likely WordPress-only: one site affected, the infection stays gone after a proper clean, and core files, plugins and database are the only things changed.
- Likely server-level: malware returns after cleaning, several sites are infected together, or the server shows unexplained load, new users or outbound connections.
- Not sure: assume the server could be involved until someone has checked cron, services, users and connections.
Our guide to why malware keeps coming back goes through the common persistence patterns in more detail.
Security triage
Is your site showing any of this?
Tell us what you’re seeing in two minutes and we’ll tell you what it means and what to do next. Hacked right now? Get emergency help.
Why does a WordPress clean-up miss server malware?
A WordPress clean-up looks at WordPress. Security plugins run inside the site and see site files, not the operating system, so they cannot see a scheduled task on the server or a process connecting out to an attacker. If the attacker has left something at server level, the site is re-infected as soon as you finish cleaning.
That is not a criticism of plugins, which are useful for prevention and for catching known site malware. It is a limit of where they run; we explain how to combine both in security plugin vs server-side scanning.
In what order should you clean an infected server?
Break the server persistence first, then clean the sites, then fix how the attacker got in. If you clean the site first, the persistence reinstalls the malware and you start again. If you skip the entry point, the attacker simply returns.
- Preserve evidence. Take a snapshot and record what you see before changing anything.
- Break persistence. Remove malicious cron entries, services, rogue users and keys, and stop suspicious processes.
- Clean every site. Quarantine webshells and injected code, reinstall WordPress core, plugins and themes from official sources, and clean the database. Infections spread between sites, so clean all of them.
- Find and close the entry point. Use access logs and file timestamps to find the vulnerable plugin, stolen login or exposed service.
- Harden and monitor. Lock down SSH and the firewall, block PHP execution in uploads and watch for changes.
After a root-level compromise, a rebuild onto a fresh server may be safer than cleaning. See VPS server security for how to isolate and harden a server, and server malware removal if you would like us to do it for you.
Frequently asked questions
Can WordPress malware infect the server?
WordPress malware runs with the permissions of the web server or site user, so on its own it is limited to what that user can reach. But an attacker with code execution through WordPress can use it to look for other weaknesses, and may reach the wider server, particularly where sites share a user or the server is poorly configured.
Can server malware infect WordPress?
Yes. Server-level persistence is the usual reason a cleaned WordPress site is infected again: a scheduled task or service downloads the malware back into the site. That is why checking only the site often fails.
Do I need a server scan or a website scan?
If one site is affected and stays clean after treatment, a website scan and clean-up may be enough. If malware returns, several sites are affected or the server behaves oddly, you need server-level checks as well. A forensic scan covers the server; a malware sweep covers the sites.
Is shared hosting affected by server malware?
Less directly: on shared hosting the server itself is your host's responsibility, and you can clean what your account controls, including files, databases and cron jobs. Server-level issues on shared hosting should be reported to your host.