Last year, a popular WordPress form plugin with over 900,000 active installations was found to contain a critical vulnerability that allowed unauthenticated attackers to upload arbitrary files to any affected site. The patch was released within 48 hours. But weeks later, security researchers were still finding sites that hadn’t updated — and those sites were actively being exploited.
900,000 installations. Weeks of exposure. All because of a plugin that most users had installed and forgotten about.
This is not a rare scenario. It is the most common way WordPress sites get compromised.
How Plugin Vulnerabilities Actually Work
A WordPress plugin is code that runs on your server with full access to your database and filesystem. When a plugin has a vulnerability, an attacker doesn’t need your password. They don’t need to trick you into clicking a link. They just need to find your site running the vulnerable plugin version — which automated scanners do constantly, at scale — and send a specially crafted request.
The most common vulnerability types:
SQL injection. The plugin builds a database query using user-supplied input without properly sanitising it. An attacker manipulates that input to extract your entire user table, including email addresses and password hashes. On WooCommerce stores, that means customer names, addresses, and order history.
File upload vulnerabilities. A plugin that accepts file uploads — contact forms, product galleries, document managers — may not properly validate what’s being uploaded. An attacker uploads a PHP file disguised as an image. Once it’s on your server, they visit its URL and have direct code execution: they can read any file, write any file, or establish a persistent backdoor.
Cross-site scripting (XSS). The plugin renders user input on the page without escaping it. An attacker injects JavaScript that runs in your admin’s browser the next time they visit the dashboard. That script can steal session cookies, add a new administrator account, or install malware — all without ever touching your login page.
Broken access controls. The plugin registers a REST API endpoint or an admin-ajax action but forgets to check whether the requester is actually authorised. Any visitor can call that endpoint and perform actions that should be restricted to administrators.
What makes this particularly dangerous is that the vulnerability is in the plugin code — not in your configuration, not in your password, not in anything you did wrong. The site is vulnerable the moment the plugin is installed, and the moment the vulnerability becomes publicly known, the clock starts ticking.
The Lifecycle of a Plugin-Based Breach
Understanding the timeline helps explain why “I’ll update it next week” is such a high-risk position.
Discovery. A security researcher or, less fortunately, a malicious actor finds a vulnerability in a plugin. If it’s a responsible researcher, they report it to the plugin author privately.
Patch release. The plugin author releases an update fixing the vulnerability. This is the moment the clock starts publicly. The patch can be reverse-engineered to understand exactly what was changed and why, giving attackers a precise recipe for exploiting unpatched versions.
Public disclosure. The vulnerability is published on databases like WPScan, CVE, or Wordfence’s threat intelligence feed. Automated scanners immediately begin probing sites for the vulnerable version.
Mass exploitation. Within hours to days of public disclosure, the vulnerability is being exploited at scale. Botnets scan millions of sites looking for the vulnerable plugin version. This is not targeted — your site is not special. It’s simply in the list of sites running old software.
Compromise. Sites that haven’t updated get backdoors installed, malware injected, data extracted, or spam infrastructure established. Often the site owner doesn’t know for weeks. The malware is designed to be invisible — it doesn’t want to be found until it has done its work.
The gap that matters is between patch release and when you update. For most unmanaged sites, that gap is weeks to months. For some, it’s never — we regularly find client sites running plugins with known vulnerabilities from two years ago.
What the Numbers Look Like
Sucuri’s annual hacked website report consistently shows that outdated software — primarily plugins — is the leading cause of WordPress compromises, accounting for over 60% of infections they investigate.
WPScan’s vulnerability database lists thousands of known WordPress plugin vulnerabilities. In any given year, several hundred new ones are added. The plugins involved are not obscure ones nobody uses — they include widely-installed tools for contact forms, SEO, page builders, sliders, backups, and WooCommerce extensions.
For e-commerce sites specifically, the stakes are higher. A breached WooCommerce store doesn’t just leak data — it creates regulatory exposure. Under GDPR, a personal data breach must be reported to the relevant supervisory authority within 72 hours of discovery. The fine for failure to notify can reach €10 million or 2% of global annual turnover, whichever is higher. Customer trust, once lost through a breach notification, is difficult to recover.
The Warning Signs Most Site Owners Miss
By the time a site is obviously compromised — search results showing spam links, browser warnings, hosting account suspended — the breach has usually been ongoing for some time. The early signs are subtler:
Unexplained admin accounts. Log into your WordPress dashboard and check Users → All Users. If you see administrator accounts you don’t recognise, your site has almost certainly been compromised. Attackers create these to maintain persistent access even after the initial vulnerability is patched.
Modified core files. WordPress core files — the files in /wp-admin/ and /wp-includes/ — should never change between updates. If a file scanner or your hosting control panel shows recent modifications to these files, that’s a red flag.
Outbound requests to unknown domains. Check your server’s access logs for POST requests going out to domains you don’t recognise. Malware frequently phones home to command-and-control servers.
Injected content in the database. Malicious JavaScript or redirects are often stored in the database rather than in files, making them harder to detect with file scanning. Search your wp_options table for <script> tags or suspicious URLs that don’t belong there.
Sudden traffic changes. A spike in traffic from unusual geographies, or a sudden drop in organic search traffic (Google deindexing spam-injected pages), can indicate a compromise.
These signs appear before the obvious damage. Catching them requires either monitoring tools or regular manual checks — neither of which happens automatically.
What Regular Maintenance Actually Prevents
The businesses we work with on ongoing maintenance plans don’t experience these breaches. Not because the vulnerabilities don’t exist — they do, regularly — but because the window of exposure is measured in hours rather than months.
Here’s what a proper maintenance workflow looks like in practice:
Monitoring for vulnerabilities. We track security advisories for every plugin installed on every site we manage. When a vulnerability is disclosed for a plugin on a client’s site, we know about it immediately — not when we happen to log into the dashboard.
Tested updates within 24-48 hours. Critical security updates go out within a day of release, after a basic compatibility check on a staging copy. This closes the exploitation window before automated scanners have had time to target the site at scale.
Regular plugin audits. Beyond updates, we periodically review the full plugin list: what’s active, what’s inactive, what’s abandoned (no updates in 12+ months), and what’s redundant. Inactive plugins are deleted, not just deactivated — an inactive plugin with a file upload vulnerability is still exploitable.
File integrity monitoring. Automated checks compare current file hashes against known-good baselines. Any unexpected file modification triggers an alert, catching infections before they spread.
Database monitoring. We scan the database for injected content on a regular schedule. If malicious scripts appear in wp_options or post content, they’re caught before they run on your visitors’ browsers.
The cost of this ongoing attention is a fraction of what post-breach recovery costs — in money, in time, and in the customer trust you spend years building.
The Abandoned Plugin Problem
One vulnerability category deserves special attention: plugins that are no longer maintained.
WordPress.org removes plugins from its directory when they’re found to have unresolved vulnerabilities. But removal from the directory doesn’t remove them from the millions of sites that already installed them. A plugin that was removed from the directory three years ago might still be running on your site — still actively exploitable — with no update mechanism remaining.
Plugins become abandoned for various reasons: the developer moved on, the business model didn’t work, the plugin was superseded. Whatever the reason, an abandoned plugin is a fixed target. Its vulnerabilities are known and they will never be patched.
The only safe approach to abandoned plugins is removal. Find alternative functionality elsewhere, or accept the loss of that feature. Keeping an abandoned plugin active because you rely on one thing it does is trading a known, permanent security risk for a minor convenience.
A Practical Starting Point
If you’re not on a maintenance plan and want to understand your current exposure:
-
Update everything now. Log in, go to Dashboard → Updates, and apply every available update. This alone closes most known vulnerabilities.
-
Audit your plugin list. Under Plugins → Installed Plugins, look at everything that’s installed. Delete anything you don’t use. For plugins that haven’t been updated in over a year, search for them on WPScan’s database to check for known vulnerabilities.
-
Check your user list. Users → All Users. Remove any accounts you don’t recognise, particularly administrators and editors.
-
Install a file integrity monitor. Wordfence’s free version includes file scanning. Run a scan now to check for existing infections.
-
Set up automatic updates for minor releases. WordPress can automatically apply minor security updates. Enable this at minimum — it handles the most critical patches without requiring manual action.
These steps take an hour. They won’t give you ongoing protection — they’re a one-time snapshot — but they’ll close the most obvious gaps right now.
For ongoing protection, the honest answer is that manual maintenance doesn’t scale. Most site owners don’t check for updates daily, don’t monitor security advisories, and don’t have a staging environment to test updates before applying them. That’s not a criticism — it’s just not what they’re there to do. Which is exactly why ongoing maintenance plans exist. See our WordPress Security Checklist for a complete overview of what a hardened site looks like.