WordPress Attacks in the Last 10 Years: Every Major Hack, How to Detect It, Remove It and Stop It Coming Back

Your WordPress site probably looks fine to you right now. That proves almost nothing. For ten years, the most profitable WordPress attacks have been designed to be invisible to the site owner and visible only to Google, to visitors from search, or to people on a different device. Owners find out weeks or months later — from a customer, from a traffic crash, or from a Google warning.

This guide does three jobs in one place. First, it lists the major WordPress attacks from 2016 to 2026, so you can recognise which era — and which pattern — you are dealing with. Second, it gives you the exact checks to confirm an infection. Third, it gives you a complete removal protocol and a prevention checklist, in the right order. Cleaning a hacked WordPress site in the wrong order is why most “cleanups” fail and the hack comes back within days.

The fix, in short:

1. Confirm it properly: check your site the way Google sees it, not the way you see it — cloaked attacks hide from owners on purpose.
2. Find every hiding place: files, database, cron jobs, hidden admin users, mu-plugins and .htaccess. Modern WordPress malware lives in several at once.
3. Remove all of them together: miss one persistence point and the rest rebuild the infection, sometimes within an hour.
4. Close the door it came through: update or delete the vulnerable plugin/theme, and rotate every password and key — cleanup without this step is temporary.
5. Clean Google afterwards: remove spam URLs, resubmit your sitemap and request re-indexing of your real pages, or the spam stays in search results long after your server is clean.

1. What a “WordPress Attack” Actually Is

WordPress core — the software you download from wordpress.org — is rarely the way in. Across the last three years, security researchers at Patchstack recorded 7,966 new vulnerabilities in the WordPress ecosystem in 2024 and 11,334 in 2025. Roughly 9 out of 10 were in plugins, most of the rest in themes, and only a handful in core itself.

An “attack” is usually a chain, not a single event:

1. Entry — a vulnerable plugin or theme, a weak or reused admin password, a pirated (“nulled”) plugin, or an unpatched file-upload flaw.
2. Control — the attacker creates a hidden admin account, uploads a web shell (a small file that lets them run commands on your server), or drops a loader that runs before everything else.
3. Money — your site is then used for what actually pays: gambling and pharma SEO spam shown only to Google, redirecting your visitors to scams, stealing WooCommerce payments with a card skimmer, mining cryptocurrency, sending spam email, or selling access to your site to the next attacker.
4. Persistence — backup copies of the malware are hidden in the database, in a scheduled cron job, and in folders most owners never open, so deleting the one file you found does not end it.

That chain explains the single most important fact in this guide: the visible symptom (spam pages, a redirect, a defaced homepage) is the least important part of the infection. Treating only the symptom is the most common and most expensive mistake site owners make.

The attack styles have rotated over ten years — defacement in 2017, redirects and malvertising in 2019, fake browser updates in the early 2020s, fake CAPTCHA pages in 2025, poisoned plugin updates and AI-run attacks in 2026. The chain underneath them has stayed almost exactly the same.

2. The 10-Year Timeline: Major WordPress Attacks, 2016–2026

This is not every vulnerability — there are now thousands a year. These are the incidents that changed the pattern, hit very large numbers of sites, or started a campaign that is still running.

2016–2017: Mass defacement and the birth of cloaked SEO spam

Pharma hack and Japanese keyword hack (ongoing from this era). Attackers injected spam that appeared only when Google’s crawler visited, so owners saw a clean site while Google indexed pages selling pharmaceuticals or fake designer goods in Japanese. This “show it to Google, hide it from the owner” trick — called cloaking — is still the core technique behind casino spam in 2026.

WordPress REST API defacement — February 2017. A flaw in WordPress 4.7.0 and 4.7.1 allowed anyone, without logging in, to change any page through the REST API. Within days of disclosure, more than 1.5 million pages on over 39,000 sites were defaced across around 20 separate campaigns. Lesson that still holds: the patch existed before the attacks peaked — the sites that were hit were the ones that had not updated.

Balada Injector begins — 2017. A long-running campaign that injects malicious code into WordPress files and databases, redirecting visitors to fake tech-support pages, lottery scams and push-notification scams. Sucuri estimates it has infected over one million sites since 2017, in waves every few weeks, each wave exploiting whichever plugin flaw was disclosed most recently.

SocGholish / FakeUpdates begins — 2017. A JavaScript malware framework that shows visitors a convincing “your browser is out of date” prompt. Accepting it installs a remote-access trojan, often the first step toward ransomware. It ran for nine years before a coordinated law-enforcement action in June 2026 seized its servers and cleaned 14,971 compromised WordPress sites.

2018–2020: Plugin privilege escalation at scale

WP GDPR Compliance — November 2018 (CVE-2018-19207). A plugin rushed onto 100,000+ sites to comply with Europe’s new privacy law contained a flaw that let unauthenticated attackers change site settings so that anyone could register — as an administrator. Attackers created their own admin accounts and took full control. Lesson: a plugin installed in a hurry, under deadline pressure, gets less scrutiny — attackers know this and time campaigns around it.

Social Warfare, Yuzo and Yellow Pencil wave — 2019. A cluster of popular social-sharing and design plugins were exploited together to inject redirects and malvertising. None of the flaws were in WordPress core; all arrived through extensions site owners had added for features, not for security-critical functions.

WP File Manager — September 2020 (CVE-2020-25213). An unauthenticated remote-code-execution flaw in a file-manager plugin installed on about 700,000 sites. Attackers uploaded PHP web shells hidden inside image files. Wordfence blocked over 450,000 exploit attempts in the first few days. Lesson: any plugin that can upload or manage files is a high-value target and should be removed when it is not actively needed.

2021–2022: Backup plugins, builders, botnets and fake plugins

Kaswara Modern WPBakery Addons — CVE-2021-24284. A critical (10.0) unauthenticated file-upload flaw in a page-builder add-on. It was still being mass-exploited in 2022, a full year after disclosure — proof that old, forgotten add-ons remain useful to attackers long after the news cycle moves on.

UpdraftPlus — February 2022 (CVE-2022-0633). A flaw in the popular backup plugin, installed on over 3 million sites, allowed any logged-in user — even a lowly subscriber account — to download the site’s most recent backup, including its database. The flaw was serious enough that WordPress.org force-pushed an automatic update to every site running the plugin.

Elementor — April 2022. An authenticated remote-code-execution flaw in the website builder used by over 5 million sites, introduced in version 3.6.0. Builder plugins are attractive targets precisely because they are on so many sites and run with broad permissions.

BackupBuddy zero-day — September 2022 (CVE-2022-31474). Around 140,000 installs, and roughly 5 million exploitation attempts recorded by Wordfence. “Zero-day” means attacks began before a fix was available — the reason a firewall with virtual patching (Section 8) matters.

Ninja Forms forced update — 2022. Over a million sites using the forms plugin were automatically updated by WordPress.org to close a critical flaw believed to be under active exploitation. Contact-form plugins recur throughout this timeline — remember this when you reach the case study in Section 5.

47,000 malicious plugins — 2022 research. Academic researchers (the YODA study) found 47,337 malicious plugins installed on 24,931 real websites, including 3,685 that had been sold through legitimate marketplaces. Not every plugin that looks professional is safe, and a marketplace listing is not a security audit.

GoTrim botnet — late 2022. A botnet written in the Go language that did nothing sophisticated at all: it scanned for WordPress sites and brute-forced admin passwords at scale, from many IPs at once so no single IP looked abusive. Weak and reused passwords fed it.

2023–2024: Record plugin flaws and instant exploitation

Essential Addons for Elementor — May 2023 (CVE-2023-32243). An unauthenticated privilege-escalation flaw in a plugin on over 1 million sites, allowing attackers to reset any user’s password, including administrators’. Wordfence recorded about 5 million probing scans in a single day after disclosure — attackers first map which sites run the plugin, then exploit the list.

WooCommerce Payments — March 2023 (CVE-2023-28121). A critical flaw in the payments plugin on 500,000+ stores that could give an attacker unauthorised admin access. Payment plugins sit at the top of the target list because admin access to a store can be turned into stolen card data.

Credential stuffing at record scale — 2023. Wordfence reported blocking over 100 billion credential-stuffing attacks in a single year — automated attempts using username/password pairs leaked from other services’ breaches. If your WordPress admin password has ever been used anywhere else, assume it is on one of these lists.

LiteSpeed Cache — August 2024 (CVE-2024-28000). An unauthenticated privilege-escalation flaw in a caching plugin installed on over 5 million sites, allowing attackers to create administrator accounts without logging in. Even a “performance” plugin, not just feature plugins, can hand over the whole site.

Really Simple Security — November 2024 (CVE-2024-10924). An authentication-bypass flaw rated 9.8 out of 10, affecting over 4 million sites running a security plugin, exploitable by an unauthenticated attacker to log in as any user. The hardest lesson of the decade: installing a security plugin is not the same as being secure, and every plugin — including security plugins — adds its own attack surface.

Bricks Builder — February 2024 (CVE-2024-25600). Unauthenticated remote code execution in a site builder, exploited in the wild within days of disclosure.

Balada Injector in 2024. The 2017 campaign was still running seven years later, infecting over 149,000 sites in 2024 alone, including waves through the Popup Builder plugin flaw (CVE-2023-6000) that hit 7,100+ sites in January and a further 3,900+ in March.

2025–2026: Fake CAPTCHAs, poisoned updates and AI-run attacks

A record year — 2025. Patchstack counted 11,334 new WordPress ecosystem vulnerabilities in 2025, up 42% on 2024. About 46% had no fix available when they were publicly disclosed, and for the most heavily exploited flaws the median time from disclosure to mass attack was around five hours. The window between “a flaw is announced” and “your site is being scanned for it” is now measured in hours, not weeks.

OttoKit (formerly SureTriggers) — 2025 (CVE-2025-27007). A privilege-escalation flaw in an automation plugin on 100,000+ sites, chaining into remote code execution.

ClickFix and ClearFake — 2025. Compromised WordPress sites were used to display fake “verify you are human” CAPTCHA pages and fake Cloudflare checks. Following the on-screen instructions installed information-stealing malware on the visitor’s own computer. GoDaddy counted 33,290 WordPress sites carrying ClickFix variants in 2025 and 27,349 carrying ClearFake. The victim is no longer just the site owner — it is the site’s customers.

Supply-chain / poisoned-update attacks — 2026. Several incidents followed a new pattern: instead of breaking in, attackers got malicious code shipped in through a plugin’s own trusted update channel — a plugin portfolio acquired by a new owner who inserted a backdoor that activated months later, a vendor’s build pipeline being compromised, and tampered Pro plugin builds served for a few hours from a forgotten old update server. WordPress.org closed 31 plugins in the largest of these cases. Lesson: “I only install updates from the official source” is necessary, but no longer sufficient on its own — you also need file-change monitoring to notice what an update changed.

StopAndProtect — 2026. A single criminal operation ran ClickFix lures across roughly 2,000 hacked WordPress sites, logging thousands of infected visitor computers.

Mass exploitation campaign — June 2026. Researchers uncovered an exposed attacker server holding target lists and exploit tooling for WordPress and other platforms, with 25,195 sites carrying confirmed or validated compromise evidence. The WordPress flaws it worked through were mostly arbitrary-file-upload bugs — in Breeze Cache, ThemeREX Addons, Ninja Forms file uploads, Gravity Forms, Simple File List and others, including the old WP File Manager flaw from 2020, still useful six years on.

CyberXero / wp2shell — October 2026. In the first widely reported AI-orchestrated WordPress campaign, an attacker used an AI coding agent to run automated exploitation: in one recorded run it scanned 4,708 targets, gained access to 429 WordPress admin panels and planted 32 web shells in 61 seconds, by abusing a flaw in the WordPress REST API batch endpoint to inject SQL, create a rogue admin and install a shell disguised as a plugin. The defence implication is uncomfortable but clear: if attacks are automated end-to-end, scanning and patching cannot be a monthly manual chore any more.

Cloaked casino spam — November 2026 (and ongoing). The oldest pattern in this timeline, still fully alive: Indonesian gambling operations (brands such as DINSEYTOTO, EBONITOTO and SBOBET appear again and again) plant static spam folders and a fake sitemap on a compromised site, serve gambling pages to Google’s crawler and to visitors arriving from Google, and serve the real site to everyone else. Section 5 tells this one from the inside, because it happened to us.

The through-line of ten years: entry is almost always a plugin, a password, or a pirated theme. The payload changes — defacement, redirect, skimmer, spam, stealer — the chain does not.

3. How to Confirm Your Site Is Hacked: 6 Checks, in Order

Run these in order and stop treating it as a suspicion the moment one of them fires. “My homepage looks normal” is not one of the checks.

Check 1: Search Google the way a customer would

Search these, replacing your domain:

site:yourdomain.com casino
site:yourdomain.com slot
site:yourdomain.com betting
site:yourdomain.com viagra
site:yourdomain.com "free spins"

Also search your own business name and look past the first few results. One single spam result in Google’s index is confirmation — Google cannot index a spam page your server never served to its crawler. Note the exact spam URLs; you will need the list in Section 7.

Check 2: Fetch your site as Googlebot

Cloaking means your browser is shown clean content, so compare what two different visitors receive:

# What Googlebot receives
curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://yourdomain.com/ | head -200

# What a normal browser receives
curl -A "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)" https://yourdomain.com/ | head -200

If the outputs differ — gambling words, hidden links, or extra pages appearing only in the Googlebot version — you have the cloaked variant. No terminal access? In Google Search Console, use URL Inspection on a suspicious URL, open “View crawled page” and compare the HTML with what your own browser shows. Also test with a Google search referrer and from a phone on mobile data: some variants cloak by referrer or by device instead of by user-agent.

Check 3: Look for an indexed-URL spike in Search Console

In Search Console → Indexing → Pages, compare your indexed count with 90 days ago. Spam generators create URLs automatically, so a small business site jumping from a few hundred indexed pages to several thousand — or tens of thousands — almost overnight is a classic sign. Check your sitemap file too: if sitemap.xml at your domain root is a static file you did not generate, or it lists folders you never created, treat that as a planted attack file, not a plugin glitch.

Check 4: Inspect the database for encoded payloads

File scanners cannot see this layer. In phpMyAdmin (or via your host), run:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE LENGTH(option_value) > 5000
   OR option_value LIKE '%base64_decode%'
   OR option_value LIKE '%eval(%'
   OR option_value LIKE '%gzinflate%'
ORDER BY size DESC
LIMIT 20;

A large result is not automatically guilty — legitimate plugins store large settings too. What matters is whether you recognise the option name and the plugin it belongs to. Unfamiliar options with long encoded values, options named like SEO or cache “boosters” that no installed plugin claims, and any occurrence of base64_decode / eval( / gzinflate inside options, posts or cron data deserve a line-by-line look. In our own audit (Section 5), this check returning clean was equally valuable information: it proved the infection was file-based, not database-persistent, and changed the cleanup plan.

Check 5: Hunt for files that should not exist

On the server (file manager, SSH or your host’s scanner), look for:

• PHP files inside wp-content/uploads/ — uploads should hold media, not code. Any .php there is suspicious by default.
• Folders at your site root or inside it named exactly like your real pages (about-us/, contact/, blog/) but containing a single static index.html with spam content — a favourite casino-spam planting method.
• Root files that are not WordPress: a hand-made sitemap.xml, rss.xml, feed.xml, llms.txt or robots.txt that your SEO plugin did not generate, .zip archives of your whole site that you did not create, and stray files such as a large default.php that no plugin owns.
• Anything in wp-content/mu-plugins/ you did not knowingly install — files there run on every request and cannot be switched off from wp-admin.
• Files modified in the last 30 days that you cannot explain:

find /path/to/yoursite/ -type f -mtime -30 -name "*.php" -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort
grep -rEl "eval\s*\(\s*base64_decode|gzinflate\s*\(\s*base64" /path/to/yoursite/

Check 6: Audit users, cron and settings an attacker would change

• Users: list every administrator, including by database (a hidden admin may not appear in wp-admin):

SELECT u.ID, u.user_login, u.user_email, u.user_registered
FROM wp_users u
INNER JOIN wp_usermeta m ON u.ID = m.user_id
WHERE m.meta_key = 'wp_capabilities' AND m.meta_value LIKE '%administrator%'
ORDER BY u.user_registered DESC;

• Cron: inspect the cron row in wp_options for scheduled jobs you do not recognise — a reinstall job is a standard persistence trick.
• Settings: check that your site URL, permalink structure, “anyone can register” setting and default new-user role have not been changed (the exact trick used in the 2018 WP GDPR attack), and review any new Search Console owners or analytics properties you did not add.

4. Why Your Security Plugin Missed It

Owners are usually running Wordfence, Sucuri, MalCare or a similar plugin when they get hacked, and feel doubly betrayed. There are three structural reasons scanners miss modern WordPress malware — understanding them stops you relying on a green “scan clean” tick as proof of safety.

Reason 1: The malware lives where the scanner does not look. A scanner that compares files against known-good copies will not open your database, your cron options, or the static folders planted outside WordPress’s folder structure. A file scan can honestly report “clean” while spam is being generated from the database or served from planted folders the scanner never walks.

Reason 2: The malware runs in the same process as the scanner. A security plugin is WordPress code running inside WordPress, alongside the infection. A sufficiently established loader can suppress notices, whitelist itself, or deactivate the security plugin. A scan that runs from inside the thing it is scanning has a built-in blind spot; server-side scanning from your host, which runs outside WordPress, does not share it — use both, not either/or.

Reason 3: Cloaking is fingerprint-aware. The same mechanism that shows spam only to Googlebot can show clean content to a scanner’s requests. If the loader recognises the scan, it behaves. This is why Check 2 above — fetching as Googlebot yourself — catches infections that automated scans reported as clean, and why you should verify a cleanup by fetching live pages as Googlebot, not just by re-running the scan that missed it the first time.

None of this means security plugins are useless — a good firewall blocks the entry attempts that start most chains in this timeline, and that is where they earn their keep. It means a plugin is one layer, not a verdict.

5. Anatomy of a Modern Infection: The 6 Persistence Points

A professional WordPress infection is not one file. It is a small system, deliberately redundant:

1. The loader in the database. An encoded payload stored in wp_options (under an innocent-sounding option name) or in post content, decoded and executed on every request, rendering spam pages for URLs that do not exist as real posts.
2. Doorway pages via rewrite rules or planted folders. Either injected .htaccess rules that route invented URLs (/casino-bonus-….html) to a single rendering script, or — simpler and increasingly common — physical folders dropped on the server, each holding a ready-made spam page. One script, or one folder template, can put thousands of URLs in front of Google.
3. Hidden links in real content. Spam anchors injected into your genuine posts inside invisible containers, so your real pages’ authority is spent ranking the attacker’s links.
4. A hidden administrator. An admin account inserted directly into the database, sometimes hidden from the wp-admin user list, kept purely to reinstall everything after you clean up.
5. A cron reinstall job. A scheduled WordPress cron event that periodically checks whether the payload still exists — and re-downloads it from the attacker’s server if you deleted it.
6. A mu-plugin or modified core/theme file. A file in wp-content/mu-plugins/, or a few lines added to your theme’s functions.php or a core file, guaranteeing code runs on every request before most plugins load.

Remove any five and the sixth rebuilds them. This is the whole answer to the most common question in Section 10: “Why does it keep coming back?”

6. Step-by-Step Removal Protocol

Work in this order. Back up first, change nothing until the backup exists, and do not announce “clean” until Step 9 passes.

Step 0 — Back up the infected site, labelled as infected. Files and database, stored off the server. You need it for evidence and for rollback if a cleanup step breaks the site — and the label stops anyone restoring the infected copy later by mistake.

tar -czf infected-backup-files-$(date +%Y%m%d-%H%M).tar.gz /path/to/yoursite/
mysqldump -u USER -p DATABASE > infected-backup-db-$(date +%Y%m%d-%H%M).sql

Step 1 — Put the site in maintenance mode. Stop serving spam and stop taking orders, form entries or sign-ups into a compromised database while you work.

Step 2 — Find the suspicious files. Use Check 5: recently modified PHP, PHP in uploads, planted slug folders, unknown root files, unknown mu-plugins. Quarantine (move out of the web root) rather than deleting anything you are unsure about, until the site passes Step 9.

Step 3 — Replace core, themes and plugins from clean sources. WordPress core, your active theme and every plugin, reinstalled fresh from their official sources — never “cleaned” by editing a line or two out of a file you cannot fully account for. Delete nulled or pirated plugins and themes outright; across this entire 10-year timeline they are the single most reliable entry point. Delete inactive plugins and themes you are not using — an inactive plugin’s files can still be executed by URL on many setups, and “inactive” does not mean “safe”.

wp core download --force --skip-content
wp plugin list --field=name | xargs -I {} wp plugin install {} --force

(Keep a safe copy of wp-config.php and your uploads folder aside first, and restore them only after scanning the uploads for PHP files.)

Step 4 — Clean mu-plugins. Delete everything in wp-content/mu-plugins/ that you cannot name a legitimate owner for. Your host’s own file there is the normal exception — verify it with the host rather than assuming.

Step 5 — Clean the database. Work on a copy first, and export the rows you remove. Remove unrecognised encoded options found in Check 4; strip hidden spam containers from post content carefully — words like “casino” can be legitimate content on some sites, so review matches instead of running a blind replace; delete rogue admin users found in Check 6 (from the database if they are hidden from wp-admin); and remove unrecognised cron jobs from the cron option. If your audit proves the database clean — as ours did — say so in your notes and do not churn it anyway; unnecessary database surgery is its own risk.

Step 6 — Clean .htaccess and wp-config.php. Remove rewrite rules that route URLs to scripts you do not own, restore the standard WordPress .htaccess block, and check wp-config.php for code before the opening <?php or after the “That’s all, stop editing!” line — there should be none.

Step 7 — Close the entry point. Identify, as best the evidence allows, how they got in: the vulnerable plugin (update it or delete it), the pirated theme (delete it), the weak password (Step 8), or the suspect form/plugin (keep it offline until it is replaced with a maintained, CAPTCHA-protected alternative). A cleanup that skips this step has a known expiry date.

Step 8 — Rotate every credential and regenerate salts. Hosting panel (with 2FA on), WordPress admins, database user, FTP/SFTP/SSH, and any API keys connected to the site. Then replace the salt keys in wp-config.php — this logs out every existing session, including the attacker’s. Change the database password properly in both places (hosting panel and wp-config.php together) — changing it in one place only takes your own site down.

Step 9 — Rescan from outside, then verify like Google. Run a server-side scan (your host’s scanner) and your security plugin scan. Then repeat Check 1 and Check 2 yourself: fetch key pages as Googlebot, compare with a normal fetch, and confirm spam URLs return a genuine 404. One caution from hard experience: do verification slowly and spread out on shared hosting — hammering your own recovering site with a fast full-site crawl can saturate its CPU and take it down again. One page at a time, with pauses, gets the same answer safely.

Only now take the site out of maintenance mode.

7. Cleaning Up Google’s Search Results

A clean server does not mean clean search results. Google keeps what it already indexed — in our case, spam snapshots of several real pages survived the cleanup in the index — until it re-crawls and drops them. Work this list:

1. Verify the spam is really gone as Googlebot (Check 2). Requesting re-indexing of a still-infected page wastes the request and can entrench the spam copy.
2. Request indexing for your real, important pages in Search Console → URL Inspection — homepage, main services, key posts — so the clean versions replace the spam snapshots.
3. Remove pure spam URLs via Search Console → Removals, using the planted patterns (for example the spam folder names). First confirm those URLs now return a real 404/410 on your server, not a soft 404 page with a 200 status.
4. Submit a fresh, genuine sitemap from your SEO plugin, and confirm the sitemap URL in Search Console points to it — not to any static file an attacker planted.
5. Answer any manual action with a reconsideration request that states plainly: what the infection was, what you removed, what you rotated, and what now prevents it. Vague requests get vague rejections.
6. Expect the right timeline: spam impressions typically fall away over 2–4 weeks as Google re-crawls; real-keyword performance usually recovers over 1–3 months, longer if thousands of doorway URLs were indexed for a long time. Anyone promising instant ranking recovery after a hack is selling something.

8. How to Prevent Reinfection: The Checklist That Actually Works

Most reinfections happen within two weeks of a cleanup, for one of four reasons: the entry point was never closed, the cleanup was file-only and a database/cron persistence point survived, credentials were never rotated, or the next plugin zero-day arrived before anyone updated. This checklist is ordered to close exactly those gaps:

Updates and inventory

• ☐ Core, plugins and themes set to auto-update where it is safe, and checked by a human weekly — remember, the 2017 defacements hit sites that had a patch available and simply had not applied it
• ☐ Every plugin audited quarterly: is it maintained, is it still needed, is there a version with a known flaw? Delete — do not just deactivate — anything unused or unmaintained for 6+ months
• ☐ No nulled/pirated plugins or themes, ever, on any site you care about
• ☐ File-upload and file-manager plugins removed unless actively required

Logins and permissions

• ☐ Unique passwords (never reused from any other service) for every admin, stored in a password manager — the 100-billion-attempt credential-stuffing machine is betting on reuse
• ☐ 2FA enforced for every administrator, and on the hosting account itself
• ☐ Registration off unless the site genuinely needs it; default new-user role never set above Subscriber/Customer
• ☐ Old staff, agency and test accounts deleted; admin list reviewed monthly against the database-level list (Check 6), not just wp-admin

Hardening

• ☐ DISALLOW_FILE_EDIT set in wp-config.php, so a hijacked admin session cannot edit PHP from the dashboard
• ☐ PHP execution disabled in wp-content/uploads/
• ☐ A firewall (WAF) with virtual patching, so newly disclosed plugin flaws are blocked in the hours before an official fix ships
• ☐ File-change monitoring switched on — this is also your early warning for a poisoned legitimate update (2026’s supply-chain pattern)

Detection and recovery

• ☐ Scanning in two places: a security plugin and your host’s server-side scanner
• ☐ Database and cron included in scanning, not files alone
• ☐ Daily backups stored off the server, with a test restore done at least quarterly — an untested backup is a hope, not a backup
• ☐ Uptime and Search Console monitoring: an indexed-URL spike or a new Search Console owner should reach a human the same day
• ☐ One page in a notebook (or a doc) listing: hosting login owner, domain registrar, backup location, and who to call — written before you need it at 2 a.m.

9. Emergency Checklist: The First 60 Minutes

If you have just confirmed a hack, do only this, in this order, before any deep cleaning:

1. Screenshot the spam Google result and note the time — evidence first.
2. Take the infected backup (Step 0).
3. Maintenance mode on.
4. Change the hosting panel password and turn on its 2FA.
5. Change your own WordPress admin password from a clean device.
6. Note every admin user you see; photograph the list if you have to.
7. Call or ticket your host and ask two specific questions: “Do you have a server-side malware scan you can run?” and “Do you have a clean backup from before [date the spam first appeared in Google]?”
8. Do not restore any backup until you know it predates the infection — loaders can sit dormant, so a clean-looking backup may already carry the payload.
9. Then start the full protocol in Section 6 — slowly, one change at a time, on a recovering shared server especially.

10. Frequently Asked Questions

Why does my site look normal to me but show casino or pharma spam in Google? Cloaking. The malware checks who is asking — Google’s crawler, a visitor arriving from a Google search, or a phone — and serves spam only to them. You, logged in from your usual browser, are served the real site precisely so you do not notice. Fetch your site as Googlebot (Check 2) to see what Google sees.

What is the most common way WordPress sites get hacked? Through plugins. Across recent years roughly 9 in 10 newly reported WordPress vulnerabilities were in plugins, and most successful infections chain a plugin flaw (or a pirated plugin) with persistence tricks. Weak and reused admin passwords are the close second — they powered over 100 billion credential-stuffing attempts in 2023 alone.

My security plugin says “clean”. Should I believe it? Believe it about the files it scanned, on the day it scanned them. Then still run the other layers: the Googlebot fetch, the database check, the admin-user audit and your host’s server-side scan. Our own infection survived file-level cleaning once and returned within a day; the database audit being clean was the clue that finally located the real mechanism — planted folders and a fake sitemap outside the scanned paths.

Why does the spam keep coming back after I clean it? Because a modern infection keeps 5–6 persistence points — database loader, doorway rules/folders, hidden links, a hidden admin, a cron reinstall job, and a mu-plugin or modified file. Deleting the visible spam addresses none of those by itself. Remove them together (Section 6), rotate credentials, and close the entry point; if it still returns, the entry point — not the cleanup — is what you have not found yet.

Should I just restore a backup and skip the cleaning? Only a backup you can show predates the infection, and even then run the confirmation checks and credential rotation afterwards. Spam loaders can sit dormant for weeks before activating, so “the backup looked fine” is not evidence it is clean.

How long until my Google rankings recover? Plan on weeks, not days. Spam pages usually drop out of the index over 2–4 weeks of re-crawling once they return genuine 404s; traffic and rankings on your real keywords typically recover over 1–3 months, and a site that carried thousands of indexed spam URLs for a year can take longer. The speed of your cleanup and re-indexing requests is the part you control.

Can a hacked WordPress site hurt my visitors, or only me? Your visitors too, in the current era. ClickFix-style infections use your trusted site to trick your customers into installing malware on their own computers, redirect campaigns send them to scams, and WooCommerce skimmers steal their card details. That is also why a hack can create legal notification duties if personal data may have been exposed — if that is in question, take legal advice rather than guessing.

How much of this can I do myself, and when do I need help? A careful owner with hosting access can run every check in Section 3 and most of the protocol in Section 6 — this guide is written for exactly that. Get experienced help when: you cannot find the entry point and it has reinfected once already; your store takes payments; you find a database-level payload you do not fully understand; or the site earns money daily and every hour of maintenance mode costs more than the help would. Whichever route you take, do not pay anyone who will not tell you which persistence points they found — “we cleaned the malware” without a list is how you get reinfected.

Are free and popular plugins safer than obscure ones? Popularity cuts both ways. A popular plugin is better maintained and a bigger target — LiteSpeed Cache, Really Simple Security, Elementor and UpdraftPlus in this timeline were all popular, mainstream plugins when they carried critical flaws. What protects you is maintenance speed and your own update discipline, not install counts.

What is the one change I should make today, before anything else on this list? Turn on 2FA for every admin and for your hosting account, and set plugins to auto-update. Those two settings, together, close the entry point behind the majority of incidents in this 10-year timeline — and they take under an hour.

11. Sources

• Patchstack, State of WordPress Security reports (2025 and 2026 editions) — vulnerability counts by year and component, exploitation timelines.
• Wordfence, 2024 Annual WordPress Security Report and Wordfence Threat Intelligence advisories — CVE-2020-25213, CVE-2022-31474, CVE-2023-32243, credential-stuffing volumes.
• Sucuri / GoDaddy, Hacked Website & Malware Threat Report (2023) and Balada Injector / SocGholish campaign research — malware campaign scales and detections.
• Guardian Gaze, WordPress Casino Spam: Detection, Removal & Prevention — casino-spam persistence model, database checks and cleanup structure: https://www.guardiangaze.com/blog/wordpress-casino-spam/
• CVE records and vendor advisories for CVE-2017 (WordPress 4.7 REST API), CVE-2018-19207, CVE-2021-24284, CVE-2022-0633, CVE-2023-28121, CVE-2024-25600, CVE-2024-28000, CVE-2024-10924, CVE-2025-27007.
• JunoBizz incident record, November 2026 (first-hand — Section 5 case study).

Need a hand with the recovery side — cleaning up search results, rebuilding trust in Google, or getting a WordPress site built and maintained with these checks in place from day one? Talk to JunoBizz — we have done the 2 a.m. version of this, on our own site, and we would rather help you skip it.