How do WordPress sites get hacked through plugins?

Most compromises exploit a known vulnerability in an outdated plugin or theme — one that already has a public CVE and a patched version available. The site isn't targeted for being interesting; it's targeted for running a version an automated scanner recognizes as exploitable.

How can an agency track plugin vulnerabilities across many sites?

Check installed plugin and theme versions against a vulnerability database across the whole fleet, so a newly disclosed CVE surfaces every affected site at once — instead of finding out site by site, or after a compromise.

Is scanning for vulnerabilities enough?

Scanning tells you where the risk is; it doesn't fix it. Pair it with a governed way to roll out the patch — checked, reversible on the plugin path, and logged — so knowing about the vulnerability actually leads to closing it safely.

← Back to blog

The Vulnerable Plugin You Didn't Know You Were Running

How a known plugin vulnerability sits quietly on a client site until someone finds it — and why fleet-wide vulnerability visibility is the cheapest incident you'll never have.

Ben KalskyCo-founder & Engineering, Digitizer · July 11, 2026 · 2 min read

WordPressSecurityAgency OpsIncidentsSiteAgent

The uncomfortable truth about most WordPress compromises: the door was already unlocked, publicly, with a sign on it. A plugin shipped a security fix. The CVE went public. The patched version went out. And on one of your client sites, that plugin stayed three versions behind — until an automated scanner found it.

This is an illustration, not a specific customer. It's the shape of the incident that hits agencies who can see updates but not risk.

The window between disclosure and patch

A vulnerability isn't dangerous the day it's written. It's dangerous the day it's disclosed — because disclosure is also when the scanners get the signature. From that moment, every site running the vulnerable version is on a list, and the only thing standing between the list and the incident is how fast you patch.

For one site, you'd probably see the security notice and act. Across fifty client sites with different plugin sets, the notice for the one plugin that matters is buried in fifty dashboards you don't check daily.

Where it bends: see the risk, not just the version

The fix isn't heroics — it's visibility aimed at the right thing:

Check versions against a vulnerability database, fleet-wide. SiteAgent's check_vulnerabilities tool compares installed plugins and themes against the WordPress.org vulnerability data, so a newly disclosed CVE surfaces every affected site at once.
Score the broader posture. scan_security reports the ordinary exposure — file-edit lockdown, debug output, SSL, default admin, open registration, PHP version — so you're not just patching one hole while three others stay open.
Then close it, governed. Knowing isn't fixing. Roll the patch out through a health-checked plugin batch that reverts automatically if it breaks, and log who approved it.

The honest boundaries

These scans read — they tell you where the risk is; they don't patch on their own. Closing the gap is a separate, governed update.
Automatic rollback covers the plugin batch path. Core and theme patches run governed but without that automatic revert, so keep a recent backup.
A scan is a point-in-time read. New CVEs land constantly; the value is checking regularly, not once.

The cheapest incident is the one you patched first

You can't out-heroics a compromise at 2am. You can make the vulnerable version visible the day it's disclosed, and close it before it's found. That's the whole game.

Aura's SiteAgent plugin is free and open source; connecting your first site — to see its health, versions, and security posture — takes a minute. The governed patch-and-rollback flow runs on a paid plan. See pricing or read the update-risk teardown.

Frequently asked questions

How do WordPress sites get hacked through plugins?: Most compromises exploit a known vulnerability in an outdated plugin or theme — one that already has a public CVE and a patched version available. The site isn't targeted for being interesting; it's targeted for running a version an automated scanner recognizes as exploitable.
How can an agency track plugin vulnerabilities across many sites?: Check installed plugin and theme versions against a vulnerability database across the whole fleet, so a newly disclosed CVE surfaces every affected site at once — instead of finding out site by site, or after a compromise.
Is scanning for vulnerabilities enough?: Scanning tells you where the risk is; it doesn't fix it. Pair it with a governed way to roll out the patch — checked, reversible on the plugin path, and logged — so knowing about the vulnerability actually leads to closing it safely.

← Back to all posts