layerone.digital
Layer One Digital

Every WordPress plugin is a door you have to keep locked

Most WordPress breaches don't come through the core; they come through a plugin nobody updated. Why your attack surface grows with every plugin you install.

WordPress Security

WordPress core is not the thing that gets you breached. It’s reasonably well maintained and patched quickly. The thing that gets you breached is the twenty-something plugins bolted around it: each one written by a different author, on a different schedule, with a different idea of how careful to be.

Every plugin you install is another door into your site. And every door is one you now have to keep locked, forever.

The attack surface is the plugin list

Year after year, the overwhelming majority of WordPress vulnerabilities trace back to plugins and themes, not core. That’s not a coincidence; it’s arithmetic:

  • More plugins means more third-party code executing with access to your site and database.
  • Each plugin updates on its own cadence, so “fully patched” is a moving target you never quite hit.
  • Plugins get abandoned. The author moves on, the code stops getting fixes, and you’re running unmaintained software with a login form.

You didn’t choose to run twenty codebases from twenty vendors. You chose twenty features, and the codebases came attached.

Patching is a treadmill, not a finish line

The standard advice, “just keep everything updated,” describes a treadmill, not a solution. Updating is itself risky (see: plugin conflicts), so teams delay it, which is exactly the window attackers count on. You end up choosing between two bad options every week:

  1. Update immediately and risk something breaking.
  2. Delay and run known-vulnerable code in the meantime.

Neither is a good place to run a business-critical site from. And the more plugins you have, the more often you’re forced to choose.

Fewer moving parts, fewer doors

The most reliable way to reduce an attack surface is to not have one. A static, pre-rendered site changes the maths entirely:

  • There’s no live plugin stack executing on each request, so there’s no plugin vulnerability to exploit at request time.
  • There’s no database exposed to the public internet waiting for an injection.
  • With almost no server-side surface, entire categories of attack simply don’t apply.

That’s the security posture we build in a Replatform & Performance Rescue: not a hardened version of a fragile stack, but an architecture where there’s very little to attack in the first place.

If your security model is “hope every plugin author is careful,” request a fit check: we’ll show you what near-zero attack surface looks like.

Back to blog