The most dangerous plugin in EmDash isn’t the one that secretly steals your data. It’s the one that asks for everything and gets approved. Cloudflare’s new CMS has a sandbox that physically blocks unauthorized access, but it cannot stop you from granting permission to a plugin that requests too many capabilities. That’s not a technical flaw. It’s a trust problem wearing a security badge.<\/p>\n
EmDash runs every plugin inside its own V8 isolate, a lightweight sandbox powered by Cloudflare’s dynamic workers. The plugin cannot touch your database, your file system, or any other part of the CMS unless you explicitly allow it.<\/p>\n
Each plugin declares its capabilities in a manifest. A contact form plugin might request But here’s the thing: EmDash does not limit how many capabilities a single plugin can request. A plugin could ask for The manifest is a simple JSON-like structure inside the plugin code. Here’s a real example from the EmDash documentation<\/a>:<\/p>\n “`javascript<\/p>\n definePlugin({<\/p>\n id: ‘my-plugin’,<\/p>\n version: ‘1.0.0’,<\/p>\n capabilities: [‘read:content’, ’email:send’],<\/p>\n hooks: {<\/p>\n ‘post:published’: async (context) => {<\/p>\n const email = context.getCapability(’email:send’);<\/p>\n \/\/ send email about new post<\/p>\n }<\/p>\n }<\/p>\n })<\/p>\n “`<\/p>\n The plugin cannot access anything outside those declared capabilities. It cannot read user passwords, cannot write to the database, cannot make HTTP requests to external servers. The dynamic worker enforces this at runtime.<\/p>\n But notice: nothing prevents the plugin from listing The WordPress ecosystem conditioned millions of users to install plugins without reading what they do. You click “Install Now” and the plugin gets full access to everything. EmDash breaks that pattern. You see a permission dialog before installation.<\/p>\n But will you actually read it? History says no. The same users who clicked “I agree” without reading terms of service will click “Approve” on a plugin that requests Cloudflare built a technically superior security model. They did not build a user education system. The architecture prevents a plugin from stealing<\/em> data it hasn’t been granted, but it cannot prevent you from giving<\/em> that data away.<\/p>\n A malicious plugin could request every available capability. If you approve, it has the same practical access as a WordPress plugin. The difference is that in WordPress, that access is implicit and unavoidable. In EmDash, it’s explicit and requires your consent.<\/p>\n This is not a flaw in the sandbox. It’s a feature of the permission model. The question is whether the average EmDash user will treat that permission dialog with the gravity it deserves.<\/p>\n Consider the economics. EmDash’s full sandbox requires Cloudflare’s paid plan at $5\/month. The target audience includes developers and small publishers\u2014people who understand technical trade-offs. But as EmDash grows, it will attract less technical users. That’s when the permission model becomes a vector, not a shield.<\/p>\n If a plugin tries to execute code outside its declared capabilities, the runtime throws an error. The plugin fails. Your site continues running. No data is exposed, no files are deleted, no emails are sent to attackers.<\/p>\n But if a plugin declares This mirrors the App Store model on iOS. Apple can’t stop you from granting location access to a flashlight app. They can only force the app to ask first.<\/p>\n WordPress has 60,000+ plugins. EmDash launched with zero. To build an ecosystem, you need to attract developers. Developers want to monetize. The GPL license in WordPress forces many developers into restrictive licensing. EmDash uses MIT, which allows closed-source plugins.<\/p>\n But closed-source plugins in a sandboxed environment are hard to audit. You cannot inspect the source code to verify it only does what it claims. The permission manifest becomes your only defense. If a plugin requests Cloudflare’s solution to this is the 402 payment protocol and the MCP server for AI agents<\/a>. The idea is that AI can generate plugins on demand, reducing reliance on a marketplace. But AI-generated code is even harder to audit for permission abuse.<\/p>\n The sandbox only works on Cloudflare’s runtime. If you self-host EmDash on a Node.js server, plugins run in-process without isolation. The permission model collapses. You get no protection at all.<\/p>\n This is the same lock-in critics have pointed out. The feature that makes EmDash genuinely superior to WordPress requires you to stay inside Cloudflare’s infrastructure. Open source code, proprietary runtime.<\/p>\n The counterintuitive truth: EmDash’s security is strongest when you<\/a> trust Cloudflare and weakest when you trust yourself. The plugin permission system is a marvel of modern isolation, but it cannot protect you from your own approval.<\/p>\nread content<\/code>codecodecodecode and send email<\/code>codecodecodecode. That’s it. The runtime enforces the boundary at the hardware level using Linux namespaces, seccomp filters, and memory protection keys.<\/p>\nread content<\/code>codecodecodecode, write content<\/code>codecodecodecode, delete content<\/code>codecodecodecode, read users<\/code>codecodecodecode, write users<\/code>codecodecodecode, send email<\/code>codecodecodecode, make external network requests<\/code>codecodecodecode, and manage settings<\/code>codecodecodecode. The system will happily let it declare all of those. The question is whether you, the site owner, will approve them.<\/p>\nThe Manifest System: What Plugins Can and Cannot Declare<\/h2>\n
read:users<\/code>codecodecodecode, write:content<\/code>codecodecodecode, network:all<\/code>codecodecodecode, and admin:settings<\/code>codecodecodecode. The system does not have a “max permissions” cap. It trusts you to evaluate each request.<\/p>\nThe Real “Flaw”: User Trust vs. Technical Enforcement<\/h2>\n
delete:all<\/code>codecodecodecode because they just want the feature to work right now.<\/p>\nCould a Plugin Request All Permissions? Yes. So What?<\/h2>\n
What Happens When a Plugin Oversteps? Nothing\u2014Unless You Deny It<\/h2>\n
network:all<\/code>codecodecodecode and you approve it, then it can exfiltrate your content to any server. The sandbox did its job by showing you the request. The failure was yours.<\/p>\nThe Harder Problem: Plugin Ecosystems Without Trust Infrastructure<\/h2>\n
network:all<\/code>codecodecodecode, you have to trust the developer’s intent.<\/p>\nWhere This Architecture Breaks Down<\/h2>\n
The Future: Permission Fatigue and the AI Agent Problem<\/h2>\n