Two of the stories we’ve covered this month — the BdThemes plugin supply-chain attack and the Forminator file-upload flaw — aren’t isolated incidents. They’re both recent examples of a pattern that’s reshaping what “keeping a WordPress site secure” actually requires: the gap between a vulnerability becoming public and someone actively exploiting it has shrunk from days to hours.
The numbers behind the pattern
Through 2026, the WordPress ecosystem has been averaging more than 250 new plugin vulnerability disclosures a week, with roughly 43% of them exploitable without any authentication at all — meaning an attacker doesn’t need a stolen password or a compromised account to use them, just a vulnerable, internet-facing site. Security researchers tracking real-world exploitation have found that automated bots typically start probing for newly disclosed vulnerabilities within hours of public disclosure, often faster than the average site owner even hears about the issue in the first place.
The Forminator flaw we covered fits this pattern exactly: a critical, unauthenticated file-upload vulnerability on a plugin running across 600,000+ sites is precisely the kind of disclosure automated scanning tools are built to find and exploit immediately, not the kind of thing that stays theoretical for long.
What this changes about “regular maintenance”
A monthly or quarterly maintenance check used to be a reasonable cadence for a lot of WordPress sites. It’s a much weaker plan today, not because maintenance itself changed, but because the threat side of the equation sped up. A vulnerability disclosed on a Tuesday can have bots actively probing for it by Tuesday evening; a site that gets checked on the first of next month has an exposure window measured in weeks, not the hours attackers are actually working with.
A few practical shifts follow from that. When a patch is available for something you’re running, applying it immediately is worth prioritizing over waiting for a scheduled update window — the security team’s own guidance on incidents like these is consistent on this point: update now, not at the next convenient maintenance slot. When no patch exists yet for a disclosed vulnerability, deactivating the plugin entirely until one does is safer than leaving it running and hoping you’re not noticed in the meantime — a disabled plugin simply can’t be exploited. And plugins you’ve deactivated but never actually removed are worth cleaning out properly, since a deactivated-but-still-installed plugin can still be an attack surface for some vulnerability classes, and an abandoned plugin nobody’s watching is exactly the kind of thing that sits unnoticed until it’s a problem.
Why this favors monitoring over periodic checks
The underlying shift here is really about response time. A monitoring setup that’s actually watching for new vulnerabilities affecting your specific installed plugins, and flags unusual activity as it happens, closes the gap between disclosure and your response in a way that a scheduled check-in fundamentally can’t — by the time your next scheduled check rolls around, the automated bots have often already had days to work. That’s less about any single incident and more about matching your site’s defense to how fast the threat side is actually moving in 2026. If your current setup is “someone looks at it every so often,” this is the trend that makes the case for ongoing security monitoring instead — and if you’re not sure which of your installed plugins currently have a disclosed, unpatched vulnerability sitting on your site right now, that’s exactly the kind of question worth getting a straight answer to.
FAQ
Does this mean I need to update my site every single day? Not on a fixed schedule, no — the goal isn’t updating constantly, it’s updating quickly once a relevant patch actually exists, and knowing fast enough to act on it. That’s a monitoring problem as much as an update-habit problem.
Is this specific to plugins, or does it apply to WordPress core too? The 250-per-week figure is plugin-specific, but the same principle held for the wp2shell core vulnerability we covered separately — exploitation began within days of disclosure there too. The pattern isn’t limited to plugins; it’s broader than that.
What’s the single highest-impact change I can make based on this? Removing plugins you’re not actively using, rather than just deactivating them, is the cheapest and most permanent fix — it shrinks the number of things that can go wrong on your site regardless of how fast the threat landscape keeps moving.