Every WordPress site owner lives with the same quiet bargain. You install a plugin to add a contact form, a booking calendar, or an SEO panel, and in exchange for that convenience you hand a stranger's code direct access to your database, your filesystem, and your network. The plugin is almost certainly fine. But "almost certainly" is doing a lot of work in that sentence, because nothing in the WordPress architecture stops a malicious or compromised plugin from reading your unpublished posts, editing another plugin, or shipping your data to a server in another country.
Cloudflare thinks this bargain is the thing holding content management back, and in 2026 it did something about it. On April 1, the company announced EmDash, a full-stack CMS built entirely in TypeScript on Astro, calling it the "spiritual successor to WordPress." Plenty of people assumed the April 1 date meant it was a joke. It was not. On September 28, Cloudflare shipped EmDash 1.0: stable, MIT licensed, open source, with more than 175 contributors and 1,800 commits behind it. As proof of scale, Cloudflare migrated its own blog to EmDash in August, where it handles millions of pageviews per week and legitimate traffic spikes up to 5,000 requests per second.
The headline feature is a different plugin security model. And that feature matters because of one number: by Cloudflare's count, cited in TechRadar's coverage, roughly 96% of WordPress vulnerabilities come from plugins. Not from PHP core, not from the server, from plugins.
One disclosure before the comparison: I have not migrated a production site to EmDash. Everything here comes from Cloudflare's announcements, the plugin sandbox documentation, and early production reports, and I will be explicit about which claims are vendor-reported. What follows is a design-level comparison of the two architectures, because the right question is not "is EmDash better" but "which trade-offs fit your site."
The core difference: trust versus enforcement
WordPress runs plugins as peers. A WordPress plugin is PHP code executing inside the same process as WordPress core, with direct access to the database, the filesystem, and the network. There is no boundary between "the site" and "the plugin." Cloudflare's 1.0 announcement puts it plainly: a contact-form plugin in WordPress can technically read unpublished posts, modify another plugin, or send data anywhere, and site owners must simply trust that it will not, including in future updates.
EmDash runs plugins in jail. Every EmDash plugin executes in its own isolated runtime with private storage, and it starts with access to nothing: not the site's content, not media, not users, not secrets, not the filesystem, not the network. It gains abilities only when the plugin declares them in a manifest and the site administrator approves them. The runtime enforces those boundaries; they do not depend on the plugin author's good intentions.
On Cloudflare's platform, each plugin runs as a Dynamic Worker, a V8 isolate spun up on demand. The clever part is that this is not Cloudflare-only. On a self-hosted Node.js server, EmDash starts workerd, the open-source Workers runtime, as a separate process and runs plugins inside it with the same manifests and capability-gated APIs. The plugin sandbox documentation covers the differences between the two setups.
What a sandboxed plugin actually looks like
From Cloudflare's launch post, here is a complete plugin that emails editors when a post goes live:
import { definePlugin } from "emdash";
export default () =>
definePlugin({
id: "notify-on-publish",
version: "1.0.0",
capabilities: ["read:content", "email:send"],
hooks: {
"content:afterSave": async (event, ctx) => {
if (event.collection !== "posts" || event.content.status !== "published") return;
await ctx.email!.send({
to: "editors@example.com",
subject: `New post published: ${event.content.title}`,
text: `"${event.content.title}" is now live.`,
});
ctx.log.info(`Notified editors about ${event.content.id}`);
},
},
});
Two lines of that manifest carry the whole security model. capabilities: ["read:content", "email:send"] means the plugin can read content and send email, and per Cloudflare's post, it is impossible for the plugin to do anything else. It has no external network access. A plugin that asks for email:send cannot reach your user table, because the capability for that simply does not exist inside its runtime.
Installing one feels more like installing a mobile app than a server plugin. EmDash shows you what the plugin wants to do before it runs, and the runtime holds it to that list. Cloudflare's 1.0 announcement walks through concrete examples of how these abilities stay independent:
- A search indexer plugin can read published articles and contact the search service. It cannot edit articles or contact other hosts.
- An image optimizer can read and manage media. It cannot read user content.
- A notification plugin can observe publishing and send email. It cannot change the content being published.
- A webhook plugin can read selected events and contact public destinations. It cannot reach private networks or another plugin's storage.
That independence is the part that matters. In WordPress, granting a plugin one access effectively grants all of them. In EmDash, media access does not expose users, and network access to one service does not open the network.
The registry: no more trusting the marketplace
The second half of the security story is distribution. Historically, if you wanted to know whether a WordPress plugin was safe, you leaned on the marketplace's vetting and on reputation. Cloudflare points out that WordPress has a queue of hundreds of plugins waiting for security review at any given time, which tells you how well scale and manual review mix.
EmDash 1.0 launched a decentralized plugin registry built on AT Protocol, the same protocol behind Bluesky. The design separates three roles that traditional registries combine: publisher identity, the authoritative package record, and the discovery catalog.
- Publishers own their records. Plugin packages and release history live in the publisher's own signed account, not in a company's database. A catalog cannot suspend an author into oblivion.
- Verification is cryptographic. Atproto repositories use signed Merkle Search Trees, so EmDash can verify a release record independently, then check the downloaded bundle's checksum, package name, version, and requested access against the signed record.
- Moderation does not mean ownership. The default catalog applies content moderation to what it displays, but hiding a listing does not rewrite or erase the underlying publication, and other services can index the same publications with their own policies.
This does not magically make third-party plugins safe to run. It makes them inspectable, which combined with capability manifests means you can answer "what could this code do to me" from the artifact itself instead of from star ratings.
What else EmDash brings to the table
AI-native tooling is built in. EmDash ships an MCP server, a CLI, and agent skills, so a coding agent can drive content migrations and editorial chores programmatically. Cloudflare reports that Avulux, a company that switched from WordPress after tiring of its maintenance burden, completed its conversion in under a day using EmDash Agent Skills.
Payments are a config option, not a plugin project. Every EmDash site has x402 support built in: you mark content as paid, set a price, and provide a wallet address. A client that cannot pay receives an HTTP 402, pays on demand, and gets through. For the growing crowd of publishers worried about AI agents consuming content with no human seeing an ad, that is a business model in a checkbox.
Serverless economics. On Workers, an EmDash site scales to zero when idle and bills only for CPU time. Themes are Astro projects (pages, layouts, components, styles, and a seed file defining content types), and since Astro's popularity with developers and LLMs keeps climbing, both humans and agents already know how to build them.
Migration paths exist. You can import a WordPress WXR export, and custom post types map to EmDash collections, which is a cleaner model than the classic trick of squeezing custom fields into a crowded posts table with a heavyweight plugin like ACF.
Where WordPress still wins
A fair comparison has to credit the incumbent, because WordPress is not losing on capability any time soon.
- Ecosystem depth. WordPress powers over 40% of the web and has roughly two decades of plugins, themes, tutorials, agencies, and hiring pools. EmDash's registry is weeks old. Lexington Themes offers 44 Astro themes with EmDash variants, and Urumi is shipping the first eCommerce plugin, but those numbers are a rounding error next to the WordPress directory.
- Cheap, boring hosting. A WordPress site runs on any $5 shared host on earth. EmDash self-hosted needs Node.js plus workerd, and the best experience, including the Dynamic Worker plugin sandbox, assumes Cloudflare. The xCloud writeup of EmDash flags this trade-off directly: platform coupling, with database, storage, and plugin runtime all living on one vendor's stack.
- Cost of the sandbox. Per that same writeup, the sandboxed plugin runtime needs a paid Workers plan on Cloudflare. Free-tier hobbyists should price that before migrating.
- Maturity risk. EmDash hit 1.0 on September 28, 2026. The 1.0 label comes with production workflows for editorial, media, localization, and migration, and the Cloudflare Blog deployment is genuine evidence at scale, but it is one organization's evidence. WordPress's edge cases have been found and fixed by millions of sites over decades.
The decision checklist
If you are weighing the two, here is the short version I would actually use:
- Stay on WordPress if your site depends on specific plugins with no EmDash equivalent, your budget lives on cheap shared hosting, or your team's skills and vendor relationships are all PHP.
- Harden instead if you stay: audit installed plugins quarterly, delete anything inactive, prefer plugins with a history of fast security releases, and keep automatic core updates on. The 96% number is a plugin problem, and plugin hygiene is where the wins are.
- Try EmDash if you are starting a content site fresh, you already know TypeScript or Astro, your team wants agents to manage content through MCP, or you are an agency building sites for clients where the per-plugin blast radius is your biggest liability.
- Pilot before committing if you have an existing WordPress site: import your WXR into a scratch EmDash instance, check what breaks in your content model, and only then decide. Migration cost is the real gate, not features.
The honest summary is that EmDash attacks the one structural weakness WordPress cannot fix without breaking itself. WordPress cannot sandbox plugins without orphaning twenty years of plugin code, so it competes on ecosystem and inertia instead. EmDash cannot match two decades of ecosystem, so it competes on architecture. For new sites, that competition finally has an interesting answer.
I write about developer tools, backend engineering, and AI infrastructure every week. Subscribe, it is free.
Have you hit a WordPress plugin security scare yourself, or are you already testing EmDash? I would like to hear which way you are leaning in the comments.
