Installing a WordPress plugin still kind of feels like copy‑pasting a random script and running it as “root” on your own site. You skim the reviews, glance at active installs, mutter a small prayer, and click Install anyway. We’ve all done it. And the ugly stat behind vibe is real: 96% of security issues for WordPress sites originate in plugins. Why? Because plugins, by default, get way too much power. Cloudflare’s new CMS, EmDash, is a serious swing at fixing that exact problem without throwing away the “CMS + plugins” workflow people actually want. Yes, the keyword is EmDash. Loud and clear.
Key takeaways
Here’s the gist, with the parts you’ll actually care about:
- EmDash is a WordPress-like CMS written entirely in TypeScript. It’s built for modern hosting. Serverless-first, but not married to a single platform. - Plugin security in EmDash is capability-based. A plugin has to ask for permissions up front, and it simply can’t do anything outside them. - Each EmDash plugin runs in an isolated sandbox using “Dynamic Workers” isolates. Smaller blast radius than WordPress’s shared PHP runtime. - The plugin risk in WordPress isn’t some theoretical boogeyman. Cloudflare cites the 96% number, and Patchstack reports 7,966 new WordPress ecosystem vulnerabilities in 2024, which is up 34% YoY. - This cuts down on marketplace “trust theater.” You don’t have to squint at star ratings and vibes. You can judge a plugin by what it’s requesting.
What is EmDash, really?
EmDash is an open-source, MIT-licensed CMS from Cloudflare, positioned as a spiritual successor to WordPress. It’s written in TypeScript, powered by Astro, and designed around strict plugin sandboxing using Dynamic Workers isolates. Cloudflare also makes a point of saying no WordPress code was used. That’s a big part of how they can ship it under MIT. Source: Cloudflare launch post
https://blog.cloudflare.com/emdash-wordpress/
Why EmDash exists: WordPress plugin security is structurally messy
WordPress is a monster success. Cloudflare points out it powers over 40% of the Internet, which lines up with the number everyone quotes and explains why attackers keep circling it like sharks. But WordPress is also old. Cloudflare says it’s turning 24 this year, and yeah, the plugin model comes from a different hosting era. The core problem is painfully simple:
A WordPress plugin is PHP that hooks into WordPress. There’s basically no isolation. A plugin can typically rummage around in your database and filesystem like it owns the place. So “plugin security” becomes “every plugin author must write perfect code forever.” Come on. Patchstack’s 2024 report adds the extra sting: 7,966 new vulnerabilities were found in the WordPress ecosystem in 2024, mostly in third-party plugins, a 34% increase over 2023. And more than half of plugin developers Patchstack notified didn’t patch before public disclosure. Source: Patchstack report
https://patchstack.com/whitepaper/state-of-wordpress-security-in-2024/
EmDash plugin security: capability permissions + isolated sandboxes
Here’s the part I actually care about as a developer. EmDash flips the default trust model. It stops assuming plugins are innocent until proven guilty. Cloudflare’s design, in plain language:
- Each plugin runs inside its own sandbox using a Dynamic Worker isolate. 2) The plugin has to declare capabilities in a manifest up front. 3) EmDash only hands the plugin the APIs, the “bindings,” it asked for. 4) Anything else is off-limits. Not “please don’t.” More like “you literally can’t.”
Cloudflare describes it as a strict guarantee: an EmDash plugin can only perform actions explicitly declared in its manifest. Think OAuth consent screen vibes, but for CMS plugins. Source: Cloudflare’s EmDash post
https://blog.cloudflare.com/emdash-wordpress/
Example: an EmDash plugin can send email
Adapted directly from Cloudflare’s EmDash announcement. Look at the capabilities list. It’s blunt on purpose. ts import { definePlugin } from "emdash". Export default () => definePlugin => { if return. Await ctx.email!.send. Ctx.log.info. }, }, }).
If it didn’t request email:send, it doesn’t get ctx.email. No email API, no emailing. Same deal for content access. And Cloudflare notes something else that matters a lot: by default, plugins have no external network access unless they declare which hostnames they need. That’s a very different world from “oops, this plugin can read wp-config.php.”
Why isolates matter: Dynamic Workers and the Cloudflare Workers security model
When Cloudflare says “isolate,” they’re leaning on the Cloudflare Workers runtime model, V8 isolates. The Workers docs describe isolates as lightweight sandboxes where each isolate’s memory is completely isolated from others, and the platform is built for multi-tenant safety. Source: Cloudflare Docs, How Workers works
https://developers.cloudflare.com/workers/reference/how-workers-works/
The Workers security model doc gets more specific. Workers limit timing APIs, like freezing Date.now() during execution, and they avoid exposing local timers and concurrency primitives that can help side-channel attacks. They also talk about defense-in-depth with process isolation, Linux namespaces, and seccomp. Source: Cloudflare Docs, Workers security model
https://developers.cloudflare.com/workers/reference/security-model/
If you want a hands-on explanation of Dynamic Workers and sandboxing untrusted code, I wrote about it here:
https://www.basantasapkota026.com.np/2026/03/dynamic-workers-cf-run-untrusted-code.html
EmDash vs WordPress plugins: what changes day to day?
A few practical shifts I’d expect teams to feel pretty fast:
Permission review becomes… real. Like, you can set policies such as “editors can install plugins only if they request read-only content access.” WordPress can’t really enforce that cleanly right now. Less “security plugin” whack-a-mole too. Patchstack basically argues malware scanning after the fact can create a false sense of safety. EmDash is trying to prevent whole classes of risky behavior up front. And when a plugin breaks, it should break in its sandbox, not faceplant the whole CMS. That’s the idea, anyway. This also plays nicely with supply-chain reality. We’ve watched trusted packages get compromised upstream. Different ecosystem, same lesson: reduce implicit trust. Related internal link:
https://www.basantasapkota026.com.np/2026/04/axios-got-hacked-detect-npm-rat-and-fix.html
A quick “case study” scenario: the analytics plugin you don’t fully trust
Marketing wants a third-party analytics plugin. In WordPress land, that plugin might end up with broad access to the DB, filesystem, and network. You can harden WordPress, sure. But the plugin still runs inside your app. It’s in the house. In EmDash, the conversation gets a lot cleaner:
- Does it need
read:content? - Does it need network egress, and if yes, to which hostnames?
- Does it need to write anything, or is it just observing events?
That’s a better review process than “it has 4.7 stars and the comments seem fine.”
Sources
- Cloudflare. Introducing EmDash — the spiritual successor to WordPress that solves plugin security
https.//blog.cloudflare.com/emdash-wordpress/ - Patchstack. State of WordPress Security in 2024 (7,966 vulnerabilities; +34% YoY. Plugin-heavy ecosystem risk)
https.//patchstack.com/whitepaper/state-of-wordpress-security-in-2024/ - Cloudflare Docs. How Workers works (V8 isolates, memory isolation, cold start characteristics)
https.//developers.cloudflare.com/workers/reference/how-workers-works/ - Cloudflare Docs. Workers security model (side-channel mitigations, defense-in-depth, sandboxing approach)
https.//developers.cloudflare.com/workers/reference/security-model/ - Hacker News discussion (community reactions and critique; useful for real-world concerns)
https://news.ycombinator.com/item?id=47602832 - Reddit thread (community summary of the permission model; “declared upfront” framing)
https://www.reddit.com/r/CloudFlare/comments/1s9p9yh/introducing_emdash_the_spiritual_successor_to/