Your WordPress Site Keeps Getting Hacked Because the Real Backdoor Was Never Actually Found

If your WordPress site keeps getting hacked even after you’ve cleaned it, the problem usually isn’t a new attack. It’s an old one that never actually left.

Most cleanup guides stop the moment the malware is gone. They tell you to delete the bad files, update your plugins, and move on. That works for a few days, sometimes a few weeks. Then the redirects come back. Or a new admin account shows up that nobody on your team created. Or Google flags the site again, and you’re right back where you started.

A WordPress site that keeps getting hacked after cleanup almost always has a persistence problem, not a fresh compromise. Attackers plant backdoors or steal hosting-level credentials that survive a standard WordPress cleanup, then use that access to re-enter days or weeks later.

Why Your WordPress Site Is Getting Hacked

There are two separate questions hiding inside “my WordPress site keeps getting hacked,” and most cleanup advice only answers one of them.

The first question is how the attacker got in the first time. The second, and the one that actually explains reinfection, is how they’re managing to get back in after you’ve already cleaned the site. These are different problems with different fixes, and treating them as one problem is the single biggest reason WordPress hack cleanups don’t stick.

Getting in is usually the easier part to explain. Staying in, and coming back, is where most site owners lose the fight without realizing it.

How They Got In (The Entry Point)

The overwhelming majority of WordPress compromises start with an outdated or vulnerable plugin or theme. Patchstack’s vulnerability data puts it at roughly 96% plugins and 4% themes, with WordPress core rarely the culprit at all. Attackers scan the web for sites running known-vulnerable versions within hours of a patch going public, which means an unpatched plugin isn’t a minor risk sitting in the background. It’s an open invitation with a countdown clock attached.

Weak, reused, or stolen login credentials are the other major entry point. If a password was exposed in an unrelated data breach somewhere else on the internet, and that same password sits on your WordPress admin account, your site is already exposed even if nothing on your server has changed yet.

How They’re Staying In (The Persistence Problem)

Once an attacker is inside, getting in and staying in become two separate goals for them. They plant a backdoor, and it often has nothing to do with the plugin that let them in originally. That backdoor can live almost anywhere: disguised as a font file in a static assets folder, sitting at the web root, or hidden inside a theme’s functions.php file. A cleanup that only checks wp-content misses all of it.

Attackers also frequently create a hidden admin account, one that doesn’t show up on the normal Users screen because the backdoor filters it out of that view before WordPress ever displays it. The account is still sitting in the database. WordPress just isn’t showing it to you.

Then there’s the persistence method that survives almost every WordPress-level fix: stolen hosting credentials. SFTP passwords, SSH keys, or host control panel logins sit above WordPress entirely. Resetting your WordPress admin password does nothing to these. Two-factor authentication on your WordPress login does nothing to these either. If the attacker still has SFTP access, they can upload a fresh backdoor the moment you delete the old one, and the site looks reinfected within hours.

This is the core reason a WordPress site keeps getting hacked despite repeated cleanups. The visible malware gets removed, but the access that let the attacker plant it in the first place is never actually closed.

Before You Clean Anything, Preserve the Evidence

It’s tempting to start deleting suspicious files the moment you spot them. Don’t. Give it one hour first.

• Back up everything as-is. Every file, the database, all of it. This is your evidence copy, not your fix. You’ll compare against it later to confirm what got cleaned and what got missed.
• Request every log your host can give you. Web access logs, SSH logs, SFTP logs. Ask right away. Web logs often vanish after 48 hours, and some hosts never keep SFTP logs at all.
• Don’t assume the hack happened when you noticed it. Attackers often get in quietly and wait. An older backup you thought was safe might already have the same backdoor sitting inside it.

How to Clean a Hacked WordPress Site the Right Way (Step-by-Step)

The individual steps below aren’t unusual on their own. What matters is the order and being thorough enough at each one that you’re clearing the actual cause, not just the symptoms.

Remove the Malware First, Don’t Just Deactivate It

Deactivating a suspicious plugin through wp-admin doesn’t remove it. A standalone shell file will still run if someone requests it directly by URL, whether the plugin shows as active or not. The same goes for any backdoor sitting outside wp-content entirely, in a static folder, at the web root, or disguised as an image or font file. Delete the files. Deactivating is not the same as removing, and this single distinction is where a lot of WordPress malware removal attempts quietly fail.

This is exactly the gap a signature-based scanner tends to miss, since it’s built to match known malware patterns rather than analyze what a file is actually doing. A scanner built around behavior and pattern analysis, rather than signatures alone, has a much better chance of catching an obfuscated or custom backdoor that a traditional scanner would walk right past.

Rotate Every Secret

Update your WordPress salts and their corresponding salt values, using fresh, randomly generated strings.

This invalidates every existing login session immediately, which matters if an attacker has an active session open right now. Rotate your database password and any API keys the site uses as well. If a shell with code execution capability was live on the site, rotate everything a second time after removal, in case the attacker captured the new values before you finished cleaning up.

Reset Every Password, Not Just WordPress

Reset every WordPress user’s password. Then go further: reset your SFTP password, rotate or remove SSH keys you don’t recognize, and change your hosting account and control panel password. This step is where most cleanups quietly fail, and it’s exactly why a WordPress site keeps getting hacked even after a thorough-seeming cleanup. WordPress-level password resets don’t touch hosting-level access at all.

Audit Who Actually Needs Access

Once the immediate threat is handled, pull a list of every WordPress admin, host panel user, SFTP account, and SSH key. For each one, ask whether that person genuinely still needs that level of access to do their current work. Remove anyone who doesn’t. Downgrade anyone who has more than they need. This is the cheapest, most durable security improvement available to you, because it shrinks the number of credentials an attacker could steal to get back in, long before the next attack even starts.

When a Full Reinstall Makes More Sense Than a Manual Cleanup

If the infection is old, the file changes are too widespread to trust a manual review, or you just don’t have time to comb through every file by hand, a full reinstall is often faster and safer than trying to surgically clean a site you can’t fully account for. The step-by-step manual cleanup later in this post is still the right call when you can pin down exactly what changed. This is the faster path for when you can’t.

A reinstall isn’t a substitute for the persistence work covered later on. It clears out WordPress-level malware, but it does nothing about stolen hosting credentials or an attacker who still has your SFTP password. Think of this as the first half of the job, not the whole thing, and keep reading once you’re done here.

Assume Every Site on the Same Hosting Account May Be Infected

If you manage more than one WordPress install under the same cPanel account, a compromise on one site puts the others at real risk too, even if they still look untouched. Don’t clean the obvious site and call it done.

Save Your Database Connection Details First

Before you delete anything, open wp-config.php and copy your database name, username, password, and host. You’ll need these to reconnect a fresh WordPress install to your existing database.

Delete the WordPress Installation

Remove the core files entirely rather than trying to clean them:

• wp-admin
• wp-includes
• The WordPress root files, including wp-config.php once you’ve saved the credentials from it, along with the rest of the root-level PHP files

Keep only:

• wp-content/uploads, since this holds your actual media files, not code
• Your child theme, if you use one, but read through its code line by line first. A backdoor hiding in functions.php is one of the most common places attackers plant something that survives a partial cleanup.

Install a Fresh Copy of WordPress

Don’t try to salvage the existing core files, even the ones that look untouched. Download a new copy directly from WordPress.org and connect it to the database using the credentials you saved earlier.

Reinstall Every Plugin and Theme From Trusted Sources

This step is where a lot of reinstalls quietly reintroduce the same problem:

• Download fresh copies from WordPress.org or the original vendor’s site, not from anywhere else.
• Don’t restore plugins or themes from your old backups. If the backdoor got in through a plugin, an old backup likely still has the same vulnerable version, or the backdoor itself.
• Skip anything that hasn’t been updated in six months or more. An abandoned plugin isn’t just outdated, it’s a door that’s never getting patched.
• Never use a nulled plugin or theme. Nulled copies are a common way backdoors get distributed in the first place, since they’re modified versions of the real thing.

Run a Full Malware Scan

Before you consider the reinstall finished, scan the entire site to confirm nothing survived the wipe.

Ultimate Security’s AI Malware Scanner analyzes plugin and theme behavior rather than matching known signatures alone, which gives it a better shot at catching anything unusual that made it back in through a plugin reinstall.

Keep the Database Unless You Know It’s Compromised

Some incident responders report that database-level infections are uncommon compared to file-based ones, with most malware showing up as injected PHP files rather than tampered database content. If you’re working from a specific source for that figure, it’s worth confirming before this goes live as a stated number. Either way, if you keep the database, run the query later in this post to check for a hidden rogue admin account, since that’s a database-level change a plugin scan won’t catch.

Close the Door, Not Just the Room

This is the step that actually determines whether your WordPress site keeps getting hacked or finally stays clean. Everything above cleans the room. This closes the door.

Whatever the original entry point was, once an attacker is inside, they typically create their own way back in that doesn’t depend on that original vulnerability at all. An extra SFTP user. An SSH key you didn’t add. Continued access to your host’s control panel. That access sits above WordPress entirely, which means it survives file cleanups, plugin updates, and WordPress password resets without being touched by any of them.

If you’ve cleaned a site, updated everything, and it still comes back within days, this is almost always why. The attacker never lost the door they built for themselves the first time around.

Closing it means going through the hosting side deliberately, not just the WordPress dashboard:

• Change your SFTP password. Not just your WordPress admin password. This is a separate credential that WordPress-level fixes never touch.
• Review your SSH keys and remove anything you don’t personally recognize. A single unfamiliar key is enough to let an attacker back in without needing a password at all.
• Change your hosting account and control panel password. This is the top-level access point, and it’s often overlooked because it feels separate from “the site.”
• Turn on multi-factor authentication for the host control panel itself, not just WordPress logins. WordPress-level 2FA has no effect on SFTP or SSH access.
• Have anyone with access to the site run a malware scan on their own computer. A stolen credential often comes from malware on someone’s machine, not a direct attack on the server.
• Stop saving SFTP passwords in desktop FTP clients. Saved credentials sitting in a local app are a common target for exactly the kind of theft described above.

How to Keep Your WordPress Site Clean for Good

A clean scan today doesn’t guarantee a clean site next month. New vulnerabilities get disclosed constantly, and attackers don’t stop scanning just because your site passed one check. Staying clean is an ongoing habit, not a one-time task, and this is the layer most WordPress site owners skip entirely once the immediate crisis is over.

Watch for Abandoned Plugins

Keep vulnerability monitoring running continuously rather than only after something feels wrong. The Vulnerability Scanner covers this by checking your plugins, themes, and WordPress core against known CVEs on an ongoing basis, and it’s worth paying attention to more than just outdated items. An outdated plugin usually gets patched once someone notices. A plugin that’s been abandoned by its developer never will, which makes it a permanent open door rather than a temporary one, and it’s the kind of risk that’s easy to miss without a scan flagging it specifically.

Revisit your access list periodically, not just right after a hack. People change roles, contractors finish projects, and old accounts quietly accumulate access nobody remembers granting. A quarterly pass through who has WordPress, hosting, SFTP, and SSH access closes the same kind of gap that caused the original problem before it became one again.

Keep Self Defense and deactivation alerts turned on permanently, not just during a cleanup. It’s the layer that tells you immediately if anyone, including an attacker who’s found a new way back in, tries to switch off your protection.

None of this replaces the deep, one-time forensic work covered earlier and in the companion playbook. It’s the layer that sits on top of that work and keeps you from having to repeat it in six months.

Frequently Asked Questions

Conclusion

WordPress site keeps getting hacked because cleanup alone rarely closes the persistence gap: the backdoors, hidden accounts, and hosting-level credentials that let an attacker walk back in. Preserve the evidence first, remove the malware and rogue access before rotating secrets, close hosting-level credentials the same day you clean the files, and keep scanning on a schedule instead of stopping after one pass. Get that right, in that order, and a hacked WordPress site stays fixed instead of becoming a repeat problem.