This morning I got an email alert I almost skimmed past. The subject line was "[CVE-2026-87902] 30,000 IPs Target WordPress in Five Days." I read it twice, because the numbers didn't look like a typo.
CVE-2026-87902 is a critical vulnerability in WordPress core, rated 9.2 out of 10 on the CVSS scale. It's an unauthenticated local file inclusion flaw, meaning an attacker doesn't need a password or an account to try it, and on some server configurations it can escalate all the way to remote code execution. It affects every version of WordPress core from 4.7.0 through 7.1.1: basically every install running until the patch shipped.
Here's where it gets uncomfortable. CrowdSec, a threat intelligence firm I follow, reported 30,813 unique IP addresses sending probe requests for this exact vulnerability since September 23. That's 322,680 total probe attempts in five days, averaging 64,536 a day, and the number kept climbing every single day: from 14,938 up to 124,154.
The number of distinct attacking sources grew about 100x in that same five days, from 237 to 23,321, while the number of attempts per source dropped, from around 63 down to about 5. That's not a coincidence. It means this shifted from a handful of loud scanners you could block with an IP list to thousands of quiet ones. You can't blocklist your way out of that.
And the timeline is the real lesson here. WordPress shipped the patch on September 22. The first real-world attack attempt was logged at 11:49 UTC that same day, hours after the patch existed, before most site owners had even updated. CrowdSec's own detection rule went live September 23. CISA added it to the Known Exploited Vulnerabilities list September 25. The gap between "a fix exists" and "attackers are already testing your site" was measured in hours, not days.
For the record, full remote code execution needs a specific theme folder pattern plus a couple of server settings most sites don't have. But that didn't stop anyone: attackers are firing the whole exploit chain blind at every WordPress site they find and just checking which ones answer.
I want to be clear this isn't me cherry-picking one bad week. This is the pattern with WordPress, and it repeats constantly.
Really Simple Security Plugin: CVE-2024-10924 (CVSS 9.8)
In November 2024, a vulnerability in this plugin let an unauthenticated attacker log in as any user on a site, including the administrator, simply by exploiting a flaw in how the plugin's two-factor authentication checked logins. That plugin was running on roughly 4 million WordPress sites. The Wordfence researcher who found it called it the most dangerous vulnerability his team had seen in 12 years of WordPress security work.
Bricks Builder Page Builder: CVE-2024-25600 (CVSS 9.8)
Earlier that same year, this page builder had its own critical flaw: an unauthenticated remote code execution bug caused by unsafe use of PHP's eval() function through a REST API endpoint. Proof-of-concept exploit code was public on GitHub within days, and real attacks started before most site owners had patched.
Three critical, unauthenticated, remote-code-adjacent vulnerabilities, across WordPress core and two of its most popular plugins, all within about two years. That's not bad luck. That's the cost of building on a platform with thousands of plugins and themes, most written and maintained by people you've never met, all wired into one shared codebase that runs a huge share of the internet and is therefore a huge, constant target.
The gap between "a fix exists" and "attackers are already testing your site" was measured in hours, not days.
On CVE-2026-87902, from the alert that started this article
Not everyone reading this is moving off WordPress tomorrow, and that's fine. If you're staying, here's what I'd actually do:
Keep WordPress core, every plugin, and every theme on auto-update or a genuinely tight patch schedule.
Remove any plugin or theme you're not actively using, because unused code is still attack surface sitting on your server.
Turn on two-factor authentication for every admin account, no exceptions.
Put a real web application firewall in front of the site (Wordfence, Cloudflare, or similar).
Disable file editing from inside the WordPress admin panel entirely.
Keep real, off-site backups that you've actually tested a restore from, not ones you just assume are working.
This is exactly why MDW builds client sites as standalone, custom-built applications instead of WordPress. We deliberately choose a modern, actively maintained programming language built for speed and long-term maintainability, not a plugin marketplace. There's no live admin panel sitting exposed on the public internet. There's no plugin ecosystem for a botnet to fingerprint and exploit. There's no WordPress core to patch in a race against attackers who are already scanning within hours of a fix shipping. There's no theme folder pattern for a local file inclusion chain like CVE-2026-87902 to even go looking for, because that whole category of vulnerability doesn't exist in this architecture.
That's not a sales pitch. It's just what actually removing WordPress's entire attack surface gets you: one less thing you have to think about every time an alert like the one in my inbox this morning shows up.
If you're on WordPress and staying there, we're happy to talk through the hardening checklist above in more detail. If you're ready to move to an architecture that removes this whole category of risk, that's a conversation too.
No obligation. No pressure. Just insights.