{"id":8533,"date":"2026-08-04T21:43:15","date_gmt":"2026-08-04T21:43:15","guid":{"rendered":"https:\/\/dextora.agency\/?post_type=insight&p=8533"},"modified":"2026-08-04T21:43:15","modified_gmt":"2026-08-04T21:43:15","slug":"wordpress-plugin-vulnerabilities-five-hour-exposure-window","status":"publish","type":"insight","link":"https:\/\/dextora.agency\/en\/insights\/wordpress-plugin-vulnerabilities-five-hour-exposure-window\/","title":{"rendered":"WordPress Core Is Nearly Untouchable. 91% of the Holes Are in Plugins, and You Have Five Hours"},"content":{"rendered":"

Almost every WordPress security article ends in the same place: keep everything updated. In 2026 that advice is technically correct and operationally useless, because the gap between a vulnerability going public and being exploited across the whole internet is now shorter than the time it takes most teams to notice the update exists.<\/p>\n

On 25 February 2026 Patchstack published its State of WordPress Security in 2026<\/a>. Two figures from it are worth committing to memory. 11,334 new vulnerabilities were catalogued across the WordPress ecosystem during 2025, a 42% increase on the year before.<\/strong> And the weighted median time from public disclosure to mass exploitation was five hours.<\/strong><\/p>\n

Five hours is less than a working day. It is shorter than most maintenance retainers, shorter than the average change-approval cycle, and considerably shorter than the interval between someone logging into an admin panel to check whether anything needs updating. This article is about what that number actually forces you to change.<\/p>\n

What the report found, in one table<\/h2>\n

The headline distribution is the part that reframes the whole discussion. The platform itself is not where sites are being broken into.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
Finding for 2025<\/th>\nFigure<\/th>\nWhat it means in practice<\/th>\n<\/tr>\n<\/thead>\n
New vulnerabilities catalogued<\/td>\n11,334, up 42% year on year<\/td>\nThe problem is volume, not exotic technique<\/td>\n<\/tr>\n
Share found in plugins<\/td>\n91%<\/td>\nYour attack surface is a procurement decision, not a platform one<\/td>\n<\/tr>\n
Share found in themes<\/td>\n9%<\/td>\nPage builders and multipurpose themes carry real weight here<\/td>\n<\/tr>\n
Found in WordPress core<\/td>\n6, all classified low priority<\/td>\nCore is effectively not your risk<\/td>\n<\/tr>\n
Median time to mass exploitation<\/td>\n5 hours<\/td>\nA human patching cadence cannot win this race<\/td>\n<\/tr>\n
No patch available at disclosure<\/td>\n46%<\/td>\nNearly half the time there is nothing to update to<\/td>\n<\/tr>\n
Critical zero-days in premium components<\/td>\n33, against 12 in free components<\/td>\nPaying for a plugin buys support, not safety<\/td>\n<\/tr>\n
WordPress-specific attacks stopped by hosting defences<\/td>\n12%<\/td>\nThe perimeter is thinner than the invoice suggests<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

One caveat before anyone quotes this in a board deck. Patchstack maintains a commercial vulnerability database and sells mitigation, so it is reporting on a market it participates in. The counts come from its own intake and curation, which is the most complete public source available for this ecosystem and is still one vendor’s view of it. Treat the direction as solid and the second decimal place as approximate, the same way you should treat any industry benchmark.<\/p>\n

Stop auditing core. It is not the door anyone uses<\/h2>\n

Six low-priority issues in core across an entire year, on software running a very large share of the web, is an unusually good result for any platform of that size. Core has a security team, a disclosure process, background updates enabled by default for point releases, and enough scrutiny that serious problems surface early.<\/p>\n

Plugins have none of that guaranteed. A plugin can be written by a two-person shop, sold, abandoned, resold, and left in the directory with fifty thousand active installs and no maintainer. The plugin security guidance in the WordPress developer handbook<\/a> exists and is good, and nothing enforces that anyone reads it. That asymmetry is the entire story of the 91%.<\/p>\n

The operational consequence is uncomfortable: the number of plugins on a site is a security metric.<\/strong> Not a performance one, not a tidiness one. Every additional plugin is an additional independent vendor whose release discipline you have adopted without reviewing it. We wrote separately about how WordPress sites actually get hacked<\/a>, and the pattern in real incidents matches the statistics almost exactly.<\/p>\n

Why five hours kills the manual model<\/h2>\n

Consider how a typical maintenance arrangement works. A vulnerability is disclosed on a Tuesday afternoon. Someone reads the advisory on Wednesday morning. A ticket is raised, a staging site is updated, a smoke test is run, the client approves the window, and the fix reaches production on Thursday. That is a competent, careful, professional process. It is also roughly thirty times slower than the exploitation window.<\/p>\n

Automated scanning does not care about your working hours. Once a fix appears in a public repository, the diff itself describes the vulnerability, and mass scanning follows within hours. The gap between disclosure and exploitation has been compressing for years, and five hours is what it now looks like.<\/p>\n

Then there is the 46%. Almost half of the disclosed vulnerabilities had no patch available at the moment they went public, which means the entire strategy of “apply updates promptly” simply has no move to make in those cases. You cannot install a fix that does not exist. Something else has to cover the interval.<\/p>\n

Premium is not the safe option<\/h2>\n

This is the finding most likely to contradict an existing procurement policy. Patchstack recorded 33 critical zero-day vulnerabilities in premium or freemium components against 12 in free ones<\/strong>, and reported that paid components carried around three times the rate of known exploited vulnerabilities.<\/p>\n

The mechanism is not mysterious. Premium plugins carry more features, larger codebases, licensing and update servers of their own, and bundled third-party libraries. They are also distributed outside the wordpress.org repository, which means they sit outside the automated review, the forced-update mechanism the repository can trigger, and often outside the update channel of the site itself. A bundled premium slider inside a purchased theme is the classic case: it is three versions behind, nobody knows it is there, and it has no update path at all.<\/p>\n

The right conclusion is not that free is safer. It is that price is not a proxy for maintenance quality<\/strong>, and it should not appear anywhere in your selection criteria as if it were. The questions that do predict something are release frequency, time-to-patch history, whether the vendor has a published security contact, and whether the component appears in a vulnerability database with a record of prompt fixes. Our vendor risk checklist before integrating a third-party service<\/a> covers the same evaluation logic for services, and it transfers directly to plugins.<\/p>\n

What hosting and WAFs actually do<\/h2>\n

The report’s most awkward number for the hosting industry is that traditional defences blocked only 12% of WordPress-specific vulnerabilities<\/strong>, against a considerably better rate for generic attack traffic.<\/p>\n

That difference is the important part. Generic rules catch generic attacks: SQL injection patterns, known bad payloads, obvious scanners. A WordPress-specific vulnerability is usually a legitimate request to a legitimate endpoint with parameters the plugin author failed to validate. There is nothing in the packet that looks wrong unless the rule knows that specific plugin, that specific endpoint, and that specific parameter. Generic filtering cannot know that.<\/p>\n

None of which makes managed hosting worthless. Isolation, hardened PHP settings, immutable backups and fast rollback are worth paying for, and we set out where the money genuinely matters in choosing business hosting<\/a>. Just do not buy it believing that the WAF line item covers plugin vulnerabilities. On the evidence it covers about one in eight of them.<\/p>\n

The controls that actually move the number<\/h2>\n

Given a five hour window, a 46% no-patch rate and a 12% perimeter block rate, the strategy has to stop being “patch faster” and start being “have fewer things to patch, and cover the interval when patching is impossible”.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n
Control<\/th>\nWhich finding it answers<\/th>\nEffort<\/th>\nWhat it leaves uncovered<\/th>\n<\/tr>\n<\/thead>\n
Cut plugin count, remove anything inactive<\/td>\n91% in plugins<\/td>\nOne audit, then quarterly<\/td>\nNothing about the plugins you keep<\/td>\n<\/tr>\n
Provenance rules for new plugins<\/td>\nPremium zero-day rate<\/td>\nA policy plus ten minutes per decision<\/td>\nEverything already installed<\/td>\n<\/tr>\n
Virtual patching at the application layer<\/td>\n5 hour window, 46% unpatched<\/td>\nSubscription plus setup<\/td>\nVulnerabilities nobody has published yet<\/td>\n<\/tr>\n
Automatic minor and security updates<\/td>\n5 hour window<\/td>\nConfiguration only<\/td>\nMajor versions, and the risk of a bad release<\/td>\n<\/tr>\n
Staged major updates on a copy of production<\/td>\nBreakage risk from automation<\/td>\nA staging environment<\/td>\nAdds delay, so pair it with virtual patching<\/td>\n<\/tr>\n
File integrity and outbound request monitoring<\/td>\nDetection when prevention fails<\/td>\nSetup plus someone reading alerts<\/td>\nDetects, does not prevent<\/td>\n<\/tr>\n
Tested restore, not just backups<\/td>\nRecovery time after a successful breach<\/td>\nOne rehearsal per quarter<\/td>\nData written between breach and detection<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

Three of those deserve expansion.<\/p>\n

Virtual patching<\/strong> is the direct answer to the 46%. A rule written for one known vulnerability in one known component blocks the specific request shape that exploits it, without touching the plugin. It buys you the interval between disclosure and a real fix, which is precisely the interval where sites are lost. Public vulnerability trackers such as the Patchstack vulnerability database<\/a> and the CISA catalogue of known exploited vulnerabilities<\/a> are what these rules are built from, and they are also worth subscribing to directly if you run more than a handful of sites.<\/p>\n

Staged auto-updates<\/strong> means splitting the update stream rather than choosing between automatic and manual for everything. Security and minor releases go out automatically, because the expected loss from a rare broken layout is far smaller than the expected loss from a five hour exposure. Major versions go through staging. WordPress supports this split natively through the background update constants<\/a>, and most teams never configure them because the default conversation is framed as all or nothing.<\/p>\n

Monitoring<\/strong> exists because the first three controls will eventually fail. What matters after that is elapsed time. A compromise found in an hour is an incident; the same compromise found in three months is a data problem, a reputation problem and possibly a regulatory one. The baseline set we recommend for smaller teams is in our guide to cybersecurity for small business<\/a>.<\/p>\n

What these numbers do not justify<\/h2>\n