Hacked WordPress sites don’t always look broken. The most common sign I see is a Google Search Console alert: thousands of Japanese-language pages suddenly indexed on a site whose owner was sure nothing was wrong. The site loads fine when you log in. The dashboard is clean. The hack is invisible to anyone who isn’t Googlebot.
After cleaning up compromised WordPress sites for ten years, I can tell you the list of what actually caused each one is shorter, and different, than the standard checklist circulating online. Most of that checklist is vendor-driven: install this plugin, enable that setting. This post ranks the five attack vectors I see show up most often in real cleanups, explains why some of the most-recommended defenses miss the point, and ends with fixes in order of actual impact.
The standard security advice has a problem
Open any “WordPress security checklist” from a hosting provider and you’ll see the same opener: strong passwords, 2FA, hide your login URL. That advice is fine. It also doesn’t address the way most compromised sites actually got compromised.
Patchstack’s 2025 report found that 43% of new WordPress vulnerabilities required zero authentication to exploit (Patchstack State of WordPress Security 2025). The attacker never sees your login page. They hit a vulnerable plugin endpoint directly and get code execution or admin access without ever guessing a password. MalCare’s own data puts it bluntly: 2FA protects against roughly 5% of threats (MalCare blog).
The dominant beginner advice, “install Wordfence and keep plugins updated, you’ll be fine,” is half-right. Wordfence does block brute force effectively. But Wordfence runs at the application layer, after the web server and PHP have already loaded. A PHP webshell uploaded into /wp-content/uploads/ is executed by the web server directly before WordPress even boots. Wordfence cannot see it. Patchstack’s 2026 report measured that traditional WAFs block only 12% of WordPress-specific attacks (Patchstack 2026).
And the standard “patch urgently by CVSS score” advice misleads you in both directions. Patchstack found 64.7% of disclosed vulnerabilities are CVSS “Medium,” yet 69.6% of those are unlikely to ever be exploited in the wild. Meanwhile, some lower-scored vulnerabilities get mass-exploited within hours. The signal you want is real-world exploitation frequency, not severity score.
The 5 attack vectors, ranked by how often I’ve seen them
These are ranked by real-world exploited-in-the-wild frequency from Wordfence, Patchstack, and Sucuri research, cross-checked against the cleanup patterns I keep running into. Not by theoretical severity. Not by CVSS. Most of the high-CVSS items in any given quarter never see a single exploitation attempt, while a handful of “Medium” plugin bugs get hammered by 9 million requests in two weeks.
#1 Vulnerable plugins: the door attackers actually use
This is the vector. 96% of WordPress vulnerabilities disclosed in 2024 came from third-party plugins, 4% from themes, fewer than 6 total from core (Wordfence 2024 Annual Report). In 2025 the count jumped to 11,334 new vulnerabilities, a 42% increase year-on-year, with 46% unpatched at the moment of public disclosure. The exploitation window for the heavily-targeted ones has a weighted median of 5 hours.
That’s not theoretical. LiteSpeed Cache CVE-2024-28000, a privilege escalation in a plugin with 5 million installs, saw 48,500 attack attempts in a single 24-hour window after disclosure (Wordfence). GutenKit and Hunk Companion together triggered 9 million exploitation attempts in the two weeks after disclosure in October 2024. Really Simple Security CVE-2024-10924 was an unauthenticated auth bypass that hit 4 million installs and skipped 2FA entirely through a REST endpoint.
The cleanup pattern I see most often follows the same script. A plugin file-upload vuln, no authentication required, accepts a PHP file disguised as an image. The shell drops into /wp-content/uploads/. The web server executes it on the next request. The owner’s Wordfence dashboard still says everything is fine, because Wordfence never sees the request. Two weeks later there’s a backdoor admin user, the database has injected scripts, and the cleanup invoice is in the four digits.
Fix: auto-updates on for everything that supports them. Deactivate-and-delete unused plugins, not just deactivate. Run a server-side scan for unexpected PHP files inside /uploads; that’s exactly what GuardingWP (my own scanner-as-a-service) catches and what most free WP-level scanners miss. For the underlying maintenance discipline, keeping plugins current is the lowest-effort, highest-coverage move you can make.
#2 Credential attacks: big volume, lower conversion
Brute force and credential stuffing on wp-login.php generate by far the most attack traffic. Wordfence blocked 6.4 billion brute force attempts per month in 2024 and 100 billion credential-stuffing attempts from 74 million unique IPs across the year (Wordfence 2024). Average WordPress site gets probed every 34 minutes.
Volume isn’t risk, though. Conversion rate on credential attacks drops below 0.02% the moment you add basic defenses: rate-limiting, blocking the default admin username, and unique passwords. 2FA is a real win against this specific vector. Trade-off: it doesn’t help against any of the other four. CVE-2024-10924 walked straight past 2FA by hitting /reallysimplessl/v1/two_fa/skip_onboarding directly. The login page wasn’t the door.
Fix: disable xmlrpc.php if you don’t use the mobile app or Jetpack, rate-limit wp-login.php, kill the default admin username, use a password manager. A note worth making: I do not recommend leaning on Wordfence Free as your brute-force defense alone, because the free tier has a 30-day delay on firewall rule updates for newly disclosed vulnerabilities (Ben Ryan technical analysis). When exploitation windows are 5 hours and your patch lag is 30 days, the math doesn’t work.
#3 SEO spam injection: the silent one
This is the attack that pays for itself. Attackers inject thousands of doorway pages, usually Japanese-language or gambling keywords, and use cloaking to serve them only to search bots. You log in: site looks fine. Googlebot crawls: 4,000 spam pages indexed under your domain. The attacker monetises the hijacked traffic by redirecting it to counterfeit stores.
Sucuri’s 2024 SiteCheck data: 117,393 Japanese keyword spam detections, 114,318 hidden content spam, 79,817 gambling spam (Sucuri SiteCheck Malware Trends 2024). 10.07% of all remediations involved malicious .htaccess rules used to enforce the cloaking. The 2023 Hacked Website Report found malicious admin users in 55.2% of infected databases.
I’ve cleaned up sites where this ran for four months before anyone noticed. The first warning signal is almost always Google Search Console: a sudden spike in indexed pages, or organic traffic collapsing because Google demoted the domain. By then the cleanup is bigger than the original entry point, because there’s a backdoor and a malicious admin to find too.
Fix: check Google Search Console “Pages” report weekly for unexpected indexed URLs. Set up an organic-traffic alert. Run a server-side malware scan (not just a front-end URL scan, which the cloaking can fool). Audit .htaccess for unfamiliar rewrite rules.
#4 Backdoors: why one cleanup often isn’t enough
The initial exploit is rarely the last one. 49.21% of compromised sites Sucuri analysed in 2023 contained at least one backdoor (Sucuri 2023 Report). Sucuri removed 21,062 backdoors that year alone. Malicious admin accounts showed up in 55.2% of infected databases.
The pattern is consistent. A plugin vuln gives the attacker file write access. They drop a PHP shell in /uploads or inject one line into wp-blog-header.php. They create a new admin account with an innocuous name. They might rotate the database credentials in wp-config.php, lock the owner out, and create a fresh admin to maintain access. The first the owner hears about it is when they can’t log in any more, and by then the attacker has whatever they came for.
The thing competitor checklists miss: if you restore a backup without identifying the entry point first, you restore to the same vulnerable plugin version and get re-compromised within days. I’ve seen the same site cleaned up three times in two months because the cleanup crew kept skipping the diagnosis step.
Fix: file integrity monitoring so you see new PHP files appearing in places they shouldn’t. After any incident, list every admin user and verify each one. Verify wp-config.php hasn’t been touched. Patch the entry point before you restore.
#5 Supply chain: the vector you can’t patch your way out of
This is the one no competitor article covers and the one most undermines the “keep plugins updated” advice, because updating to the latest version is exactly how the backdoor gets delivered.
In April 2026, an attacker bought 30+ WordPress plugins through Flippa, the website-flipping marketplace, and planted a dormant backdoor across them (TechCrunch coverage). The code looked benign: a fetch_ver_info() function calling a remote URL, with a unserialize() on the response. The backdoor activated 8 months later, after sitting in production through several minor version bumps that site owners auto-updated cleanly. No CVE. No WordPress.org notice. No red flag in anyone’s dashboard.
This wasn’t isolated. In June 2024, five plugins on WordPress.org were backdoored via credential stuffing on the developer accounts, with code injected to spawn rogue admin users and SEO spam (Wordfence). Patchstack tracked 1,614 abandoned plugins still active on live sites despite removal from the WordPress.org repo, with no auto-update mechanism warning the owner.
You cannot patch your way out of this one. The patch is the threat.
Fix: track plugin authorship changes (Patchstack publishes these). Limit plugin count aggressively, every plugin is an unmonitored supply chain. Favour plugins with a verified ownership history and active maintainer. Run periodic server-side scans to catch dormant shells that bypass WP-level tools. This is the specific vector GuardingWP was built for: scanning at the file-system level for backdoor signatures that don’t trip application-layer scanners.
What a real defense stack looks like
There is no single plugin that covers all five vectors. Anyone selling you that is selling. What follows is ordered by coverage per effort, what I’d install first on a site I just took over:
- Patch plugins within 48 hours of disclosure, not when it’s convenient. Auto-updates on for everything that supports them. For the gap between disclosure and a vendor patch, virtual-patching services like Patchstack vPatch close the window.
- Server-side file scanning, not just plugin scanning. File-upload webshells bypass every WP-level scanner. This is the layer GuardingWP operates at, and it’s what most free security plugins structurally cannot do.
- Login hardening: rate limiting, unique username, 2FA. Low effort, closes the brute-force vector. Not a complete defense but a fast win.
- Minimise plugin surface. Every inactive plugin is an unmonitored attack surface, and every active plugin is a supply-chain risk. Deactivate-and-delete, not just deactivate. Audit twice a year.
- Monitor for unexpected indexed content. Google Search Console “Pages” report is your earliest SEO-spam detection signal. Check weekly, set a traffic alert, treat any unexplained indexed URL as a potential incident.
If you’d rather not track plugin CVEs, scan files, and audit GSC manually every week, that’s what managed WordPress maintenance is for. The work doesn’t go away. Someone has to do it.
Wrap-up
Security isn’t one product or one setting. It’s knowing which door attackers actually use, and putting the lock there first.