Plugins are the single largest attack surface on any WordPress site you manage. They come from thousands of different developers, at wildly different skill levels, and every one you install is code you are trusting on a client’s site. That trust is exactly what attackers go after.
For years the advice was simple: keep everything updated and you are fine. That advice is now broken, and if you manage client sites, the gap it leaves is yours to cover.
Here is what is actually happening with plugin vulnerabilities, and what genuinely protects your clients.
Key Takeaways
- Plugins, not WordPress core, are where nearly every vulnerability lives: 91% of new WordPress vulnerabilities in 2025 turned up in plugins.
- Updating fast no longer keeps sites safe, because attackers now weaponize the most-targeted vulnerabilities in a median of five hours.
- Almost half of vulnerabilities have no fix available when they go public, so there is often no update to apply at all.
- Paying more does not buy better code. When vulnerabilities show up in premium plugins, 76% of them are exploitable in real attacks, and premium code gets less independent scrutiny than free code, not more.
- Reliable protection works in layers: strict plugin hygiene, a live vulnerability feed, active monitoring, and application-level protection that covers the gap before a patch exists.
Why are plugins such a big security risk?
Because they are the part of WordPress nobody fully controls. Core goes through layers of review before every release. A plugin gets that scrutiny once, at submission, and after that its security rests entirely on a developer whose standards you cannot see. That is why plugins, not core, are where almost every serious vulnerability turns up.
The scale of it grew sharply last year. Patchstack’s State of WordPress Security 2026 recorded 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42% jump on the year before, and plugins accounted for 91% of them. More high-severity vulnerabilities appeared in 2025 than in the previous two years combined. There were only six in core, all low priority. So when someone tells you WordPress is insecure, correct them. WordPress core is solid. The plugins bolted onto it are the problem, and every plugin on every client site is part of an attack surface you are responsible for.
When attackers exploit a plugin, the damage is depressingly familiar. They inject spam links to boost someone else’s SEO. They redirect visitors off the site. They plant a backdoor for later. They quietly conscript the server into sending spam or running a DDoS. The client sees a broken, blacklisted, or defaced site, and you get the call on a Saturday.
Aren’t premium plugins the safe choice?
No, and this is the assumption that catches people out. It feels logical that a marketplace vets a paid plugin more carefully than a free one. The data says the opposite.
Premium components get less security scrutiny, not more, because researchers cannot easily access the code to test it. Patchstack’s research found that 76% of the vulnerabilities reported in premium components were exploitable in real attacks, and premium plugins carried three times as many known exploited vulnerabilities as free ones. Paying for a plugin buys you support and features. It does not vouch for the code underneath. Judge a premium plugin on how fast it patches and how actively its developer maintains it, not on its price tag.
Doesn’t updating plugins quickly keep sites safe?
Not anymore, and this is the shift that changes everything about how you protect a site. The old model assumed you had breathing room between a vulnerability going public and attackers exploiting it. That room is gone.
Patchstack puts the weighted median time to first mass exploitation at just five hours. Attackers hit roughly half of high-impact vulnerabilities within 24 hours. Read that again and think about your actual update routine. If you batch updates for a weekly maintenance window, you are not maintaining sites, you are cleaning up after attacks that already happened. Don’t believe the timeline is that tight? The same research shows attackers hit 20% of heavily exploited vulnerabilities within six hours of disclosure. Five hours is the median, not the outlier.
It gets worse. Nearly half of all vulnerabilities, 46%, had no fix available from the developer at the time of public disclosure. So for almost half of them there is no update to rush out even if you are watching the feed every hour. The vulnerability is public, the exploit is circulating, and the patch simply does not exist yet.
WordPress.org made the timing harder still in 2026. Its “Protect the Shire” policy now holds new plugin releases for up to 24 hours of security review before distributing them, and that hold applies to manual updates from the dashboard, not just background auto-updates. The intent is sound — it exists to stop a poisoned update before it reaches millions of sites, and some plugin authors back it for exactly that reason. But the effect is a guaranteed window where a flaw is known and the fix is still in the queue. One caveat worth knowing: the hold only covers plugins updated through WordPress.org, so premium plugins on their own update servers skip it entirely. Speed alone cannot protect a site, because attackers are faster than any update workflow you can run.
How do you actually protect a client site from plugin vulnerabilities?
You layer your defenses, because no single step catches everything. Here is what holds up, in rough order of impact.
Practice ruthless plugin hygiene
Most vulnerability risk is killed before it starts. Install plugins only from the WordPress Plugin Directory or established vendors, and confirm each one ione still gets regular updates. Anything untouched for six months is a liability, because nobody is screening an abandoned plugin for new issues. Delete plugins you are not using instead of leaving them deactivated, because dormant code is still exploitable code sitting on the server. Every plugin you remove is one less thing that can get you called on a weekend. Fewer, better-maintained plugins mean a smaller attack surface on every site you run.
Watch a vulnerability feed that is actually current
You cannot defend against what you cannot see. A live vulnerability feed tells you the moment a scanner flags a plugin on a client site, what the flaw is, and how severe it is. That lets you triage across your whole portfolio in one pass, instead of learning about a problem from a client whose homepage now sells counterfeit sneakers.
Keep monitoring and a firewall running, whatever the update status says
Traditional defenses aren’t the silver bullet vendors sell. In Patchstack’s pentests of common host and firewall setups, the defenses blocked only 26% of WordPress vulnerability attacks. Nearly three-quarters got through. The reason: nobody built generic firewall rules for WordPress-specific flaws. Broken Access Control was the single most-exploited vulnerability class of 2025, and it slips past most firewalls because the malicious request looks like ordinary authenticated traffic. Monitoring still earns its place, but run it as one layer, never the whole wall.
Add application-level protection to cover the gap
This is the layer that answers the five-hour problem head on. Application-level protection blocks the exploit request before it reaches the vulnerable code, without touching the plugin itself. The vulnerable file stays exactly where it is on the server, but the attack aimed at it never lands. Because it does not wait on a patch, it holds the line during the exact window, before a fix exists or clears the update queue, when sites actually get compromised.
How does ManageWP help with plugin vulnerabilities?
ManageWP surfaces known vulnerabilities across every site in your dashboard, then pairs that visibility with Vulnerability Protection that shields sites before a fix is even available. Instead of logging into each site to check whether a flagged plugin has an update, you see your entire portfolio’s exposure in one view, and protected sites stay covered through the risky stretch between disclosure and patch.
That is the real shift for an agency. You stop reacting to vulnerabilities after they go public and start protecting sites before you have even read the disclosure. When a client asks whether they are safe, you are not explaining what got through. You are showing them a record of what got stopped.
Plugins are what make WordPress worth using, and there is no reason to fear them. Treating them as harmless is what gets sites compromised. Research before you install, keep what you run lean and maintained, watch the feed, monitor continuously, and layer in protection that does not depend on a patch arriving in time.
Layer up.
Frequently Asked Questions
Are plugins really the biggest WordPress security risk?
Yes. According to Patchstack’s State of WordPress Security 2026, 91% of new WordPress vulnerabilities in 2025 were found in plugins, against only six low-priority issues in core. Core is heavily reviewed before every release, while plugin security depends on thousands of individual developers, which is why plugins are where nearly all serious vulnerabilities appear.
Are premium plugins safer than free ones?
No. Patchstack found that 76% of vulnerabilities reported in premium components were exploitable, and premium plugins had three times as many known exploited vulnerabilities as free ones. Premium code gets less independent scrutiny because researchers cannot easily access it, so a price tag is no indicator of security.
Isn’t keeping plugins updated enough to stay secure?
No. Patchstack measures a median time to first exploitation of five hours, and 46% of vulnerabilities have no fix available when they are disclosed. Fast updates help, but they cannot protect a site during the window before a patch exists, or before it reaches your site through the update system.
What should I do about an abandoned plugin?
Replace it. A plugin untouched for six months is no longer being screened for new vulnerabilities, so it only grows more dangerous over time. Find an actively maintained alternative, and delete any plugin you are not using rather than leaving it deactivated, because dormant code can still be exploited.
How does application-level protection differ from updating a plugin?
It blocks the exploit instead of fixing the code. Application-level protection stops malicious requests before they reach the vulnerable plugin, so the site stays covered even when no patch exists yet. It works alongside updates and monitoring rather than replacing them, closing the gap between disclosure and a fix.
Image credit: Unsplash.
Leave a Reply