--- title: "WordPress's Real Problem Is That Plugins Run in the Same Process" slug: "wordpress-plugin-sandbox" language: "en" date: "2026-10-27T22:55:27.287Z" updated: "2026-10-27T22:55:27.000Z" description: "11,334 vulnerabilities in the WordPress ecosystem last year, 91% in plugins, 46% unfixed. The root cause is architectural, not a plugin quality problem." canonical: "https://fix.slopit.io/wordpress-plugin-sandbox/" tags: ["wordpress", "security", "cms", "software"] --- Ajay Chavda has built more than 1,500 commercial sites, most on WordPress, and he has stopped recommending it. His essay is a product launch — he built Hatamoto, a Go-based CMS, and the piece ends with a signup form — but the diagnosis is unusually well evidenced, and it's worth separating from the sales pitch. The number that should worry anyone running WordPress isn't the plugin count. It's this: Patchstack recorded 11,334 new vulnerabilities in the WordPress ecosystem in 2025, 42% more than the year before. 91% were in plugins, 9% in themes, six in core. 46% had no fix from the developer when they became public. For the most attacked, the median time from disclosure to mass exploitation was five hours. Sucuri found that 95.5% of the infected sites it cleaned in 2023 ran WordPress. Some of that is market share. All of it lands on the agency owner taking the call. ## The structural problem Chavda's central claim is not that plugins are bad. It's that WordPress has no sandbox at all. Every plugin runs in the same PHP process as core, with the same access to the database and files. A slider plugin can read the users table. A form plugin can send data anywhere. There is no permission prompt, and no way to limit what a plugin touches. That is the root cause, and it explains why the ecosystem's security statistics look the way they do. It also explains why the standard advice doesn't scale: turn off auto-updates, stage every change, pin versions, pay for maintenance, add a security plugin to watch the other plugins. Each of those is a band-aid, and Chavda's description of the resulting stack is the most damning paragraph in the piece — a caching plugin to fix speed, a security plugin to protect the plugins, a staging setup to make updates safe, a backup service in case staging misses something. A fragile platform doesn't get sturdier when you add more layers. The update problem follows from the same architecture. WordPress restores core if its own auto-update fails, and since 6.6 it reverses a plugin auto-update that throws a fatal error. But it can't see a theme that wrecks the layout, a form that stops sending, or a checkout that loads but won't take payment. So agencies either babysit updates or fall behind, and Sucuri found 39.1% of cleaned installs were out of date when infected. ## The governance problem is real too The essay also documents the 2024 WP Engine fight: WordPress.org banning a host, taking over its ACF plugin, contributors asked to confirm they weren't affiliated with WP Engine, and a court later ordering access restored. Then Automattic cut its pledged contribution from nearly 4,000 hours a week to 16, WordPress moved to one major release a year, and the backlog sits around 13,000 tickets. You don't have to take a side in that dispute to see the structural issue: a large share of the web runs on a platform where one person controls the .org infrastructure, the plugin directory, and the direction of the project. That's a concentration risk independent of anyone's intentions. ## Where I'd push back The prescription deserves the same scrutiny as the diagnosis. A single Go binary with Postgres is simpler for a developer and harder for the average agency. WordPress's actual moat is not its code; it's the fact that a non-technical client can log in, install a plugin, and find a freelancer who knows the stack in any city. Hatamoto's WebAssembly sandbox and signed registry are better engineering, but they also mean a smaller catalogue, a younger project, and a migration path that has to deal with the ugliest part of WordPress: full URLs baked into serialised PHP data. "No company owns it" is a promise about a licence, not a guarantee about a community. Apache-2.0 means you can fork it; it doesn't mean anyone will. And the migration cost is real. Chavda's own export/import commands sound clean, but moving 1,500 agency sites is a different project from moving one. ## What's worth taking regardless Three ideas in the essay are right independently of which CMS you pick. **Sandbox plugins and make permissions explicit.** Running third-party code with full database access, in 2026, is indefensible. The fact that it's normal doesn't make it defensible. **Updates should be reversible by default.** The phone analogy is the correct bar: install the new version next to the old one, check that the site still works, roll back automatically if it doesn't. WordPress's fatal-error rollback is a narrow special case of a general requirement. **Machine readability belongs in the model, not a plugin.** If AI systems are going to read and write the site, schema, sitemaps and access control should come from the content model, not from four plugins that disagree. The pitch is a pitch. But the numbers behind it — 11,334 vulnerabilities, 46% unfixed, five hours to exploitation — are the argument for sandboxing, and they'd be true even if Hatamoto didn't exist. The interesting question is whether a better architecture can attract an ecosystem before the old one's debt comes due. *Source: [I've used WordPress for 20 years, and I've stopped recommending it — Ajay Chavda, Hatamoto](https://hatamoto.dev/post/wordpress-20-years-why-we-built-hatamoto).*