If your site gets broken into through a plugin, it almost certainly will not be because someone targeted you. It will be because a vulnerability was published, a scanner found your site inside a list of millions, and your plugin was still on the old version. In 2025 the weighted median time between public disclosure of a heavily exploited WordPress vulnerability and mass exploitation of it was five hours. That is the number that should shape your patching policy, and it is the reason a monthly update cycle is not a security control.
The practical conclusion: plugin security is a logistics problem, not a product problem. You do not fix it by buying a better firewall. You fix it by knowing exactly what is installed, removing what you do not use, patching within hours rather than weeks for the handful of plugins that matter, and accepting that roughly half the vulnerabilities disclosed will not have a fix on the day you read about them.
Below is what the pipeline actually looks like, from researcher report to automated attack, and where you can realistically intervene.
How long do you have after a WordPress plugin vulnerability is disclosed?
Less time than any sensible maintenance schedule allows. Patchstack’s State of WordPress Security in 2026 report, covering 2025 data, breaks the exploitation curve down like this for the vulnerabilities that got heavily attacked:
| Time since public disclosure | Share of heavily exploited vulnerabilities already under attack |
|---|---|
| 6 hours | 20% |
| 24 hours | 45% |
| 7 days | 70% |
Read that against a normal agency maintenance cadence. A site patched every Monday morning sits unprotected through the entire window where most exploitation happens. A site patched monthly is, for practical purposes, not patched at all against anything that gets weaponised.
It gets worse at the front end of the timeline. Mandiant’s M-Trends 2026 puts the mean time-to-exploit across the industry at minus seven days — negative, because the average is dragged below zero by zero-days that are in use before any vendor fix exists. Google’s Threat Intelligence Group counted 90 zero-days exploited in the wild during 2025, up from 78 in 2024. “Patch promptly” is good advice, but it is not a complete answer, because for a meaningful slice of attacks there was nothing to patch at the time.
Where WordPress plugin vulnerabilities come from
The volume is the first thing worth internalising. 11,334 new vulnerabilities were disclosed across the WordPress ecosystem in 2025 — a 42% increase on the 7,966 recorded in 2024. The split:
- 91% were in plugins
- 9% were in themes
- 6 total were in WordPress core, all classified low priority
That last line is the one most site owners get backwards. WordPress core is not your risk surface. Core had six low-priority issues in a year across tens of millions of installs. Your risk surface is the twenty-six plugins someone added over four years, eleven of which nobody can now explain the purpose of.
Severity moved too, not just volume. 1,966 of those vulnerabilities — 17% — were rated high severity, more than the previous two years combined, and the count of vulnerabilities classed as highly exploitable rose 113% year on year.
And then the part that breaks most patching policies: 46% of disclosed vulnerabilities had no developer fix available at the moment of public disclosure. For nearly half of what you will read about, “update the plugin” is not an available action on day one. The only moves are mitigation, virtual patching, or removing the plugin.
What attackers actually exploit
The mental image most people have of a plugin hack is SQL injection or a file upload that drops a shell. Those exist, but they are not the bulk of it. Of the attacks Patchstack’s mitigation rules blocked in 2025:
| Vulnerability class | Share of blocked exploitation | What it looks like in practice |
|---|---|---|
| Broken access control | 57% | An endpoint that never checks who is calling it. Requests look like ordinary authenticated traffic. |
| Privilege escalation | 20% | A subscriber account, or no account, becomes an administrator. |
| Local file inclusion | 10% | A parameter controls which file gets loaded; attacker points it somewhere useful. |
| SQL injection | 5% | The classic. Still present, no longer dominant. |
Broken access control dominating matters operationally, because that traffic is boring. It is a well-formed request to a legitimate endpoint. There is no obvious payload for a signature to match, nothing that looks like an attack in your access logs, and often no error anywhere. By the time the symptom appears — a new admin user, injected spam pages, a redirect — the actual exploitation happened days earlier. Mandiant’s median dwell time across incidents is 14 days.
If you have ever wondered how a site ends up quietly serving thousands of spam pages without anything obviously breaking, that is the mechanism; we walked through the cleanup side of it in our guide to finding and cleaning the Japanese keyword hack.
Why the plugin you patched last year is still the one getting you hacked
Here is the most useful single finding in the 2026 data: of the ten most-exploited WordPress vulnerabilities of 2025, only four were disclosed in 2025. The rest were published in 2023 or 2024 and were still generating enough attack volume to make the top ten.
Among them: LiteSpeed Cache (two separate 2024 vulnerabilities — an unauthenticated stored XSS affecting versions up to 5.7, and an unauthenticated privilege escalation up to 6.3.0.1), tagDiv Composer (2023, unauthenticated stored XSS, up to 4.2), GiveWP (2024, PHP object injection leading to RCE, up to 3.14.1), WooCommerce Payments (2023, unauthenticated privilege escalation, up to 5.6.1), and Startklar Elementor Addons (2024, unauthenticated arbitrary file upload, up to 1.7.13).
Scanning for an old vulnerability costs an attacker almost nothing. The exploit is written, the scanner is already running, and there is no reason to ever retire it as long as some fraction of the internet is still vulnerable. Your three-year-old plugin version is not obscure. It is a line in a list.
This is also why “we’re on a maintenance plan” and “we’re patched” are different claims. If the plan updates plugins but nobody ever audits what is installed, an abandoned plugin pinned at a vulnerable version because an update once broke the layout will sit there indefinitely, invisible to the update screen. That audit is the part people skip — it is in the maintenance checklist we run on client sites for exactly this reason.
Not sure what is actually installed on your site, or which of it is still maintained? That inventory is the first thing we build in a Dealinweb security audit — every plugin, its version, its last update date, and whether a known vulnerability applies to the version you are running.
Premium plugins are the worse half of your inventory
The intuition that paid plugins are safer than free ones does not survive the data. Of 1,983 valid vulnerability reports for premium or freemium products in 2025, 76% were rated exploitable in real-world attacks, and premium products carried roughly three times as many known exploited vulnerabilities as free ones.
The reason is distribution, not code quality. A free plugin from the WordPress.org repository updates through the admin dashboard like everything else. A premium plugin usually needs a valid licence key to receive updates. When the licence lapses — the client stopped paying, the card expired, the agency that bought it left — the plugin keeps working and silently stops receiving security fixes. There is no warning that says “this plugin is now frozen at a vulnerable version.”
A quick way to see the shape of your exposure, if you have WP-CLI:
# Everything installed, with version and available update
wp plugin list --fields=name,status,version,update,update_version
# Active plugins that have an update waiting
wp plugin list --status=active --update=available --fields=name,version,update_version
# Anything installed but not active — delete, don't deactivate
wp plugin list --status=inactive --field=nameDeactivated plugins deserve a specific note. Deactivating a plugin does not remove its files from the server, and several classes of vulnerability — anything reachable by requesting a plugin file directly — remain exploitable on an inactive plugin. If you are not using it, delete it.
Your host’s firewall is not the control you think it is
Patchstack ran two 2025 penetration studies against hosting providers’ built-in defences, firing known WordPress exploits at live sites. Traditional hosting defences blocked 12% of attacks in the test focused on known exploited vulnerabilities, and 26% in a broader test. The best-performing host — running a stack of Imunify360, SiteLock and an internal WAF — blocked 60.7%. Several hosts combining Cloudflare, ModSecurity and Imunify360 blocked under 17%. One blocked nothing at all.
This is not an argument against having a WAF. It is an argument against treating one as the reason you can patch slowly. Generic rules struggle with broken access control precisely because that traffic is indistinguishable from legitimate requests without plugin-specific knowledge of which endpoint should check which capability.
Aggressive WAF rules also have a cost in the other direction: over-tuned ModSecurity rulesets are one of the more common causes of a wp-admin that intermittently refuses to save. That trade-off is worth understanding before you turn everything up to maximum.
What actually closes the window
Four things, in order of how much they move the risk:
1. Reduce the inventory. Every plugin is an independent codebase with its own maintainer, release cadence and abandonment risk. The most reliable security work on most sites is deleting things. A plugin that does one small job you could do with ten lines in a child theme is not worth the subscription to the attack surface.
2. Patch on a schedule measured in hours for the plugins that matter. Not everything needs this. The plugins that do are the ones with large install bases (attractive targets), the ones handling authentication, forms, file uploads or payments, and anything with a history of unauthenticated vulnerabilities.
3. Turn on auto-updates selectively — and understand what they do not do. Plugin auto-updates have been available per-plugin since WordPress 5.5 and are off by default. WordPress runs auto-updates roughly twice per day via WP-Cron, which already means a worst case of around twelve hours on a five-hour exploitation median. There is no automatic rollback if an update breaks the site, and the mechanism depends on WP-Cron working — which, on sites where cron is disabled or jammed, it silently is not. Check Tools → Site Health before assuming auto-updates are running.
Enable them where the blast radius of a bad update is small, and pair them with tested backups and a staging check for anything where it is not. We went through the specific ways this breaks in what actually breaks when you auto-update WordPress.
4. Subscribe to vulnerability intelligence for the plugins you actually run. The point is not to read a weekly digest. It is to get an alert the same day a plugin on your list is disclosed, so that the 46% of cases with no fix available can be handled by removal or mitigation rather than waiting.
Patched is not the same as clean
The last step people skip. Applying the update closes the door; it does not evict anyone who already walked through it. Attackers establish persistence early — an extra administrator account, a scheduled task, a modified mu-plugins directory, a backdoor in a file that looks like it belongs — specifically so that patching does not remove them.
After any plugin vulnerability that applied to a version you were running, the question is not “is it updated” but “was it used before I updated”. That means checking users, checking scheduled events, and comparing core and plugin files against known-good copies. If a site was exposed during the exploitation window, treat it as a possible incident: the first 60 minutes after a WordPress compromise covers the triage order.
Where to start
If you do nothing else this month: list every plugin on the site, delete the ones that are inactive or unexplained, check the last-updated date on everything that remains, and find out which of your premium plugins have live licences. That exercise alone usually removes more risk than any product you could buy.
If you would rather have someone do it properly — full plugin inventory, version-by-version check against known vulnerabilities, licence and abandonment status, and a patching cadence that fits a five-hour exploitation window rather than a monthly invoice — talk to us about a security audit. We will tell you what is actually exposed before anything happens, which is considerably cheaper than the cleanup afterwards.