The Security Case: Why We Stopped Patching Plugins

If you run a WordPress site with more than a handful of plugins, you are not running a website. You are running a supply chain you don't control, executed on a runtime you didn't choose, wrapped around a core you can't audit.

The plugin treadmill

The average WordPress install we audit has 30–50 active plugins. Each one is an attack surface, a performance tax, and an upgrade constraint at the same time. The security math is brutal: your posture is roughly the posture of your least-maintained plugin.

We lived this. Two of our plugins carried known XSS advisories for months before we noticed, because nobody's job was to notice.

Access control you can review

Payload flips the model. There is no plugin marketplace; the things plugins used to do live in your codebase, where they belong:

access: {
  read: () => true,
  update: ({ req }) => req.user?.role === 'editor',
  delete: ({ req }) => req.user?.role === 'admin',
}

That is the entire authorization model for a collection — typed, versioned, and reviewable in a pull request. Compare that with capability juggling across plugins, options pages, and database-stored role definitions.

What actually changes

• No PHP surface area — the CMS runs on the same runtime as your app
• One dependency tree, and it's yours
• Admin authentication, sessions, and CSRF handled by the platform, not by a plugin published in 2013
• Security updates arrive through the channel you already trust: package updates

None of this makes a site immune to vulnerabilities. But it moves your security model from "trust strangers, patch constantly" to "read your own code, review changes like an engineer" — which is the only posture we've ever been able to defend to a CTO.