Every plugin you install gets the keys to everything.
Your database. Your files. Your network. A contact form plugin can read your user passwords. A carousel plugin can phone home to a server you’ve never heard of. There are no sandboxes. No permission boundaries. No guardrails.
Last week Cloudflare said this out loud. They launched EmDash — a new CMS they’re calling the “spiritual successor to WordPress” — built from the ground up to fix plugin security.
Their diagnosis is correct. Their solution is to burn the house down.
You don’t fix a neighborhood by building a new city
EmDash runs plugins in V8 isolates. Each one gets its own sandboxed environment with zero capabilities by default. A plugin has to declare what it needs — database access, outbound HTTP, email. If it doesn’t declare it, it can’t do it. The enforcement happens at the runtime level, not in application code.
That’s genuinely elegant engineering.
It also has zero plugins. Zero themes. Zero ecosystem. Against WordPress’s 70,000+ plugins, two decades of documentation, and 43% of the web.
EmDash is open source, MIT-licensed, and was built with AI in about two months. It’s v0.1.0 preview software. And while the code runs anywhere Node.js does, the architecture maps tightly to Cloudflare’s own infrastructure — Workers, D1, R2. The economic gravity is obvious.
You know what else you can build with AI in a couple months? A solution that works with the WordPress you already have. Without asking 810 million websites to start over.
The real problem isn’t PHP. It’s visibility.
Cloudflare frames this as an architecture problem. PHP can’t sandbox plugins, therefore you need a new runtime.
Here’s another way to look at it.
The problem isn’t that plugins have full access. The problem is that nobody is watching what they do with it.
You install 30 plugins. Each one can query any database table, call any URL, register any hook, modify any file. Right now, on your production site — do you know which plugins are making outbound HTTP requests? Which ones write to your users table? Which ones registered a callback on wp_login?
You don’t. Nobody does.
You don’t need a new runtime. You need a bouncer.
So I built one
Bouncer is a plugin behavior firewall for WordPress. It generates a capability manifest for every plugin — what it touches, what it calls, what it hooks, what it writes. Then it monitors against those manifests at runtime.
EmDash prevents misbehavior by architecture. Bouncer detects it by intelligence.
One requires leaving WordPress. The other protects the WordPress you already have.
It watches four channels. A gallery plugin writing to wp_users gets flagged — that’s not in its manifest. A slider plugin calling an outbound domain that didn’t exist in the last version gets flagged. A caching plugin registering on wp_login at priority zero gets flagged. A plugin file modified outside the update process triggers an emergency.
And when you install something new, AI reads its code structure before activation. Not pattern matching. Not signature scanning. Structural analysis — what does this plugin actually do, is that normal for its type, and what changed since the last version.
“But you can’t truly sandbox PHP”
I know. I’m not trying to.
You can’t give Plugin A different permissions than Plugin B inside the same PHP process. That’s a hard constraint. Cloudflare is correct about that.
But the idea that anything less than perfect isolation is worthless? That’s wrong.
According to Patchstack, 11,334 new WordPress plugin vulnerabilities were disclosed in 2025. The vast majority — XSS, broken access control, CSRF, SQL injection — are detectable behaviors. They show up as anomalous database queries, unexpected outbound calls, and unauthorized hook registrations. The exact things Bouncer monitors.
Supply chain attacks are the fastest-growing category. A trusted plugin gets poisoned through a compromised developer account. There’s no CVE yet. No malware signature. No WAF rule. The plugin just quietly starts behaving differently.
That’s not a PHP architecture problem. That’s a detection problem. And detection is solvable.
Perfect is the enemy of shipped. EmDash is perfect architecture with zero ecosystem. Bouncer is imperfect detection with the entire WordPress ecosystem.
WordPress doesn’t need a funeral. It needs a firewall.
The conversation Cloudflare started matters. Plugin security IS broken. The community has been treating it as a known-vulnerability-matching problem for too long — scan for known signatures, match against CVE databases, filter at the network edge.
All of those tools ask: “Is this a known threat?”
Bouncer asks: “Is this plugin doing something it shouldn’t?”
Different question. Different layer. And one that WordPress has needed for a long time.
I’m not saying Bouncer is the only answer. Something else could solve this too. The WordPress Plugin Check already runs automated security scans on submissions — but that’s pre-deployment static analysis, not runtime monitoring. The vulnerability databases are mature. The community is massive. The infrastructure exists. What’s been missing is the ability to watch what plugins actually do, live, on every request.
That’s a tooling gap. Not a reason to abandon the ecosystem.
Cloudflare spent two months building a CMS to solve a plugin problem. I spent less time building a plugin to solve the same problem.
We don’t need to leave WordPress to fix WordPress.
Bouncer is open source, GPL-licensed, and works on the WordPress you already have.