96% of WordPress Hacks Start With Plugins. Cloudflare’s EmDash CMS Fixes That.

Plugins are responsible for 96% of WordPress vulnerabilities. Cloudflare just shipped a CMS that sandboxes every single one. Here’s what security teams need to know — and what they should be skeptical about.

• 96% of new WordPress vulnerabilities come from plugins (Patchstack 2025)
• 40%+ of the entire web runs on WordPress
• 24 yrs WordPress’s age — older than AWS EC2

I’ve been watching the “WordPress killer” narrative cycle through the industry for years. Ghost, Contentful, Strapi, and Sanity are all real products, none of them actually threatening WordPress’s grip on 40% of the web. So when something new launches with that positioning, my default is to be skeptical.

EmDash is different, and the difference isn’t the feature set. It’s who built it and why.

On April 2, 2026, Cloudflare announced EmDash — a fully open-source, serverless CMS built on Astro 6.0, written in TypeScript, with every plugin running in an isolated sandbox. Cloudflare handles a significant fraction of the world’s internet traffic. They don’t need EmDash to be profitable. They need the web to be more serverless, more secure, and more dependent on Cloudflare infrastructure. That incentive structure is what makes this worth taking seriously.

The problem is structural, not operational.

The WordPress plugin security story isn’t new, but it keeps getting worse. Patchstack’s 2025 report finds that 96% of new WordPress vulnerabilities are in plugins. Themes account for 4%. Core: under 0.1%. I’ve seen this play out firsthand with hosting clients — the compromise almost always traces back to an outdated or poorly coded plugin.

The root issue: a WordPress plugin runs inside the same PHP environment as WordPress core. It gets unrestricted access to your database, filesystem, and admin session. One bad plugin is a full site compromise. You can’t patch your way out of a trust model that was designed before cloud infrastructure existed.

Cloudflare’s framing is pointed: WordPress is 24 years old. AWS EC2 didn’t exist when it launched. WordPress Hosting has gone from managing VPS stacks to deploying a JavaScript bundle to a global edge network. The question isn’t whether WordPress needs to change, but whether it can.

What EmDash actually does differently

EmDash doesn’t try to fix WordPress. It rebuilds the concept from scratch using three architectural decisions that matter to security teams.

Sandboxed plugins

Every EmDash plugin runs inside its own V8 isolate — completely isolated from core and from other plugins. Before installation, a plugin must declare exactly which capabilities it needs, such as read:content, email:send, and so on. It cannot reach outside those declared permissions. Think of it as the mobile app permission model applied to server-side CMS plugins. A plugin that sends email notifications cannot, by design, touch your database.

Passkeys by default

EmDash ships with passkey authentication as the default, so there are no passwords to brute-force, no credentials to leak. WordPress ships with a username/password login form that hasn’t fundamentally changed in two decades.

No HTML blobs

WordPress stores rich text as raw HTML with metadata buried in HTML comments. EmDash uses Portable Text — structured JSON that decouples content from its DOM representation. This eliminates injection risk categories arising from parsing and re-rendering arbitrary HTML, and it means content can render across the web, mobile, email, and APIs without unsafe manipulation.

The AI-native angle cuts both ways.

EmDash ships with a built-in MCP server, a JSON-output CLI, and documentation structured for machine consumption. AI agents like Claude or Cursor can manage your content types, entries, and plugins directly. The GitHub repo describes it as “agent-native, not agent-compatible.”

That’s genuinely new. But every new AI-accessible surface is a new attack surface.

If an agent has MCP-level access to your CMS, what are the session boundaries?

How is that access scoped and revoked?

EmDash doesn’t yet have mature answers to those questions, and security teams need to ask them before developers enthusiastically adopt this.

“EmDash is the first CMS designed from the ground up for how we work in 2026: AI agents building sites, structured content that machines can parse, and deployment at the edge.” — Joost de Valk, joost.blog

What I’d push back on

The 96% stat is real but weaponized. Patchstack confirms it for recent vulnerability disclosures; older cumulative CVE data puts plugin share closer to 70–80%. The trend is clear. The precision is marketing.

The sandbox is a sound concept running on proven technology. Cloudflare uses V8 isolates at a massive scale for Workers. But EmDash’s capability API hasn’t been adversarially tested in production. The Hacker News thread reaction was measured: “interesting architecture, but we’ve heard this before.” That’s the right posture.

And it was built in two months using AI coding agents. That’s a remarkable demonstration of what’s possible. It’s also not the same as two decades of edge-case hardening. WordPress has 60,000 plugins, a global developer community, and battle-tested security tooling. EmDash has a well-reasoned architecture and a v0.1.0 badge.

What to do with this right now

Don’t migrate. Not to a beta CMS with no ecosystem, no production case studies, and no WooCommerce equivalent, regardless of how good the architecture is. The right move on your existing WordPress estate is still proper maintenance: keep plugins updated, run a security scanner, and use a managed host with WAF coverage.

But do read the Cloudflare engineering post and pull the GitHub repo. Use EmDash’s capability-declaration model as a lens to audit how much trust you’re implicitly granting your current WordPress plugins. Test the MCP server in a sandbox and understand what agent-level CMS access actually means for your threat model.

The plugin sandboxing and passkey-first defaults represent where CMS security has to go. Cloudflare just put that on record, in open-source code, backed by infrastructure-scale credibility. That matters whether EmDash itself becomes the platform or forces every other CMS vendor to answer for their plugin trust model.

Frequently asked questions

What is EmDash CMS?

An open-source serverless CMS launched by Cloudflare in April 2026, built on Astro 6.0 and TypeScript. Plugins run in isolated V8 sandboxes with declared permissions. Passkey authentication is the default. It includes a built-in MCP server for AI-agent workflows.

Is EmDash more secure than WordPress?

Architecturally, yes — the sandbox model prevents plugins from accessing anything outside their declared permissions, which eliminates the core WordPress plugin risk. But EmDash is in beta and hasn’t been tested at scale. Architectural superiority and production security are not the same thing.

Should I migrate from WordPress to EmDash?

No. Not now. EmDash is v0.1.0 with no ecosystem. Watch it for 12–18 months. For new greenfield projects, it’s worth a serious evaluation once the plugin marketplace and community develop.

Is EmDash vendor-locked to Cloudflare?

It’s MIT-licensed and can run on any Node.js server with SQLite. In practice, it’s optimized for Cloudflare Workers, D1, and R2. Running it elsewhere takes real engineering effort.