Everyone says the same thing. Plugin sandboxing fixes WordPress security. Capability manifests let you declare exactly what a plugin can do—read content, send email, nothing else. That’s the fix. Cloudflare’s EmDash builds this into its core: every plugin runs in an isolated V8 worker, and it can only touch what you explicitly allow.
It sounds airtight.
The capability manifest doesn’t prevent abuse of the capabilities it grants. It only prevents unauthorized access.
It isn’t.
The capability manifest system is a genuine architectural improvement over WordPress’s all-or-nothing plugin model. But the common advice—that manifests alone prevent plugin abuse—misses where the system bends, breaks, or simply shifts the risk to a different place. Understanding those gaps is what separates a realistic evaluation from marketing copy.
What the Manifest Actually Controls
EmDash requires every plugin to declare its capabilities in a structured manifest. A plugin that sends email upon post publication declares read:contentcodecode and email:sendcodecode. That’s it. The runtime—a dynamic worker running on Cloudflare’s V8 isolates—enforces those boundaries at the hardware level. No database queries beyond what’s declared. No file system access. No unrestricted network calls.
The source material confirms this: “A plugin that declares read content and send email can literally do nothing else.” That’s a powerful statement. It means a compromised plugin cannot exfiltrate password hashes, modify other plugins’ data, or mine cryptocurrency on your server.
So what’s the catch?
The Manifest Trust Problem
The system assumes the plugin developer declares capabilities honestly. That assumption is fragile.
A plugin that needs to read content and send email is trivial to audit. But consider a backup plugin. It needs to read everything—posts, media, users, settings—write files to remote storage, and make network calls to an S3-compatible endpoint. Its manifest would declare something like read:allcodecode, write:allcodecode, network:outboundcodecode. That’s essentially the same level of access a WordPress plugin has by default. The sandbox still isolates the plugin from the core, but the granted permissions are broad enough to cause catastrophic damage if the plugin is malicious or compromised.
The capability manifest doesn’t prevent abuse of the capabilities it grants. It only prevents unauthorized access. A backup plugin with a backdoor can still read every user email and send them to an attacker’s server—because “send email” or “network outbound” is in its manifest.
That’s not a flaw in the architecture. It’s a limitation of any permission system. But the common framing—“plugins can only do what they declare”—implies a level of safety that evaporates once a plugin needs anything beyond trivial access.
The Self-Hosted Blind Spot
Here’s the detail most commentators skip. The full sandbox requires Cloudflare’s dynamic workers, which are only available on the Workers Paid plan ($5+/month). Self-host EmDash on a regular Node.js server, and plugins run in-process—no isolation, no capability enforcement. The same code, the same security model, but with zero sandboxing.
The source material is explicit: “The full sandbox only works on Cloudflare’s runtime. Self-host M- on a regular Node.js server and plugins run in process without isolation.”
So the advice “EmDash fixes plugin security” is only true if you pay Cloudflare. If you self-host, you’re running a CMS with no plugin ecosystem, no security advantage over WordPress, and a brand new attack surface. That’s not a minor caveat—it’s a fundamental dependency.
Worse, even on Cloudflare’s free tier, plugins run in “in-process mode” without sandboxing. The headline feature requires a monthly subscription.
The Billing Risk Nobody Mentions
Capability manifests don’t control cost. Every plugin invocation is a Cloudflare Workers request. Every request hits multiple billing meters: Workers compute, D1 database reads, R2 storage operations, KV lookups. A DDoS attack or a runaway plugin can generate thousands of billable requests per second.
The source material from a critic points out: “If you use Cloudflare’s new CMS called M-Dash, you can wake up one morning to a bill of $13,000… there is nothing built into the platform to stop it.”
The capability manifest can limit what a plugin does, but it cannot limit how often a plugin fires. A plugin that sends email on every post publish could be abused by an attacker who publishes thousands of posts programmatically. The manifest says “email:send” is allowed—it doesn’t say “email:send up to 100 times per hour.”
Cloudflare offers CPU time limits per request and WAF rate limiting, but those are per-IP, not per-plugin. A distributed bot attack bypasses them. The advice to “just use manifests” ignores this operational risk entirely.
The Ecosystem Catch-22
WordPress has 60,000+ plugins. EmDash launched with zero. The capability manifest system is elegant, but it only matters if plugins exist to install. Building a plugin ecosystem from scratch takes years—even with AI-assisted porting.
The source material from a supporter acknowledges: “It’s a v0.1.0 beta with 38 GitHub stars, three contributors, and zero production deployments.”
The common advice to “switch to EmDash for security” assumes the plugin you need will be available. Right now, any non-trivial site (e-commerce, membership, forms, SEO) requires custom development. That development carries its own security risks—bugs in custom code, incomplete manifests, misconfigured permissions. The manifest system doesn’t prevent those; it only enforces what the developer declares.
When the System Works—and When It Doesn’t
EmDash’s capability manifest is genuinely superior for plugins with narrow, well-defined scopes. A contact form plugin that only reads content and sends email? The sandbox contains it perfectly. An SEO plugin that needs to read all content and write metadata? Still manageable—the manifest is auditable, and the runtime enforces the boundary.
But for plugins that require broad, multi-system access—backup, migration, caching, analytics—the manifest grants permissions so wide that the sandbox offers little practical protection. The attack surface shifts from “plugin can do anything” to “plugin can do many things, and we trust its manifest.”
The advice everyone gives—“use capability manifests to prevent plugin abuse”—is incomplete. It works for simple plugins. It fails for complex ones. It requires Cloudflare’s paid infrastructure. It ignores billing risk. And it assumes an ecosystem that doesn’t exist yet.
That’s not an argument against EmDash. It’s an argument for understanding the tool’s actual boundaries before betting a business on it.
- What does the EmDash capability manifest control?It requires every plugin to declare its capabilities in a structured manifest, enforced at the hardware level by V8 isolates.
- What is the main limitation of the capability manifest?It assumes the plugin developer declares capabilities honestly, and broad permissions for complex plugins offer little practical protection.
- Does self-hosted EmDash provide sandboxing?No. Self-hosted on a regular Node.js server, plugins run in-process with no isolation or capability enforcement.
