The Hidden Life of WordPress Vulnerabilities

When does a vulnerability really appear on your site? 

Not when it’s discovered. Not when it is announced. Not when it’s patched.

Vulnerabilities begin the moment they’re introduced into the code—and they often sit there silently for months, sometimes years, before anyone notices. 

Establishing a timeline with data

We wanted to know: how long do vulnerabilities actually live inside plugins before discovery?

So we analysed thousands of plugin change logs. The data was disconcerting. 

Vulnerabilities exist on an average of 14 months between introduction and discovery. 

For instance, BerqWP v2.2.45 patched an unauthenticated arbitrary file upload vulnerability of CVSS score 10 on July 18, 2025. The vulnerability was introduced in v2.1.2, on October 1, 2024, in a release meant to address a cross-site scripting vulnerability of lower severity. 

That’s 9 months where sites could be hacked again and again without anyone realizing the entry point was a fully updated plugin.

In the case of The Events Calendar plugin, we saw it had a high severity PHP object injection vulnerability of 9.3 CVSS for at least 2 years, before it was patched on September 3, 2025 in v6.15.1.1.

There is no telling how many of those websites got hacked because the vulnerability wasn’t discovered or patched for months. 

The worrying part? These weren’t edge cases. They’re normal.

Surprised? You shouldn’t be.

In all honesty, this is not a surprise. The WordPress community has wilfully ignored the evidence. 

Our research confirms what zero-day attacks already suggest: vulnerabilities don’t “appear” at disclosure—they’ve been there all along. 

The large scale attacks make headlines only because of their scale or severity. It stands to reason that there must be even more attacks that are quieter in comparison. 

In an extreme case, the WordPress Markdown Shortcode plugin had a medium severity XSS vulnerability that was introduced 10 years ago in v0.2.1. It was fixed on September 25 2025 in v0.2.3. 

Hackers have exploited sites through undiscovered vulnerabilities for years. They’ve installed malware, hijacked search results, and more. We have seen this in our firewall data spanning 7+ years. 

Hackers are evolving, fast

It is important to understand how the threat landscape is evolving. We must stay ahead of hackers in order to keep our sites, users, and data secure. 

Attackers now have a new advantage: AI.

The same AI that is helping you code quickly is also helping hackers find vulnerabilities faster. 

Combined with an established, thriving network to share discovered vulnerabilities, websites are getting hacked faster and in bigger numbers. The gap between introduction and exploitation is closing.

A PHP object injection vulnerability of CVSS 6.5 was introduced into the Fluent Forms plugin in v5.1.16, released May 6, 2024. It was patched over a year later in v6.1.2, released August 29, 2025. Formerly, it may have escaped notice. But with an active install count of 600,000+, it is exactly the plugin that hackers will scour for vulnerabilities. 

With AI accelerating the pace of attacks, reactive defence is no longer enough. Security needs to be always on—protecting sites from the second flawed code ships, until long after it’s fixed.

The wrong way to deal with vulnerabilities

Right now, the WordPress community thinks in terms of discovery. A bug gets reported, everyone scrambles to update, and then they relax—until the next incident.

But vulnerabilities don’t spring into existence when they are discovered by someone with good intentions—aka not-a-hacker.

Yet, this is how they are treated. As though they don’t exist before discovery.

Critically, it means “fully updated” does not equal “fully secure.” The reality is that your site can and will get hacked if it has a vulnerability.

Therefore your current approach to defence is not enough.

Firstly, updates are reactive. They work after the fact. Secondly, virtual patches will only work from the point of discovery. They prevent attacks from discovery till the plugin is updated on your site. 

The reality is that site security needs to be in place at all times. Right from the moment that a vulnerability is introduced to the point it is fixed, and beyond.

The right way to think about security

You need to zoom out to see that the vulnerability as a threat from when it starts existing. You then realise that security needs to account for the danger from that point on.

To do that, you set up proactive site security to blocks any exploits of the vulnerability. Before, during, and after discovery. The same defence will secure your site for the escalation in attacks when the vulnerability is discovered and announced.

Then, you apply the update as soon as it is out—after due testing, of course.

Next, have a top-grade scanner keep a vigilant eye on your site’s code every single day. The slightest hint of malware trips the alarm, you can deal with it in minutes.

And finally, you round off protection with backups.

As you can see, updating for security is not the wrong strategy; it is an incomplete one. This is your blueprint from moving from reactive to proactive security.