bwt
// state of

WordPress Security & Vulnerabilities, 2026

Plugins are the attack surface, disclosure is outrunning patching, and the uncomfortable finding is that more than half of notified developers don't fix the hole before it goes public. What the numbers say and how to actually reduce your risk.

BWT editorial June 17, 2026 #plugins

The single most useful thing to internalize about WordPress security in 2026: core is not your problem. The WordPress core codebase is among the most-reviewed open-source projects on the web, and core vulnerabilities are rare and fast-patched. Your risk lives almost entirely in plugins and, to a lesser extent, themes.

The numbers make the case bluntly.

The disclosure firehose

Vulnerability disclosure keeps accelerating. In just the first week of 2026, 333 new vulnerabilities were disclosed across the ecosystem — and 120 of them had no patch available when they went public. Wordfence’s April 2026 reporting logged 157 vulnerabilities across 122 plugins and 27 themes in a single month. Patchstack has become the largest vulnerability discloser of all time, surpassing Wordfence, WPScan, and even Microsoft and GitHub by volume.

More disclosure is good — it means more researchers are looking. But it also means the window between “a flaw exists” and “everyone knows about it” is shrinking, and the patch doesn’t always make that window.

The uncomfortable finding

The most damning data point in Patchstack’s 2026 reporting: more than half of plugin developers who were privately notified of a vulnerability did not patch it before public disclosure.

Sit with that. The responsible-disclosure model assumes a vendor fixes the hole during the private window, then the details go public once users can update. For the majority of notified plugins, that’s not happening. The flaw goes public unpatched, and every site running that plugin is exposed until — if — the developer ships a fix.

This is the core argument for tracking vendor health, not just features. A plugin from a vendor with a slow or absent security-response track record is a standing liability no matter how good the feature set is. It’s exactly why every plugin entry in our directory surfaces its open-CVE count up front, and why the vendor health dashboard weights release responsiveness.

The scale of the attack traffic

Wordfence — the most widely deployed WordPress security plugin — blocks roughly 55 million exploit attempts and over 6.4 billion brute-force attacks every month across its network. That’s not a targeted-attack picture; it’s automated, indiscriminate, internet-wide scanning. (Our own 404 logs show the same thing in miniature: a steady drip of bots probing for .env files, wp-login.php, and abandoned-plugin backdoors.)

The implication: you don’t need to be a target. The scanning is automatic and constant, and an unpatched known vulnerability will be found.

The security plugins that matter

A security plugin doesn’t eliminate the risk — it buys detection, a firewall layer, and time. The two we track in the security category:

  • Wordfence — the endpoint firewall and malware scanner with the largest threat-intelligence network. Free tier is genuinely useful; the paid tier buys real-time rule updates.
  • Akismet — narrower scope (spam), but spam is an attack surface too, and it’s Automattic-maintained with a long track record.

One caveat worth stating plainly: a security plugin is itself a plugin, with its own attack surface. Pick ones from vendors with fast security-response histories, and don’t stack five of them thinking more is safer.

The hardening checklist that beats another plugin

Most security wins are configuration and discipline, not installs:

  1. Update relentlessly. The majority of compromised sites were running a known, patched vulnerability. Enable auto-updates for plugins you trust.
  2. Prune ruthlessly. Every deactivated-but-installed plugin is still code on disk. Delete what you don’t use.
  3. Vet vendor health before installing. A plugin from an abandoned or slow-to-patch vendor is a future incident. Check the last release date and open-CVE count.
  4. Least privilege. Fewer admins, strong unique passwords, 2FA on every admin account.
  5. Off-site backups. When prevention fails, a clean restore is the whole game. Keep backups somewhere the site can’t write to.
  6. Stay on supported PHP. Old PHP versions stop getting security fixes; the host won’t always nag you.

The call

The WordPress security story in 2026 isn’t a doom story — it’s a discipline story. The platform is fine. The risk is the plugins you add and the updates you skip. Treat plugin selection as a security decision, keep the surface small, patch fast, and back up off-site. That ordinary discipline beats any single security plugin you could install.

Methodology

Vulnerability and attack-volume figures are drawn from Patchstack’s and Wordfence’s published 2025-2026 reporting and rounded; treat them as directional. Open-CVE counts on our plugin entries refresh on every build from upstream vulnerability databases — a zero means no known open advisory, not a guarantee of safety. See our methodology page for sourcing detail.