53 percent of WordPress sites run unpatched CVEs: GuardingWP 2026 audit

#53 percent of WordPress sites run unpatched CVEs: what the GuardingWP 2026 audit actually proves

More than half. The inaugural State of WordPress Security 2026 report from GuardingWP, drawn from scans of 424 confirmed WordPress installs across more than forty verticals, says 53 percent of sites run at least one plugin carrying a known unpatched CVE. The same report puts 93.2 percent missing modern security headers, 55.9 percent leaking their WordPress version through the generator meta tag, and 35.8 percent still serving XML-RPC.

The numbers are not a surprise. The surprise would be a finding under thirty percent, because the structure of the WordPress plugin economy returns this rate by default. This article reads the GuardingWP data as evidence that the cure is not a better firewall, it is the supply-chain controls already written into NIS2 Article 21 paragraph 2 letter d and DORA Article 28.

This piece sits next to our pillars on NIS2 and DORA on WordPress: the 2026 compliance stack and on WordPress plugin supply chain, and it complements the WCAG, BFSG, and EAA work in the accessibility compliance pillar because procurement teams now bundle accessibility, security, and resilience into one supplier sheet.

#TL;DR

• GuardingWP 2026 scanned 424 confirmed WordPress installs across more than 40 verticals. The four headline findings are detectable from a single HTTP response per site.
• 53 percent of sites run at least one plugin with a known unpatched CVE. 93.2 percent miss modern security headers. 55.9 percent leak the WordPress version. 35.8 percent expose XML-RPC.
• The 53 percent rate is not user negligence. It is the default output of a plugin economy where each install integrates 20 to 40 third-party publishers with non-aligned patch cycles.
• WordPress 7.0 added AI infrastructure with API keys to the admin secret surface. Patchstack founder Oliver Sild publicly predicted a “rush by hackers to steal API keys.”
• NIS2 Article 21 paragraph 2 letter d and DORA Article 28 already encode the cure: a documented vulnerability handling policy, supplier assessment, patch cadence, and register of ICT third-party arrangements.
• The lever that moves a WordPress organisation from compliance failure to compliance pass is not a plugin. It is a control framework.

#The numbers, sourced

The four headline metrics in the GuardingWP 2026 report are observable from outside the site. A scanner needs the home page response and the /xmlrpc.php HTTP status to derive every one of them. That matters because compliance auditors are increasingly drawing from external evidence first, and Patchstack-style telemetry, GreyNoise, and the Internet Archive are all standing measurement infrastructures.

For the EU regulated reader, the relevant baselines for those four numbers are different. CSP and HSTS are mentioned in ENISA’s good practices for the security of internet-facing systems. XML-RPC exposure is explicitly called out in OWASP’s Top 10 risks. Unpatched plugin CVEs map directly to NIS2 Article 21 supply-chain controls. The GuardingWP report is not a list of curiosities. It is four already-codified compliance gaps, measured.

#Why the 53 percent number is structural

A typical WordPress site runs between twenty and forty plugins. WordPress.org publishes 60,000 plus plugins, with a long tail of authors who do not have funded security teams. The patch cycle of plugin A and plugin B is not coordinated. The site owner is the integrator of last resort. When CVE-2025-XYZW lands in plugin A on a Tuesday, the site owner is the only party who can decide whether to patch, whether to test against the rest of the stack, and whether the patch breaks plugin B.

The economics of the situation do not favour the integrator. Patching twenty plugins a month with regression testing is engineering work. Most WordPress sites are not budgeted to do that engineering. Therefore most WordPress sites are not patched. The 53 percent rate is the equilibrium.

There are two ways out of this equilibrium, and only one is durable.

The first way is to shrink the plugin stack. A WordPress site with eight plugins, all of which are still under active maintenance and all of which are individually scoped to a function the site owner can describe in one sentence, is a tractable patch surface. The discipline costs more upfront because the team has to either build the function in custom code or live without it, but the monthly cost of staying patched falls in proportion.

The second way is to outsource the patch cadence to a managed provider who actually does it. This is what serious managed WordPress hosts and serious agencies actually deliver, and where the contract terms say “we apply security patches within X hours of vendor release, on a staging environment, then production.” If the contract does not say this, the cadence does not exist, and the site is statistically in the 53 percent.

#What WordPress 7.0 changed

WordPress 7.0 “Armstrong” shipped on the same publication week as the GuardingWP report. The 7.0 release added the AI Services Registry and the Abilities API, which means the admin surface now stores API keys for hosted model providers (Anthropic, OpenAI), AI gateways (Vercel), and self-hosted endpoints. Those keys have a billable side. A compromised admin credential is no longer just a content integrity problem. It is also a cost-leak problem.

Patchstack founder Oliver Sild posted publicly on X on the day of release: “there will be an absolute rush by hackers to steal API keys.”

Justin Nealey, writing on his blog, flagged the related practical headache: the WP AI Client has no built-in throttle, and multiple plugins sharing one API key can blow through the token cap in under a minute. That is not a hypothetical adversary, that is a friendly misconfiguration. Both shapes of cost-leak imply the same control: per-connector key scoping, rate limits applied at the gateway not the plugin, and an audit log that surfaces unexpected token consumption inside one billing cycle.

The control surface is well understood. It is the same control surface a finance team would apply to any newly minted billable credential. WordPress is unusual only in that it has not historically had this category of credential in its admin.

#How NIS2 reads the GuardingWP data

The NIS2 Directive (2022/2555), Article 21, paragraph 2, lists ten technical and organisational measures that essential and important entities must apply. Paragraph 2 letter d, in the directive’s own words, requires “supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers.” A WordPress install running unpatched CVE plugins fails letter d, regardless of whether the plugin is individually critical, because the entity has not assessed and managed the supplier risk.

The cure under NIS2 is procedural. It includes:

• A documented vulnerability handling and disclosure policy that the entity actually follows. Paragraph 2 letter b.
• A patch and update cadence with a target time to apply CVE-rated fixes. Paragraph 2 letter f, in conjunction with letter b.
• A supplier assessment that covers the plugin authors who are themselves ICT third-party providers, including their security maturity, their channel for disclosure, and their patch latency. Paragraph 2 letter d.
• A register of ICT third party arrangements, which under DORA also has an explicit Article 28 obligation for financial entities.

A WordPress site can pass the technical reading of NIS2 (i.e. have no unpatched CVE plugins on the day of audit) and still fail the procedural reading if the entity cannot show the documents. The 53 percent rate suggests the documents do not exist for half the in-scope sites.

This is the part of the conversation most security-tool vendors avoid. Selling a firewall is easier than selling a control framework. The control framework is what NIS2 actually requires.

#How DORA reads the GuardingWP data, for financial entities

The DORA Regulation (2022/2554) has been directly applicable since 17 January 2025. It applies to credit institutions, payment institutions, insurers, investment firms, crypto-asset service providers, and roughly fifteen further categories listed in Article 2.

DORA Article 28 governs ICT third party risk management. The WordPress plugin authors of a financial entity’s public website fall under that definition. Two practical consequences follow from the GuardingWP-profile.

First, the entity must maintain a register of contractual arrangements with ICT third party providers (Article 28 paragraph 3). This register must cover the plugin publishers whose code runs on the public site. For most financial entities, this register does not currently include WordPress plugin authors at all. The cure is not technical, it is administrative: extract the active plugin list, map each plugin to its publisher, attach the publisher’s vulnerability handling channel and patch latency, and add the entry to the register.

Second, Article 28 paragraph 5 requires that contractual arrangements with ICT third party providers serving critical or important functions include “exit strategies, in particular establishing a mandatory adequate transition period.” For a WordPress site that depends on a single specialised plugin for a critical workflow (signed-document delivery, KYC adapter, regulatory filing PDF assembly), the exit strategy needs to exist in writing. It rarely does.

These are not glamorous controls. They are paperwork. They are also what an actual DORA audit looks like.

#Where the GuardingWP report is too quiet

The report’s headline numbers are well sourced, but it underplays one thing the practitioner reader needs to see clearly: the 53 percent rate is concentrated in the long tail of small business installs, and is much lower in installs that have a managed provider on a contract that explicitly covers security patching. We do not have GuardingWP’s underlying segmentation, but our own concentration of WordPress sites under maintenance contract reads in the single digits for unpatched CVE rate on any given audit week.

The implication is not that managed WordPress hosts and security-focused agencies are perfect. It is that the equilibrium 53 percent is a market average that mixes two very different populations. A buyer reading the report should not conclude “WordPress is unsafe.” They should conclude “WordPress sites without a control framework are unsafe, and the size of the unmanaged tail is half the market.”

#What changes if WordPress 7.0 is taken seriously

The release of WordPress 7.0 with AI infrastructure is a useful forcing function for the unmanaged tail, because the addition of API keys to the admin surface makes the cost-leak case visible in a way that XSS or stored-cred exfiltration was not. A finance person who could not be moved by “you may have an unpatched CVE” can be moved by “your AI provider invoice for last month was three figures higher than usual and we cannot account for the traffic.”

The control surface that closes the AI-key risk also closes a lot of the rest of the GuardingWP findings, because the controls overlap:

• Modern security headers (CSP, HSTS, X-Content-Type, Referrer-Policy) at the edge. One Cloudflare Worker or one .htaccess block. Closes the 93.2 percent gap.
• Generator meta tag suppression. One filter. Closes the 55.9 percent gap.
• XML-RPC disabled or rate-limited at the edge. One firewall rule or .htaccess line. Closes the 35.8 percent gap.
• API key scoping, per-connector rate limit, anomaly alerting on token spend. New control surface. Closes the 7.0 risk before it has scale.

These are not heroic engineering tasks. They are line items on a managed-services scope of work.

#A practitioner reading

I run security audits for WordPress sites under EU jurisdictions and have for fifteen years. The plant-of-the-week pattern in 2026 is the same one in 2018: a site arrives with twenty-eight plugins, the owner cannot list what eight of them do, and the regression-testing burden of patching everything in one cycle exceeds the budget. The GuardingWP rate is a faithful description of that pattern. The cure that actually works on a one-year horizon is the one nobody likes:

1. Audit the plugin list. Remove every plugin whose function the owner cannot describe in one sentence.
2. Replace the two or three plugins that survive but have stagnant maintainer channels.
3. Establish a documented patch cadence and a vulnerability handling policy. Write it down. Refer to it by name in the maintenance contract.
4. Add a register of ICT third-party arrangements that reflects the active plugin list and is updated on each plugin add or remove.
5. For WordPress 7.0 installs, scope each AI provider key per-connector, apply rate limits at the gateway, and alert on anomaly token spend.

The first four items are NIS2 Article 21 compliance work. The fifth is the new control class introduced by 7.0. None of the five are bought from a vendor as a product. They are how the WordPress practitioner shows up.

#Closing argument

The GuardingWP 2026 report is the most useful single document the WordPress security community has published in five years, because it reframes a debate that has been stuck in tool-comparison mode for too long. The right reading is not “switch to Patchstack” or “install Wordfence.” It is: half the market does not run a control framework, the controls that close the gap are codified in NIS2 and DORA, and the buyer who is on the receiving end of EU regulation in 2026 is the one with leverage to force the controls into the supplier contract.

For the WordPress agency reader, this is the strongest commercial moment in years to sell the framework, not the tool. The 53 percent number is the lead line of the next supplier pitch deck.

#Sources

• GuardingWP, State of WordPress Security 2026 (report landing page)
• Directive (EU) 2022/2555 on the security of network and information systems (NIS2), Article 21
• Regulation (EU) 2022/2554 on digital operational resilience for the financial sector (DORA), Article 28
• Patchstack
• ENISA: good practices for the security of internet-facing systems
• OWASP Top 10 2021

#Related on this site

• Pillar: NIS2 and DORA on WordPress: the 2026 compliance stack
• WordPress plugin supply chain 2026: four backdoors in one month
• WCAG 2.2, BFSG, and EU Accessibility Act: the 2026 compliance stack for WordPress
• WordPress security audit
• DORA Article 28 ICT third party risk: WordPress hosting and WAF supplier audit

Last updated: 2026-05-23