Why Half of WordPress Plugin Developers Ignore Vulnerabilities

You know what really scares us about our work? Not complex technical challenges, not demanding clients, and not even tight deadlines. What scares us is that every week, around 300-400 new vulnerabilities appear in WordPress plugins. Last week alone — 467 of them. That’s not a typo, four hundred sixty-seven security holes in seven days.

But here’s where it gets really interesting. Patchstack recently released their 2025 report, and there’s a number that made our jaws drop: 52% of plugin developers who were notified about a vulnerability simply didn’t fix it before public disclosure. So they’re told “you have a security hole,” and they’re like “okay, maybe later.” And you know what? “Later” often never comes.

Imagine this situation: you install some popular plugin for forms or backups on your site. Everything works beautifully and conveniently. Then six months later, security researchers find a critical vulnerability in it. They write to the developer. The developer reads it, sighs, and… does nothing. Because the plugin is free, brings in no money, and fixing bugs requires time and effort. 71% of disclosed vulnerabilities remain unpatched at the time of publication. Attackers get a ready-made “how to hack” manual, while your site sits there with an open door.

Here’s a recent case from our practice. A client came to us with an e-commerce project — everything was running smoothly, sales were going well, no problems. Until one day it turned out the site was being used to send spam. Turned out one of the backup plugins had a known vulnerability that allowed uploading arbitrary files without authorization. Such vulnerabilities often lead to remote code execution. The developer had known about this for three months, but never released an update — the plugin was abandoned.

So what do we do?

First, stop installing plugins randomly. At our agency, we now check every plugin before installing it for clients: when was the last update, who’s the developer, do they have a history of responsible security practices. Sounds boring, but it really works.

Second, only 30% of users enable automatic updates for plugins. That’s catastrophic. Yes, sometimes updates can break things, but you know what will definitely break things? Your site getting hacked. We set up auto-updates for our clients, at least for security patches, and monitor to make sure nothing breaks.

Third, use server-level protection. When a developer won’t fix a bug (or fixes it too slowly), WAFs and and other server-side security settings come to the rescue.

And finally — be ruthless with abandoned plugins. If the last update was a year ago and the plugin has known vulnerabilities — delete it without regret. Look for alternatives. Yes, it’s inconvenient, yes, you’ll have to reconfigure functionality, but it’s still cheaper and easier than recovering a hacked site and your reputation afterward.

The bottom line

Plugins account for 96-97% of all WordPress vulnerabilities. Half of developers aren’t rushing to fix them. Hundreds of new holes appear every week. This isn’t fear-mongering — this is the reality of 2026.

At our agency, we now treat security not as an optional “let’s also install Wordfence” thing, but as a mandatory part of any project. Plugin audits before installation, vulnerability monitoring, regular updates — all this is a baseline standard, not a premium service.

Because when you see “Your site has been hacked” in your inbox on Monday morning — it’s too late to figure out who’s to blame. It’s easier to prevent this situation altogether.