27 Independent Codebases
The average WordPress site has 27 active plugins. Each plugin is a separate codebase written by a different developer or team, with its own quality standards, its own security practices, and its own update schedule. You are trusting 27 independent parties with the security of your site.
The Abandonment Problem
WordPress.org lists over 60,000 plugins. An estimated 40% haven't been updated in over 2 years. These plugins remain installed and active on millions of sites. They don't get security patches. They don't get compatibility updates. They just sit there — functional but vulnerable.
The Supply Chain Problem
When a popular plugin maintainer burns out, sells their plugin, or simply walks away, every site running that plugin inherits the risk. In 2025, a popular form plugin with 5 million active installations was sold to a company that injected analytics tracking code without disclosure. 5 million sites were affected overnight.
Patchstack's 2026 report quantified a counterintuitive finding: premium and freemium WordPress components have 3x more Known Exploited Vulnerabilities than free plugins. 76% of premium component vulnerabilities were exploitable in real attacks. Paying more doesn't buy security — it buys a more valuable target with less researcher scrutiny.
This isn't a hypothetical. It happens regularly. Plugin ownership changes hands, maintenance lapses, backdoors are introduced. Each plugin is a link in a supply chain you don't control.
The Compatibility Cascade
WordPress core updates can break plugins. Plugin updates can break other plugins. Theme updates can break both. A single update to WordPress core in March 2025 broke compatibility with over 400 plugins simultaneously. Site administrators faced a choice: skip the security update or break their sites.
The Alternative — And Its Own Risks
Modern frameworks like Astro, Hugo, and Next.js don't have plugins. They have npm dependencies — versioned, lockfile-controlled, auditable, replaceable. When a dependency has a known vulnerability, npm audit flags it immediately. That's a structural improvement over the plugin model.
But 2026 revealed that npm's supply chain has its own class of risk. In the first half of 2026 alone, over 20 npm supply chain attacks were documented — including IronWorm (50+ trojanized packages), the Axios compromise by North Korean group UNC1069, and self-replicating worms that propagated through developer credentials. A lockfile protects against version drift. It does not protect against a compromised version that was the latest when you installed it.
WordPress risk is visible — 18,005 CVEs, catalogued and countable. npm risk is increasingly invisible — trojanized packages, forged provenance, build-time code execution. You traded 27 uncontrolled plugin doors for 800 dependency doors. Different architecture, different threat model, neither safe by default.
The frameworks with the smallest supply chain surface are static generators like Hugo — compiled Go binary, zero npm runtime dependencies, zero plugins. For content sites, that's not a compromise. That's the answer.
