Cloudflare argues that WordPress's core API contract gives every plugin full trust in a shared execution environment, meaning a contact form can read database credentials and a compromised SEO plugin can exfiltrate user data. They contend this isn't a bug but the fundamental architecture, and that decades of failure to fix plugin isolation prove it requires a clean-sheet redesign rather than incremental patches.
Cloudflare positions the choice of Workers as architecturally essential rather than incidental, because V8 isolate-based sandboxing gives every plugin its own execution context by default. By building on their own stack, EmDash inherits memory isolation, per-request permission scoping, and infrastructure-level security guarantees that would be difficult to retrofit onto a traditional server-side CMS.
The blog post argues that WAFs pattern-matching known exploits, automatic plugin updates racing against zero-days, and security plugins are all edge-case mitigations that leave the fundamental shared-trust model intact. With an estimated 90% of hacked WordPress sites compromised through plugin vulnerabilities, these defenses have demonstrably failed to solve the problem at scale.
By surfacing the post to Hacker News with the framing 'solves plugin security,' elithrar signals agreement that WordPress's plugin security is the central problem worth solving and that EmDash's permission-based model represents a meaningful departure from prior mitigation-only approaches.
Cloudflare published a detailed blog post introducing EmDash, a new content management system they're positioning as a spiritual successor to WordPress. The project doesn't fork WordPress or attempt backward compatibility — it's a ground-up rebuild designed around one core thesis: the plugin model that made WordPress dominant is the same model that makes it indefensible.
WordPress powers roughly 43% of all websites on the internet. That install base makes it the single largest attack surface in web software. The root cause isn't PHP itself (though that doesn't help) — it's that every WordPress plugin runs with full trust in a shared execution environment. A contact form plugin can read your database credentials. A gallery widget can write to the filesystem. A compromised SEO plugin can exfiltrate every row in `wp_users`. EmDash's fundamental design decision is that no plugin should ever have access to anything it didn't explicitly request and receive permission for.
The project is built entirely on Cloudflare's own infrastructure: Workers for compute, R2 for storage, D1 for the database layer, and KV for caching. This isn't incidental — it's architectural. By running on Workers, EmDash inherits V8 isolate-based sandboxing for every plugin execution context.
WordPress's security problem is structural, not incidental. The platform has had decades to fix plugin isolation and hasn't, because doing so would break the ecosystem that makes WordPress valuable. Every plugin assumes it can `require()` whatever it wants, read `wp-config.php`, and query the database directly. That's not a bug — it's the API contract, and it's why an estimated 90% of hacked WordPress sites were compromised through a plugin vulnerability.
Previous attempts to solve this have all worked around the edges: Web Application Firewalls that pattern-match known exploits, automatic plugin updates that race against zero-days, and security plugins that are themselves additional attack surface. Cloudflare, having spent years watching WordPress traffic patterns through their CDN and WAF, apparently concluded that the only way to fix the problem is to not have it in the first place.
EmDash's sandboxing model borrows from the same capability-based security thinking behind Deno's permission system and Android's app sandbox. Each plugin declares what it needs — database read, storage write, network access to specific domains — and the runtime enforces those boundaries at the isolate level. A gallery plugin literally cannot make a network request to an external server unless its manifest includes that permission and the site owner approved it. This is a meaningful departure from WordPress's "install and pray" model.
The choice to build on Workers also has performance implications. Traditional WordPress requires a PHP process to spin up, query MySQL, assemble HTML, and serve it — a cycle that runs on every uncached request. EmDash pages are edge-computed, meaning the CMS logic runs in the Cloudflare PoP closest to the user. For a typical content site, this should translate to sub-50ms TTFB globally without any caching layer — because the compute *is* the edge.
The Hacker News response (558 points as of publication) signals real developer interest, but the comment threads reveal a predictable split. Enthusiasts see a long-overdue rethinking of how CMS platforms handle trust. Skeptics see vendor lock-in with extra steps — your entire site running on Cloudflare's proprietary stack, with no self-hosting option and no exit path that doesn't involve a rewrite.
This is where the editorial honesty matters. EmDash is not open infrastructure — it's a proprietary CMS that runs exclusively on Cloudflare's platform. Workers, D1, R2, and KV are Cloudflare products. If Cloudflare raises prices, deprecates a service, or makes architectural decisions you disagree with, your options are limited.
WordPress, for all its security nightmares, runs on any $5/month VPS. You can move hosts in an afternoon. Your data is in a MySQL database you control. Your themes and plugins are PHP files you can read, modify, and fork. That portability is genuine value, and EmDash trades it away entirely.
Cloudflare's counterargument is implicit in the architecture: most WordPress sites *already* run behind Cloudflare's CDN, and the typical WordPress operator isn't exercising that theoretical portability anyway. They're paying $30/month for managed WordPress hosting that handles updates and backups. EmDash argues: what if the hosting layer was the CMS layer, and both were secure by default?
The honest framing: this is a bet that security and performance matter more to the next generation of CMS users than self-hosting portability. For agencies managing dozens of client sites, that bet might be correct. For a developer who wants to own their stack, it's a non-starter.
If you're running WordPress sites professionally — especially for clients who don't have a dedicated security team — EmDash is worth evaluating the moment it opens access. The plugin security model alone addresses the single largest operational headache in WordPress management: the constant anxiety of "which of my 23 plugins got compromised this month?"
If you're building on WordPress as an API (headless WordPress + React/Next.js frontend), the calculus is different. You've already decoupled the frontend, so the CMS is just a content API. EmDash would need to offer a comparable REST/GraphQL API with the content modeling flexibility that Advanced Custom Fields and custom post types provide in WordPress. That's a high bar.
For the broader CMS ecosystem, EmDash matters less as a product and more as a proof of concept: you *can* build a CMS with sandboxed plugins that doesn't sacrifice the extensibility that makes CMSes useful. If EmDash succeeds, expect Automattic to finally prioritize plugin isolation in WordPress core — something the community has requested for over a decade. If it fails, the lesson will be that WordPress's moat is ecosystem breadth, not technical quality, and that lesson will be correct too.
Developers building Cloudflare Workers-based applications should pay particular attention to the plugin SDK. Even if you never use EmDash as a CMS, the patterns for building sandboxed, capability-gated extensions on Workers will likely be extracted into standalone tooling. Cloudflare has a track record of shipping platform features as blog post case studies first.
The CMS market hasn't seen a credible new entrant with real distribution since... arguably Ghost in 2013, and Ghost deliberately chose a narrower lane (publishing, not general-purpose). Cloudflare has distribution that Ghost never did — millions of sites already running through their network, a developer platform with momentum, and the ability to offer a CMS as a one-click addition to an existing Cloudflare account. Whether EmDash captures meaningful WordPress migration depends entirely on the plugin ecosystem. Security gets you in the door. Plugins that actually work keep you there. The next 12 months will determine which side of that equation Cloudflare can solve faster.
This is very interesting. I've worked with WordPress on and off for 10 years, and I'm convinced that this project has got 2 things absolutely spot on. TypeScript and Worker plugins.I've given the security, or lack of, WP a lot of thought recently. In WP malicious plugin has access to
In my opinion, Cloudflare are coming at this from the wrong angle. WordPress is so popular because back in the day it was the easiest way to get a website built. So it got a network effect of engineers behind it which is why it persists at 40% of websites today. Same thing happened with React - majo
I run a handful of WordPress sites. The plugin problem is real. I've spent more time managing plugin updates, conflicts, and security patches than actually building content for the sites.But the reason I'm still on WordPress isn't loyalty. It's that my clients can maintain their
From the readme on GitHub:> A full-stack TypeScript CMS built on Astro and Cloudflare. EmDash takes the ideas that made WordPress dominant -- extensibility, admin UX, a plugin ecosystem -- and rebuilds them on serverless, type-safe foundations.Someone should introduce the authors to the lovely em
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.
> Our name for this new CMS is EmDash. We think of it as the spiritual successor to WordPress. It’s written entirely in TypeScript. It is serverless, but you can run it on your own hardware or any platform you choose. Plugins are securely sandboxed and can run in their own isolate, via Dynamic Wo