If you've ever installed a WordPress plugin and just... trusted it, you're not alone. Most people do. The plugin gets activated, the feature works, and you move on. What almost nobody thinks about is what that plugin can do behind the scenes. Architecturally, the answer is pretty much unlimited access.
That's the problem EmDash was built to fix.
The WordPress Plugin Problem Isn't About Bad Developers
Most WordPress plugin developers aren't malicious or careless. The problem is architectural, not a matter of developer intent.
When a plugin is activated on a WordPress site, it runs inside the same PHP environment as everything else. The core files, the database, the admin panel, other plugins — a newly installed plugin sits right alongside all of it, with no wall between them. It can read your database. Write to your filesystem. Make outbound network requests. Inject code into your admin dashboard. Hook into nearly any part of WordPress's execution.
This isn't a bug. It's how WordPress was designed, back in 2003, before modern cloud security thinking existed. The hooks-and-filters system that makes WordPress so extensible is the same system that makes it so risky.
According to Cyber Security Magazine, 96% of WordPress vulnerabilities come from plugins. A 2025 analysis cited by Lushbinary found over 11,300 new WordPress vulnerabilities that year, 91% originating from plugins. And when one plugin is compromised, the damage covers the entire site. One bad actor gets the keys to the kingdom.
You can't fully vet a plugin just by reading reviews. A plugin with 500,000 installs and a five-star rating can still be sold to a shady buyer and updated with malware overnight. The trust model is reputational, not technical.
What EmDash Does Differently
EmDash, Cloudflare's open-source CMS launched in April 2026, was built from scratch, and the design choices reflect two decades of hard lessons about web security. The approach isn't just "more security checks." It's a different relationship between the CMS and its plugins. Plugins don't get access to anything by default. They have to ask for it. Explicitly. In advance.
Sandboxed Worker Isolates
In WordPress, every plugin runs in the same process. In EmDash, each plugin runs in its own isolated environment called a Worker isolate, a sandboxed execution context built on Cloudflare Workers technology.
Think of it like this: WordPress plugins share an apartment building with no locks on the doors. EmDash plugins each get their own locked room, in a separate building, connected only through a strict reception desk that checks IDs.
A compromised EmDash plugin cannot touch another plugin's data. It cannot access the database directly. It cannot read files it wasn't explicitly granted access to. If something goes wrong, whether through a security flaw in the plugin code or a malicious update, the damage is contained to that isolate.
This design eliminates whole categories of attacks that are common in WordPress:
- SQL injection. Without direct database access, there's nothing to exploit.
- File system traversal. Plugins can't touch files outside their declared permissions.
- Admin UI hijacking. EmDash's admin interface is defined via a strict JSON schema. Plugins have no path to inject arbitrary HTML or JavaScript into it, and the schema enforcement makes this a hard technical constraint, not just a policy.
- Cross-plugin contamination. A compromised plugin can't read another plugin's data or credentials.
Capability Manifests
Every EmDash plugin ships with a capability manifest, a file that declares exactly what the plugin needs access to.
It works similarly to how smartphone apps request permissions. When you install an app, it asks: "Can I access your camera? Your location? Your contacts?" You can see what it's asking for and make an informed decision. If a flashlight app wants access to your contacts, that's a red flag.
A plugin that adds comments might declare it needs access to content.read and content.write. A plugin that sends newsletters might declare it needs network.outbound to an email service endpoint. Nothing beyond what's declared is accessible, and those declarations are visible to site owners before installation.
Site owners can see what a plugin actually touches before they install it. That's a different kind of trust than reading five-star reviews.
The EmDash plugin marketplace also runs automated security scanning (powered by Workers AI and Llama Guards) on submissions, adding another layer before plugins even reach users.
What This Looks Like in Practice
Say you're running an EmDash blog and you install a plugin that adds social sharing buttons. Here's what happens in each system:
In WordPress: The plugin hooks into wp_footer, wp_head, and potentially admin_init. It can query your database, read your user table, and make external HTTP calls without asking permission. A compromised update can quietly harvest your users' data.
In EmDash: The plugin declares in its manifest that it needs content.read (to know what page is being viewed) and network.outbound to the social platform APIs. That's all it gets. A compromised update that tries to access the database or read user credentials simply fails. The sandbox doesn't allow it.
This doesn't make EmDash plugins bug-free. A plugin can still have broken logic, display errors, or behave unexpectedly. The sandbox limits how far the damage can spread, not all possible failure modes.
The Honest Trade-Offs
WordPress has over 60,000 plugins. EmDash launched two months ago and has a fraction of that. For many common features — WooCommerce-style e-commerce, specific CRM integrations, advanced SEO tooling — you may find gaps. The ecosystem will grow, but right now there's no pretending it's comparable.
The capability manifest system is more deliberate than WordPress's freeform PHP approach. For developers porting existing plugins, there's real work involved in mapping WordPress hooks to EmDash equivalents and declaring permissions explicitly. That friction is intentional — it's how the security model works — but it does slow down the pace of plugin development.
The sandboxing also relies on Cloudflare Workers, and that dependency is real. You can deploy EmDash on other infrastructure (Node.js alternatives exist), but you give up some native performance and tooling support that comes with running on Cloudflare's edge.
And EmDash is early. The security model is sound by design, but real-world hardening happens against real attack surface. WordPress's security team has 20+ years of patching experience. That institutional knowledge doesn't exist yet for EmDash.
The ecosystem gap is the real constraint. The security architecture holds up; whether enough plugins exist for your use case is the question you have to answer before committing.
Who Should Care About This Right Now?
If you run a simple personal blog and you've never had a security incident, the WordPress plugin problem may not have bitten you yet, but statistically it will. The Hacker News discussion around EmDash's launch is full of developers sharing stories of sites compromised through abandoned or purchased plugins.
If you're building something new — a publication, a business site, a community platform — EmDash's security architecture is a genuine reason to start there rather than migrate later. The time to think about plugin security is before you have 50,000 users, not after.
For existing WordPress sites, migration is real work and the ecosystem gap is still real. That calculus changes as the plugin library grows.
The underlying security problem that EmDash solves is real. Sandboxed isolates and capability manifests aren't marketing language. They're the reason a compromised plugin can't reach your database — which is something WordPress's architecture has never been able to guarantee, because fixing it would mean breaking the very model that made WordPress popular.
Fixing that would mean breaking the extensibility model that made WordPress popular, so EmDash chose to rebuild rather than retrofit. Whether that bet pays off depends on whether the ecosystem catches up to the architecture.
Have questions about EmDash or want help setting it up? Reach out. We're happy to dig into the specifics.