Why an outdated plugin is still the #1 way small business sites get hacked

Ask most people to picture a website getting hacked, and they picture a hooded figure typing furiously, hunting for some clever, custom exploit. In practice, the overwhelming majority of small business site compromises look nothing like that. They look like this: a plugin or library has a publicly disclosed vulnerability, a fix has existed for months, nobody applied it, and an automated tool found the gap before anyone else did.

The CVE system, briefly

When a security researcher finds a vulnerability in a piece of software, it usually gets assigned a CVE (Common Vulnerabilities and Exposures) identifier and published in a public database, alongside a severity score and — often — proof-of-concept exploit code. This process exists so defenders can track and patch known issues. The side effect is that the moment a CVE is published, it’s also a public, searchable “here’s exactly what to look for” list for attackers.

This is why patch speed matters more than almost anything else in practical security. The vulnerability isn’t secret. The only question is whether you close it before or after it gets scanned for.

It’s rarely targeted — that’s what makes it worse

Most of this activity isn’t a human deciding to attack your specific business. It’s automated scanning infrastructure that continuously crawls the internet looking for sites running a known-vulnerable version of some widely used plugin, theme, or library — completely indifferent to who you are or how much revenue you do. Being “too small to be a target” doesn’t apply, because nobody picked you. A scanner found you.

Why this is harder than “just update regularly”

In theory, patching immediately solves this. In practice:

• Updates can break things. A plugin update might conflict with your theme or another plugin, so updates get delayed “until someone has time to test it” — and that delay is exactly the exposure window.
• Nobody’s tracking what’s actually installed. Sites built over years accumulate plugins nobody remembers installing, some of which are abandoned by their original developer and will never get a fix.
• Severity isn’t obvious from the outside. Not every update note says “this patches a critical authentication bypass” — sometimes it’s buried in a changelog line that looks routine.

What actually closes the gap

• A real inventory. You can’t patch what you don’t know is installed. Every plugin, theme, and library should be listed somewhere, not just implicitly known by whoever set the site up originally.
• Scanning that checks against CVE databases specifically, not just “is there an update available” — version numbers alone don’t tell you if a specific known vulnerability applies.
• A patch SLA, not a patch habit. “We’ll get to it eventually” and “critical findings get fixed within 48 hours” produce very different outcomes over a year.
• A staging step for anything higher-risk, so “the update might break something” stops being a reason to skip it.

The uncomfortable truth is that this is one of the most preventable categories of breach that still happens constantly — not because it’s hard to fix, but because it’s boring to stay on top of.