WordPress malware removal

WordPress powers a very large share of the web, which makes it the most scanned software on it. Attacks are almost never aimed at your business specifically — automated tools sweep for one known weakness across enormous numbers of sites and take whatever they find. This guide covers where infections hide in a WordPress install and what a cleanup has to do to hold.

How WordPress sites usually get compromised

• An out-of-date plugin or theme. By far the most common route. When a vulnerability is disclosed, mass scanning for it begins almost immediately, which is why "we were going to update it next week" is such a frequent story.
• An abandoned plugin. Software removed from the directory, or no longer maintained, never receives the fix at all.
• Weak or reused administrator passwords. Credentials exposed in an unrelated breach get tried against wp-login.php automatically.
• A nulled theme or plugin. Pirated premium software very often ships with a backdoor already installed — that is the business model.
• A neighbouring site on the same server. On shared hosting or a VPS with several sites, the weakest install can be the way in to all of them.

Where the infection actually hides

Scanners find the obvious payload. What causes reinfection is everything else, and on WordPress it tends to live in predictable places.

1. The uploads directory. Executable files among your media, or images with a second extension. If the server will run PHP from wp-content/uploads, that folder is a launchpad.
2. Modified core files. WordPress core is a known quantity, so anything altered inside it stands out — if you compare against the official release rather than eyeballing it.
3. Rogue administrator accounts. Added so access survives a password change. Sometimes hidden from the user list by a filter in a malicious plugin.
4. The database. Injected scripts in wp_posts, spam in wp_options, and altered siteurl or home values that redirect visitors.
5. wp-config.php. Both a target for credential theft and a place to hide an include of a payload elsewhere on disk.
6. Must-use plugins. The mu-plugins directory loads automatically and cannot be deactivated from the dashboard, which makes it an attractive hiding place.
7. .htaccess files. Used for conditional redirects that only fire for search traffic or mobile visitors.
8. Outside the web root entirely. Cron jobs, systemd timers or files in the home directory that reinstall the payload after you delete it.

What a cleanup should actually include

1. Back up the infected state first. It is your only record of what happened, and you may need it.
2. Find the entry point before deleting anything. Server access logs usually show the request that worked and when.
3. Compare core, plugins and themes against known-good copies rather than trusting a visual check.
4. Quarantine malicious files rather than deleting them outright, so the evidence survives.
5. Clean the database — injected content, spam options, tampered site URLs.
6. Audit every user and remove accounts nobody can account for.
7. Rotate every credential: WordPress admins, database, FTP/SFTP, hosting panel, and the salts in wp-config.php so existing sessions are invalidated.
8. Patch or remove whatever let them in. A cleanup that skips this step is temporary by definition.

Hardening so it does not simply happen again

• Block PHP execution in wp-content/uploads
• Keep core, plugins and themes updated, and remove anything unused
• Enforce strong, unique administrator passwords and two-factor authentication
• Restrict or rate-limit access to the login page
• Correct file and directory permissions
• Lock down the firewall and SSH at the server level, not just the site
• Keep monitoring in place, because reinfection attempts follow a success

Should you restore a backup instead?

Sometimes — but only if you know the backup predates the compromise, and only after the entry point is fixed. Two traps catch people here. First, dwell time is usually longer than owners assume, so the "clean" backup is often already infected. Second, restoring puts the original vulnerability straight back, so the site is recompromised by the same automated scan that found it the first time.

If you run several sites on one server

Cleaning one WordPress install is rarely enough when it shares a machine with others. Malware that reached the filesystem may have touched neighbouring sites, and one missed backdoor puts all of them back at risk. That is why we work at the server level — see VPS server security.

Related guides