Guide — reinfection, explained

WordPress site keeps getting hacked? Here’s why

You cleaned it. It came back. That is not bad luck — it means whatever let the attacker in the first time was never actually found or closed. Here is why that happens and the exact process that stops it for good.

Why does my WordPress site keep getting hacked after I clean it? Because a cleanup usually removes the visible malware but not the root cause. The attacker’s original entry point — an unpatched plugin, a leftover backdoor, a leaked password, or a nulled/pirated plugin — is often still open, so the same attacker or an automated bot simply walks back in. Stopping reinfection for good requires finding and closing the actual entry point, removing every backdoor (not just the obvious one), then hardening what let it happen — which is exactly what a manual root-cause audit is for.

If you have already run a scanner, deleted some files, changed your password, and it still came back, you are not alone — this is one of the most common patterns we see on small WordPress sites. The good news: reinfection almost always has a findable, fixable cause. It just cannot be found by another surface-level cleanup. If you are earlier in the process and need the general recovery steps first, see our website hacked recovery guide — this page picks up specifically on why WordPress sites relapse after that cleanup.

Why WordPress sites get reinfected after a cleanup

1. The backdoor was never fully removed

Attackers rarely rely on a single way back in. A typical compromise plants two or three backdoors — one obvious, the rest hidden — precisely so that removing the obvious one does not lock them out. A scanner that flags and deletes one infected file can leave a disguised backdoor sitting in a theme’s functions.php, a fake plugin folder, an innocuous-looking uploaded image with embedded PHP, or a WordPress cron job that quietly re-downloads malware on a schedule.

2. The original entry point was never found or patched

Cleaning malware answers “what got installed,” not “how did they get in.” If nobody identifies the actual vulnerable plugin version, the exposed upload folder, or the leaked credential that was exploited, that same door is still standing open after the cleanup. Whoever finds it next — the original attacker or a different automated scanner — walks straight back through it.

3. A nulled or pirated plugin/theme is still installed

“Nulled” (cracked, license-bypassed) plugins and themes are one of the single most common root causes of repeat WordPress infections. Many are deliberately modified before redistribution to include a backdoor baked into the code itself — so even a fresh install of the nulled file reinstalls the vulnerability. If a nulled plugin is still active anywhere on the site (including ones you forgot about), reinfection is close to guaranteed.

4. Shared hosting cross-contamination

On cheap shared hosting, many customer accounts run on the same server and sometimes share writable directories or a misconfigured permission structure. If a neighbouring site on the same server gets compromised, malware can spread sideways into your account even if your own WordPress install and plugins are perfectly patched. Cleaning your files does nothing if the server-level exposure is never checked.

5. Weak or reused admin credentials

If the admin password was ever weak, reused elsewhere, or shared over an insecure channel, changing it once after a cleanup is not enough — attackers who harvested it via credential-stuffing lists, phishing, or a keylogger will simply try it again, and automated bots retry known-breached passwords indefinitely. Every admin and editor account, not just the main one, needs a unique password and 2FA.

6. No root-cause investigation was ever done

This is the pattern underneath all of the above: a plugin scan, a host’s automated cleanup tool, or a quick manual delete of suspicious files treats the symptom. None of these are built to answer the investigative question “what specific weakness did this attacker use, and is it still present?” Without that answer, every cleanup is temporary.

What actually stops reinfection

Stopping the cycle takes three ordered steps — skipping the order is why DIY cleanups often fail. Doing them out of order (for example, hardening before finding the entry point) just means attackers exploit the same hole through a different path.

Step 1 — Find the actual entry point

Before touching anything else, establish how the attacker got in. That means checking plugin and theme versions against known vulnerabilities as of the infection date, reviewing server access logs for the request that first touched a suspicious file, checking whether any installed plugin or theme is nulled, and confirming whether credentials were reused or leaked in a breach. Guessing here wastes the rest of the effort.

Step 2 — Remove every backdoor, not just the one you found

This means a full manual review of core, theme, and plugin files against known-clean versions (a diff against the official WordPress.org repository catches modified core files fast), a check of the wp_users table for admin accounts nobody recognizes, a review of scheduled cron tasks, and a check of the uploads folder for executable files that should never be there. Automated scanners catch known signatures; this step is about catching what a scanner has never seen before.

Step 3 — Harden so the same class of weakness cannot reopen the door

Once the site is genuinely clean, harden it: update everything (and remove anything abandoned or nulled), enforce unique strong passwords and 2FA for every account, restrict file-editing permissions in the WordPress admin, put a Web Application Firewall in front of the site if the entry point was request-based, and fix the file/folder permissions that allowed the original write. This is the step that turns “cleaned” into “actually fixed.”

Why a plugin scan alone cannot find the root cause

Security plugins are genuinely useful for day-to-day monitoring — they are just built for a different job than root-cause investigation. A scanner works by matching files against a database of known-bad signatures. That is fast and automatic, and it catches common, previously-seen malware reliably. What it structurally cannot do is reason about your specific site: it does not know which plugin version was exploited on your server on a specific date, it cannot tell a custom-written backdoor from a legitimate custom function, and it has no way to check whether your hosting neighbour was the actual source. Answering “how did this happen and is it still possible” requires a person looking at your logs, your file history, and your specific configuration — which is what a manual audit does that a scan cannot.

Plugin scan vs manual root-cause audit for a reinfected WordPress site
	Security plugin / auto-cleanup	Bug Circuit manual audit
Finds known malware signatures	Yes	Yes
Identifies the specific entry point used	Rarely	Yes — investigated directly
Finds custom/hidden backdoors with no known signature	No	Yes — manual file and log review
Checks for nulled/pirated plugins as a cause	Sometimes flags, rarely confirms	Yes
Checks shared-hosting cross-contamination	No	Yes, as one line item
Reviews admin accounts and credential exposure	No	Yes
Delivers a written report explaining the cause	No	Yes — evidence, severity, exact fix

How Bug Circuit helps if your site keeps getting hacked

Bug Circuit’s manual audit is a real person examining your WordPress install by hand for exactly the root causes above — not another automated scan. We are upfront that we productize this for small WordPress and Shopify-scale sites, so it is a focused, evidence-based engagement, not a multi-week enterprise incident-response retainer.

Free passive check first. Run our free security check — no login, no card, no impact on your site. It gives a yes/no read on visible critical exposure in seconds, which is a reasonable first step even before you decide on the paid audit.
$49 — one-time manual audit. A human engineer investigates plugin/theme versions, checks for nulled software, reviews for backdoors and rogue admin accounts, and checks hosting isolation where relevant. You get a written report: severity, evidence, and exact fix steps for each issue found.
$299 Signal — audit, fixes, and 3 months of cover. Everything in the audit, then we fix the high and critical issues with you, re-test, and keep watching for 3 months so a fresh reinfection attempt gets caught early instead of running unnoticed. Signal is currently discounted around 55% as a launch offer.

Every engagement starts only after you verify domain ownership and sign a recorded Authorization to Test — we test only what you own and have consented to, nothing else. Full terms and current pricing are on the pricing page.

Common questions

I already cleaned my WordPress site. Why did it get hacked again?

Because cleaning removes the malware, not the entry point. If a security plugin or your host deleted the infected files but never found how the attacker got in, that door is still open. The attacker (or their automated tooling) simply walks back through it and reinfects the site — often within days.

How long does it take for a hacked WordPress site to get reinfected?

It varies, but days to a couple of weeks is common. Many attackers leave more than one backdoor, and some infections are automated worms that re-scan previously compromised sites on a schedule. If your site comes back clean for a month or more after a proper root-cause audit, the entry point was almost certainly closed.

Can a security plugin like Wordfence or Sucuri stop reinfection?

It can slow it down and alert you faster, but it cannot guarantee reinfection stops, because it scans for known malware signatures — not for the human decision of how the attacker got in. A plugin will keep cleaning the same wound without ever finding what keeps cutting it open. Root-cause work is a manual, investigative task.

Is it my hosting company’s fault my site keeps getting hacked?

Sometimes partly, especially on cheap shared hosting where one neighbouring account’s malware can spread sideways through a shared server. But hosting is rarely the only cause — nulled plugins, weak passwords, and unpatched software on your own install are more common. A proper audit checks your hosting isolation as one line item, not the whole story.

Should I just rebuild my WordPress site from scratch?

It is one valid option, and sometimes the fastest, but only if you rebuild from a known-clean source, migrate content carefully (checking for injected code in posts and the database), and — critically — still find out how the original attacker got in. Otherwise you rebuild a clean house with the same unlocked door.

What is a backdoor and why does it survive a cleanup?

A backdoor is code an attacker plants specifically to let them back in later, deliberately disguised to survive a casual cleanup — a single obfuscated line added to a legitimate theme file, a fake plugin with a normal-sounding name, a scheduled task, or even a rogue admin user. Standard malware scanners look for known-bad signatures; a well-hidden custom backdoor often has none.

Keep reading

My website was hacked — what now?The general recovery pillar: containment, cleanup, and prevention.What does it cost to fix a hacked website?A realistic budget breakdown for cleanup, root-cause work, and prevention.The Japanese keyword hack, explainedSpam pages showing up in Google Search Console? Same reinfection pattern, one specific attack.Free website security checkPassive, no login — see your public exposure in seconds.Transparent pricingFree check · $49 audit · $299 Signal with fixes + 3 months of cover.

Stop guessing why it keeps happening — find the real cause

Run the free passive check first, then let a human engineer find the entry point a plugin scan cannot see.

Ready for the full manual audit? See transparent pricing →