WordPress runs 43% of the web. That number gets cited so often it's lost all meaning, but the security data behind it hasn't. Patchstack's 2025 report found that 96% of all new WordPress security vulnerabilities came from plugins and themes. Not WordPress core. Plugins. The things every WordPress site needs to actually do anything useful.
Cloudflare's response: build a CMS from scratch where plugins physically cannot access anything beyond what they declare. EmDash launched in March 2026 as an open-source, MIT-licensed CMS built on Cloudflare Workers with Astro for static generation. The pitch is simple. Every plugin runs inside a V8 isolate. No filesystem access. No network access. No database queries. Unless the plugin's manifest explicitly requests them, and the site owner explicitly grants them.
What WordPress Gets Wrong About Plugins
WordPress plugins run with full access to the WordPress runtime. A plugin that adds a contact form has the same level of access as a plugin that manages backups. Both can read the database. Both can write to the filesystem. Both can make outgoing network requests. Both can modify other plugins.
This is how a vulnerability in a contact form plugin leads to a full site takeover. The plugin didn't need database write access to do its job, but it had it anyway, and an attacker exploited that.
The WordPress ecosystem has tried to fix this at the review layer. Plugin submissions go through a manual review process. But with over 60,000 plugins and a volunteer review team, the math doesn't work. Supply chain attacks in the WordPress plugin directory have become routine. In 2024 alone, five popular plugins were compromised through stolen developer credentials, not through code review failures.
Cloudflare's argument is that the review layer is the wrong place to solve this. The right place is the runtime.
How EmDash Sandboxes Plugins
Every EmDash plugin runs inside a V8 isolate. This is the same sandboxing technology that Cloudflare Workers uses to run millions of untrusted workloads on the same hardware without them interfering with each other.
A plugin declares what it needs in its manifest:
{
"name": "contact-form",
"version": "1.0.0",
"permissions": {
"database": {
"collections": ["form_submissions"],
"operations": ["create", "read"]
},
"network": {
"allowedDomains": ["api.sendgrid.com"]
},
"storage": false,
"admin": false
}
}
This contact form plugin can create and read records in a single collection, and make outgoing requests to SendGrid. That's it. It can't read other collections, can't modify its own table schema, can't access the filesystem, and can't call any other external domain. If the plugin is compromised, the blast radius is limited to what it was allowed to do in the first place.
Compare that to WordPress, where the same contact form plugin would have access to $wpdb (the entire database), file_get_contents (the filesystem), and wp_remote_get (outgoing HTTP to anywhere).
The manifest-based model isn't new. Android, iOS, and browser extensions all use permission manifests. But no major CMS has applied this to plugins before. EmDash is the first.
The Architecture
EmDash is built on three layers.
Runtime: Cloudflare Workers. The CMS runs entirely on edge compute. No origin server, no VM, no container. Each request is handled by a Worker that boots in under 5ms. Storage is D1 (SQLite at the edge) for structured data and R2 (object storage) for media.
Static generation: Astro. Content is compiled to static HTML at build time, with optional server-side rendering for dynamic routes. Astro was chosen because it ships zero JavaScript by default and supports partial hydration, which means interactive components only load client-side JavaScript when they need to.
Plugin runtime: V8 isolates. Each plugin runs in its own isolate with a constrained API surface. The plugin can only call functions that the CMS exposes through a controlled bridge, and only for the permissions it declared.
The result is a CMS that deploys globally in seconds, has no traditional server to patch, and treats every plugin as potentially hostile code.
What EmDash Actually Ships With
The initial release is opinionated. Cloudflare built the things most CMS users need and skipped the things that create complexity.
Passkey authentication: No passwords. Site owners authenticate with WebAuthn passkeys (fingerprint, face, hardware key). No password database means no credential stuffing, no brute force attacks, and no password reset flows to secure.
Built-in MCP server: EmDash ships with a Model Context Protocol server that lets AI assistants read and write content. Given what we covered in MCP's security problems, Cloudflare's implementation is worth watching. They've confirmed the MCP server respects the same per-plugin permission model. An AI assistant using MCP can only access collections and operations that the connected plugin allows.
x402 payment protocol: Experimental support for HTTP 402-based micropayments. Content creators can gate articles behind single payments without integrating third-party subscription platforms. This is early and most browsers don't support it yet, but it's the kind of forward-looking feature that makes sense for a company that controls a significant chunk of web infrastructure.
Content API: RESTful and GraphQL endpoints for headless usage. You can use EmDash as a headless CMS feeding a Next.js, Nuxt, or Astro frontend, or use its built-in rendering.
What's Missing
EmDash launched as a 0.x release. Cloudflare was upfront about what isn't ready:
Plugin ecosystem: There are roughly a dozen first-party plugins. WordPress has 60,000+. This is the obvious challenge. A CMS is only as useful as its plugin ecosystem, and building that takes years, not months.
Migration tooling: No WordPress-to-EmDash migration path exists today. If you have a WordPress site with 500 posts, custom fields, and WooCommerce, you're not switching to EmDash this quarter.
Community: WordPress has a 20-year community. EmDash has a GitHub repo with a few hundred stars. The documentation is solid but thin. Community forums don't exist yet.
Visual editing: No drag-and-drop page builder. Content is Markdown-based with structured content types. If your content team relies on Elementor or Gutenberg, they'll need to adjust.
Should You Care?
That depends on what problem you're solving.
If you're building a new content site from scratch and you're already on Cloudflare's stack (Workers, D1, R2), EmDash is worth evaluating. The security model is genuinely better than WordPress, the deployment story is simpler, and the performance ceiling is higher because there's no origin server to bottleneck.
If you're running an existing WordPress site that works fine, EmDash isn't a reason to migrate. The plugin ecosystem isn't there. The migration tooling isn't there. And "96% of vulnerabilities come from plugins" is a solvable problem with proper plugin auditing, update management, and a web application firewall. It just requires ongoing effort that most teams skip.
If you're in the "WordPress gives me anxiety but I can't justify a custom build" category, EmDash goes on the watch list. Check back in six months when the plugin ecosystem has had time to develop.
The more interesting question is whether EmDash's sandboxing model gets adopted by other platforms. The V8 isolate approach is technically proven at scale (Cloudflare runs it for millions of Workers). If EmDash demonstrates that a manifest-based plugin permission model works for a CMS without destroying developer experience, expect similar models to show up in Drupal modules, Shopify apps, and other plugin ecosystems.
We've built plenty of WordPress sites and custom web platforms for clients, and the security posture question comes up in every project. The honest answer has always been that WordPress security is a process, not a product. You need maintained plugins, regular updates, proper hosting, WAF rules, and someone watching the logs.
EmDash is trying to make it a product. Whether that succeeds depends more on ecosystem adoption than technology, and ecosystem adoption is the one thing you can't rush. But the underlying idea, that plugins should prove they deserve access instead of getting it by default, is correct. It's the direction the web should have gone a decade ago.
If your team is evaluating CMS options for a new project or concerned about the security posture of your current platform, reach out. We'll help you pick the right tool for the actual problem.
