On July 17, 2026, a critical vulnerability chain in WordPress core was publicly disclosed. Two bugs, chained together: a REST API routing confusion issue and a SQL injection flaw, nicknamed “wp2shell” by the researchers who found it. Unauthenticated. One HTTP request. No plugin required the flaw was in WordPress’s core.
By July 18, less 0than 24 hours later, automated exploitation attempts against it were already hitting servers I manage.
Not “within a week.” Not “once a proof-of-concept made the rounds on Twitter.” Within hours of the CVE being released.
The window that used to exist
There used to be a rhythm to this. A vulnerability gets disclosed. Researchers write it up. A patch ships, often the same day or within days. Site owners had a grace period, even if at times may have not been a generous one, to apply the patches before anyone weaponizes it at scale. Vulnerability management programs are mostly built around that rhythm: monthly patch cycles, staged rollouts, “we’ll get to it next sprint.”
Whatever the exact number turns out to be, the direction isn’t in question, because I just watched it happen in real time, on infrastructure I’m personally responsible for.
What actually happened
I run a handful of small sites, some of them are WordPress sites. WordPress core patched itself to 7.0.2 on July 17. One specific site did not update, the why is still unclear, but that one site was still on 7.0 for several hours after the release of 7.0.2.
The first probe hit one of them at 15:51 the next day. A handful of requests, a generic browser user-agent, nothing alarming on its own. Over the following days, more of the same, from more IP addresses, in more countries, none of them related to each other not a targeted attack, a vulnerability that had gone public and was being worked through automatically by anyone with a scanner and a list of domains.
By July 22, the requests had a name attached to them. Literally, the user-agent string on some of them just read wp2shell, the exploit tool announcing itself. One request that day carried a response body over 1.3 megabytes, which is not what a failed probe looks like.
My hosting provider caught a SQL injection attempt in the traffic that same day and locked the account automatically. Unfortunately for me that included every site under it, not just the one being hit, before I even knew there was a problem. That’s the part that actually worked as intended. What didn’t work was the five days of runway I’d apparently been running on borrowed time without knowing it.
The part that should worry more people than it does
I spent the following hours doing exactly what you’re supposed to do: check for unauthorized admin accounts, audit the file system for planted shells, comb through cron jobs for persistence mechanisms, dig through a security plugin’s own scan logs for anything it might have already caught. I’ll write that investigation up separately it’s a good story on its own as it had been a while since I looked at WordPress installs.
But step back from the specific outcome for a second. The relevant fact isn’t what I found. It’s what the timeline demands:
If your patch cycle is measured in weeks, and exploitation starts in hours, your patch cycle is not a mitigation. It’s a formality you complete after the fact.
Disclosure on the 17th. First exploitation attempt on the 18th. Sustained, automated, multi-source scanning through the 22nd. My own patch didn’t land until after the account was already locked which means the actual thing that protected those sites for those five days wasn’t my diligence. It was luck, plus an automated detection system operated by someone else.
That’s not a security posture. That’s a gap that happened not to get exploited this time.
What has to change
Visibility can’t be someone else’s job. I only knew this was happening because my hosting provider’s automated systems caught it and told me. That’s a good outcome, but it’s not a plan.
“Patch when convenient” isn’t a real policy anymore for anything internet-facing. A five-day gap between disclosure and patching used to be reasonable diligence. Now it’s most of the exploitation window.
Automated scanning at this speed means every public-facing asset is a target on day one, regardless of size. The scanners weren’t targeting me specifically they were targeting the vulnerability, and I just happened to be sitting on top of it.
Lessons learned:
- Make sure you set automated updates, and that they work
- Make sure you have the right visibility into your environments
- Security in depth is a must! if there was no IDP tool on the hosting results might have been way worse
- CVE / Vuln gets release expect an attack within hours not days or weeks
- Human responses are becoming a complement not the first layer of response
