Why a Cleaned WordPress Site Keeps Getting Reinfected

Short answer: A cleaned WordPress site usually gets reinfected because the cleanup removed the malicious content, not the way the attacker got in. That access can take several different forms: a password nobody changed, a database login that leaked, a hidden admin account, a scheduled task quietly reinstalling the malware, or spam hidden so well that even the site owner can't see it. A clean scan may not reveal those access and persistence paths: it shows what the scanner could detect at that moment, not whether someone still has a way to put harmful content back — we've documented a case where a site passed four independent clean scans and was still reinfected within days, for exactly this reason.

TL;DR

• A malware scan checks state, not access. It answers "is there anything harmful here right now," not "can someone put it back." A full, honest cleanup can pass every scan and still leave the door open.

• Several important reinfection paths can sit outside a normal file scan or evade it. Retained credentials, database content, scheduled tasks, must-use plugins, and persistence outside the WordPress directory can all survive a file-focused cleanup.

• Every item below has a direct way to check it, and most don't require technical skill to at least investigate. A few are worth handing to a developer, and we say so.

• A fully updated site still isn't automatically safe. Patchstack found that heavily targeted vulnerabilities were typically attacked within five hours of disclosure, while traditional hosting defenses blocked only 12% of WordPress-specific vulnerability attacks in its 2025 testing.

Why Does WordPress Malware Come Back After Cleanup?

A clean malware scan primarily tells you what the tool could detect at that moment. Depending on the product and configuration, it may also check vulnerabilities, changed files, database content, or other indicators — but it still cannot prove that every route back into the site has been closed. That's true even with a well-regarded security plugin installed. Tools like Wordfence and Sucuri are genuinely useful for detection and cleanup support; the problem is treating a clean result as a complete incident investigation. It's a pattern that comes up constantly in WordPress troubleshooting communities: as one such discussion put it, a scanner "will often clean infected files, but it generally won't 'plug the hole' that allowed the malware into your site" in the first place. The "way back in" rarely looks like malware itself: a plaintext password, a background task quietly scheduled to run, a settings page nobody remembered was public.

Below are the eight places worth checking after a cleanup, roughly in the order they're worth ruling out. Most of this doesn't require being a developer to follow — a few steps are worth handing to one if you're not comfortable in your site's files or database, and we'll flag those as we go.

8 Places WordPress Reinfection Can Survive

1. Access That Was Never Actually Closed

Deleting a malicious file removes the file — it doesn't undo whatever let the attacker in to begin with. It doesn't change a password they may have used, and it doesn't rule out a second, quieter file (sometimes called a webshell: a small script that lets someone control the site remotely) sitting somewhere unrelated to whatever just got cleaned up. As one WordPress troubleshooting thread put it, "malware almost always drops a backdoor file so it can reinstall itself even after you clean up — if you don't find and remove that, a reinstall won't hold." Some malware doesn't even need a fresh way in: memory-resident families identified in 2025 security research, such as Lock360, run inside the server's own memory and rewrite core files like index.php and .htaccess the instant a clean copy is restored — undoing the fix before it's even finished.

Check: Change every password connected to the site: the hosting account, the login used to transfer files (FTP or SFTP), the WordPress admin login, and the database password, not just the one you suspect. If you're comfortable browsing your site's files, look for anything recently modified outside a normal update, and for code using functions such as eval, base64_decode, or gzinflate. Legitimate software can use these functions too, so their presence is a reason for review, not proof of malware. If that's unfamiliar territory, this is one worth asking your host or a developer to check.

Click to expand

2. Exposed Database Credentials

Every WordPress site has a file called wp-config.php that stores some of its most sensitive information: the site's database name, username, password, and server address, all as readable configuration values. A correctly configured server should not reveal that file when someone requests its URL. The danger is an exposed backup or copy, a server error that reveals PHP source, a file-read vulnerability, or an attacker who already gained file access. Any of those can expose the database credentials and allow direct changes to the database, leaving no new malicious file for a scanner to find. The risk around wp-config.php is not theoretical: in April 2026, security researchers at BleepingComputer reported a backdoor planted across more than 30 previously legitimate WordPress plugins, activated specifically to inject code into wp-config.php on thousands of sites at once. Even Wordfence's own founder has confirmed this pattern directly: responding to a user on Reddit, Mark Maunder wrote that after a hack, "they have also had a look at your database password which is stored in plaintext in your wp-config.php file. If that hasn't been changed, that is also a likely reinfection vector."

Credentials rarely leak the dramatic way; they leak the boring way. A backup file left sitting in the site's main folder (something like wp-config.php.bak), a forgotten file that publicly displays server details (a phpinfo() file), a leftover .git folder from how the code was uploaded, or an error log that happened to record a failed password can all hand over the same information as a deliberately hidden file.

Check: Look in your site's main folder and its plugins folder for anything unfamiliar, including file names that don't match any plugin you actually installed. If you're not sure what you're looking at, this is a good one to send to your host's support team or a developer, since acting on the wrong file can break the site. If you do find something exposed, change the database password the same day, both in your hosting account and inside wp-config.php.

3. Rogue Users

An administrator account you don't recognize is the obvious risk. A pile of unexplained subscriber or customer accounts is worth a look too, not dismissed just because none of them have admin access. WordPress can create public author archives for users who publish content, and on default configurations its REST API (a feature that lets other apps connect to your site) can expose the public slug and display name of users with published content to visitors who are not logged in. That slug can match the login name, giving an attacker a valid username to target. One site owner traced a repeatedly reappearing rogue admin account back to a vulnerable plugin, not a weak password — the account kept coming back until the plugin itself, the actual entry point, was found and removed.

Check: Go to Users in your WordPress dashboard and sort by role, then by registration date. Remove anyone with Administrator or Editor access you don't recognize, right away. For a large batch of low-privilege accounts you can't explain, don't stop at "none of them are admins"; ask why they exist at all, especially if the site doesn't sell anything requiring customer accounts.

Click to expand

4. Cron Jobs

WordPress can schedule tasks to run automatically in the background: sending a digest email, checking for updates, publishing a scheduled post. This system is called WP-Cron. Malware that survives cleanup sometimes uses the same system to schedule its own comeback — WordPress stores its entire schedule as one entry in its database, so malicious code can restore a scheduled task directly there, without touching a file at all. One real case described online captures why this is so stubborn: "the mu-plugin recreates the cron entry, the cron entry recreates the mu-plugin. Kill either one alone and the other puts it back within minutes." There's a second, separate version of cron worth knowing about too: the website's server can also run its own scheduled tasks, entirely outside WordPress, and nothing inside WordPress can see or control those.

Check: A free plugin called WP Crontrol shows every task WordPress knows about (Tools → Cron Events once installed) — look for anything unfamiliar, especially something that comes back after you delete it. Then, separately, check your hosting account's own cron job settings (on Hostinger, for example, this is under Advanced → Cron Jobs); it's a different system, and WordPress can't show it to you.

Click to expand

5. mu-plugins

WordPress has a special category of plugin called a "must-use plugin," or mu-plugin. Unlike a normal plugin, it loads automatically on every page and can't be switched off from the usual Plugins screen. This is the one almost no cleanup checklist mentions, which is exactly why it works so well as a hiding spot: mu-plugins sit in a separate, read-only tab rather than the main plugin list, so a real check means opening the folder directly, not just glancing at the dashboard. One site owner described finding malware in exactly this folder and deleting it by hand through their host's file manager — "but it came back every time I removed it" — until they tracked down and removed the actual plugin that was recreating it.

Check: Using your hosting account's file manager, or a file-transfer program connected over SFTP, open the folder wp-content/mu-plugins directly, and check the "Must-Use" tab on the Plugins screen too. Anything there that you did not deliberately install is an investigation trigger, not automatic proof of malware: hosts and management services sometimes add legitimate mu-plugins. Verify who installed the file and what it does before removing it. If you don't have direct access to your site's files, this is worth asking your host about by name.

6. Theme Files

An active WordPress theme can include a file called functions.php that WordPress loads with the theme. Because code there can run across the site, it is a popular place to hide instructions that keep re-inserting malware. Security research from 2025 shows attackers increasingly favor quietly editing a real, existing file rather than dropping an obviously new one — the tampered file still looks, and mostly behaves, like the original.

Check: Compare your active theme's files against a clean copy from wherever you originally got it (WordPress.org for free themes, your account with the seller for premium ones), and check when each file was last modified; a handful of files with unusual dates compared to the rest is worth a closer look. A premium or pirated ("nulled") theme usually can't just be reinstalled with one click if there's no clean copy on file, and using nulled software at all carries its own risk regardless of whether the site's been hacked before.

Click to expand

7. Hidden Database Content

Spam doesn't have to look like a file you can find and delete. It can sit directly inside a page's content, metadata, options, or page-builder data, styled so it's invisible: shrunk to a couple of pixels or moved off-screen. Better Search Replace, a popular database search-and-replace plugin, supports serialized data. Even so, a simple search can miss content that is encoded, compressed, split across fields, stored outside the tables selected for the search, or generated dynamically. A search that returns zero results therefore does not prove the page is clean. None of this necessarily appears in WordPress's normal visual editor, because the editor can render the styling along with the content, hiding it from you the same way it is hidden from visitors. It's a more common experience than it sounds: one site owner discovered Google had indexed "700+ pages of articles about debt consolidation and loans" coming from their site that, as far as they could tell from the pages they could actually see, didn't exist at all.

Check: The easiest version of this needs no technical skill: open Google Search Console, inspect the affected URL, select "Test Live URL," and then choose "View Tested Page." Check both the rendered screenshot and the returned HTML; together they show what Google's inspection crawler received and rendered at that moment, including content the normal editor may not reveal. For a deeper look, someone with access to the site's database can search it directly using a tool like phpMyAdmin, usually available through your host, rather than relying on the visual editor.

Click to expand

8. Outdated Plugins

This one isn't really a way back in on its own; it's the open door in the first place, and it's worth checking again after cleanup, not just before. According to Patchstack's 2026 WordPress security report, plugin vulnerabilities accounted for 91% of the 11,334 new WordPress security flaws discovered in 2025, a 42% jump from the year before, and 46% of those had no fix available yet at the time they were made public.

Check: Compare every installed plugin's version against a public vulnerability database like WPScan or Patchstack, not just the update badge in your dashboard, since that badge only tells you a newer version exists, not whether the one you're on is actually dangerous. Treat this as something to revisit regularly, not a one-time step during cleanup.

WordPress Reinfection Checklist

How Do You Know the Site Is Actually Clean?

Every check above is real and checkable, but there's no single moment where a checklist declares the job finished. That's a pattern real WordPress site owners run into constantly. In one real troubleshooting thread, after a site kept getting reinfected through multiple full restores, one experienced commenter put it bluntly: "this is an incident, forensic-cleanup problem now, not a plugin-hardening problem — a normal 'install security plugin and restore backup' cycle will just keep burning time if the persistence layer is still there." That's not a flaw in this advice, either — it's structural to how WordPress works. WordPress isn't a closed platform like Shopify or Wix, where the company running it patches every site centrally the moment a flaw is found. It's self-hosted software: each individual site has to apply its own patches, on its own schedule, built from plugins written by thousands of different developers of wildly different quality. That's also most of the reason WordPress sites get targeted as often as they do. According to Sucuri's own infection data, WordPress represents about 59% of websites whose content management system is known, while it made up roughly 95.5% of the infected sites in Sucuri's 2023 remediation dataset. Those figures are not directly comparable measures of risk: the latter describes Sucuri's sample, not all WordPress sites. A more useful ecosystem signal, per Patchstack's research, is that the vast majority of disclosed WordPress vulnerabilities each year (91% in 2025 alone) are found in plugins, not WordPress's own core software, and a predictable file structure makes the whole ecosystem cheap for automated bots to scan at scale.