Why does my WordPress site keep getting hacked (and how to stop it)?

Reinfection is a symptom, not bad luck

When a site gets hacked, cleaned, and hacked again, people assume the clean-up failed. Usually it didn’t — the visible malware really was removed. What wasn’t removed is the reason the attacker got in, and often a quiet backdoor they left so they could return.

The three doors attackers use most

In practice, the large majority of infections come through one of three things: an outdated plugin or theme with a known vulnerability, a weak or reused password (yours, or another user’s), or nulled/pirated premium software that shipped with malware baked in. None of these are exotic. All of them are avoidable.

Backdoors: why it comes back so fast

A smart attacker doesn’t just deface your site — they plant hidden scripts in obscure files or the database that let them re-enter even after you’ve reset passwords and updated everything. If those aren’t found and removed, your clean-up buys you days, not safety.

How to actually break the loop

Three moves, in order. One: a complete clean that includes hunting for backdoors, not just the obvious malware. Two: find and close the specific entry point. Three: harden the site — tighten file permissions, remove unused plugins, put a firewall in front of it, enforce strong logins — and then monitor it so anything new is caught early.

What this means for you

If you’ve cleaned your WordPress site more than once, stop treating each incident as a one-off. The door is still open. I’ve broken this exact reinfection loop on sites that had been through it repeatedly — the fix is always root-cause first, hardening second.

How to actually find a hidden backdoor

Sites that keep getting hacked usually share one thing: most people search for malware the wrong way. They scan for obviously bad file names. Then they stop. That's not enough. A real backdoor hunt starts with a diff. Download a clean copy of WordPress core. Match the exact version you're running. Compare every single file against it.

Anything different inside wp-includes or wp-admin needs an explanation. Plugins and themes need the same treatment. Compare them against their original source files, not your memory of what they looked like. Look for code squeezed onto one long line. Look for base64_decode used alongside eval() or gzinflate(). That combination almost always means obfuscation.

File permissions matter too. A file suddenly set to 777 is a warning sign. So is a PHP file sitting inside an uploads folder that should only hold images. This is the kind of check that finds why a site really does keep getting hacked. Sort every file by modification date. Look closely at anything touched around the time the site first got hacked. Attackers rarely change the file's name. They rely on you never checking the date.

One folder gets skipped constantly: mu-plugins. Files placed there load automatically on every request. They don't show up in the normal plugins list at all. This is a favorite hiding spot for exactly this reason. If you've never opened that folder before, open it now and check every file inside it.

The wp-config.php file deserves the same scrutiny. It's small, it's boring, and almost nobody reads it line by line. That makes it a quiet place to drop a single malicious line among the legitimate ones. Sites that keep getting hacked while the visible files always look clean, this file is worth a second look.

Check .htaccess too, at the root and inside wp-content. A single injected rewrite rule can silently redirect a portion of your visitors to a spam or phishing page. It won't affect every visitor, and it often won't affect you at all when you check the site yourself. That's exactly why it goes unnoticed for so long.

Why DIY clean-ups miss backdoors so often

A plugin-based malware scanner is built to catch known signatures. It's good at flagging files that match a database of past attacks, which is only half of what it takes to stop a site that will otherwise keep getting hacked. It's much weaker against something custom. A backdoor written specifically for your site has no signature to match yet. That's one reason a site can keep getting hacked even after running scan after scan.

Scope is the other problem. Most owners check the plugins folder. Maybe the theme too. They stop there. This gap is often the real reason sites keep getting hacked. They don't check the database for a rogue admin user. They don't check for a cron task quietly re-downloading malware every few hours. A backdoor doesn't need to live in a file at all. If your cleanup only ever looked at files, you've checked half the house.

This is exactly why a site keeps getting hacked after what felt like a thorough clean. The visible malware is gone. The mechanism that let it back in never was. It's not a failure of effort. It's a gap in where the search actually looked.

Backups make this worse in a way people don't expect. A backup taken after the initial infection captures the backdoor too. Restore from that backup later, thinking you're recovering a safe version, and you've just reinstalled the exact problem. Always check when the infection likely started before trusting any backup as clean.

Closing the door: outdated plugins and themes

"Update everything" is correct advice for anyone trying to stop a site that will otherwise keep getting hacked. It's also incomplete. If an outdated plugin was the entry point, updating it now doesn't undo what already happened. You need to know which plugin was vulnerable at the time of infection. Then check what files it wrote. Check what it changed in the database while it was open.

After that, the real fix is a habit, not a one-time update. Vulnerability databases publish disclosures the same day they're found. Attackers scan the internet for outdated versions within hours of that. A site updated weekly is a much harder target than one updated "whenever I remember." This single habit closes the most common door there is. It's also the cheapest fix on this entire list.

Not every plugin gets updated at the same pace, either. Some developers patch a disclosed vulnerability within a day. Others take weeks, and a few abandoned plugins never get patched at all. Check whether every plugin on the site is still actively maintained. An abandoned plugin with no recent updates is a standing invitation, even if nothing looks wrong with it today.

A staging copy makes this safer, too. Test updates there before pushing them live, so a bad update doesn't break the site while you're mid-fix. It's a small extra step. Skipping it is how some owners end up afraid to update at all, which is its own way of ensuring the site keeps getting hacked.

Closing the door: weak and reused passwords

A weak password isn't just "password123." It also means a password reused from another site. If that other site leaked its user database, the password is now public. Attackers run leaked password lists against WordPress login pages automatically. This happens all day, every day, on nearly every site online.

It doesn't matter whose password it is. Any user with a reused, leaked password is a working key to your front door. It doesn't have to be the owner's account. A forgotten editor account is just as dangerous. It's a common reason sites keep getting hacked through a door nobody thought to check.

Closing this properly means resetting every user's password. Not just the admin's. It also means auditing the user list itself. A backdoor account is often just a hidden WordPress user with admin rights, sitting quietly in a list nobody reviews. From there, two-factor authentication changes the math completely. A login limiter does too. Together they make password guessing far less useful to an attacker.

A password manager makes all of this easier in practice. It generates a unique password for every login, so one leak doesn't compromise the whole site. It's a small habit change with an outsized effect. Sites where every user has a unique password rarely keep getting hacked through the login form alone.

Why nulled and pirated plugins are their own category of risk

Nulled plugins are premium plugins with the licensing check stripped out. They're usually shared for free on sites that look legitimate. The appeal is obvious — why pay when it's free? The problem is who touched the code first. Whoever cracked the plugin had full access to modify it. Most nulled copies ship with a backdoor already built in.

This is different from a vulnerability in a real plugin. A vulnerability is a mistake. It gets patched eventually. A nulled plugin's backdoor is intentional. It won't show up in any changelog, because there is no honest changelog. It also won't get fixed by updating, since there's no legitimate update channel to pull from. You're stuck on whatever version you downloaded, indefinitely.

I've traced more than one repeat infection straight back to a single nulled plugin. Nobody even remembered installing it. It sat there for years, quiet, until it was reactivated remotely. This is one of the fastest ways to end up with a site that will keep getting hacked, with no obvious cause in sight. It also explains why a site can keep getting hacked right after a rebuild, if the same pirated plugin gets reinstalled out of habit.

It's not only plugins, either. Nulled themes carry the exact same risk, and so do "bundle" sites that resell dozens of premium plugins for one flat fee. The professional look of the site selling them means nothing. If the software wasn't purchased through the original developer, treat it as untrusted until proven otherwise.

What ongoing monitoring actually catches

A one-time clean-up is a snapshot. It tells you the site was clean at that exact moment. It says nothing about next week, when a new vulnerability gets disclosed in a plugin you're still running. Monitoring is what closes that gap. It's the difference between learning your site keeps getting hacked from an angry customer, or from an alert within the hour.

Good monitoring watches file integrity first. Any unexpected change to a core file gets flagged right away, not weeks later. It watches for new admin users appearing out of nowhere. It watches for logins from unusual locations. It watches for outbound connections that look like a compromised site phoning home to its attacker.

None of this replaces hardening. Monitoring is what catches the thing hardening didn't anticipate. It's the safety net underneath everything else, not a substitute for doing the earlier steps properly.

Speed of response matters as much as detection itself. An alert you see three weeks later is barely better than no alert at all. Whatever monitoring setup you choose, make sure it reaches someone who will actually act on it the same day. A missed alert is how a small, caught-early issue turns back into a site that keeps getting hacked in full.

A realistic timeline for breaking the cycle

Breaking a genuine reinfection loop isn't a same-day fix. Anyone promising that is skipping steps. The initial clean and backdoor hunt usually takes a few days. It depends on how deep the infection runs and how large the site is. Hardening happens alongside that work, not after it.

Confidence comes from time, not from one clean scan. I generally want to watch a site for several weeks after cleanup. That's long enough to see whether the same entry point gets probed again. If a site keeps getting hacked, rushing this stage isn't confidence. It's guessing dressed up as a finished job. Slower, verified work is what actually ends the pattern.

Site size and history change the timeline too. A small brochure site with a handful of plugins is faster to fully audit than a large store with years of accumulated code. A site that's changed hands between multiple developers often takes longer, simply because nobody currently involved knows its full history. None of that changes the goal — it only changes how long it honestly takes to get there.

What separates a real fix from a temporary one

A temporary fix removes what's visible, then stops. A real fix answers three questions. How did they get in? What did they leave behind? How will we know if they come back? Miss any one of those, and you don't have a fix. You have a pause before the next incident.

This is where WordPress security work stops being a one-time transaction. It becomes something closer to an ongoing relationship. Across more than 10,000 WordPress sites cleaned, one pattern holds steady. The sites that stop getting hacked are the ones that treated the first incident as a wake-up call. Not an inconvenience to clear off a to-do list. That mindset shift matters more than any single tool you install.

The same pattern shows up in the client relationships that last. Among the 573+ businesses I've secured, the ones with a 96% return rate for follow-up work are almost always the ones that fixed the root cause the first time. They didn't need a second emergency call, because there wasn't a second incident to make one about.

When it's time to stop troubleshooting it yourself

There's no shame in hitting a wall here. Backdoor hunting means comparing thousands of files by hand. It means knowing what normal WordPress code actually looks like. It means knowing which database tables attackers target first. That's a specialized skill. It comes from seeing the same patterns across many infected sites, not from reading a single guide.

If you've already cleaned it yourself and it keeps getting hacked anyway, pay attention to that. It's usually the clearest signal that something below the surface is still there. It's not a sign you did something wrong. It's a sign the problem needs a deeper look than a weekend and a scanner plugin can give it. That's normal, and it's fixable.