The latest wp2shell vulnerability was one of the biggest WordPress security events in history. The critical vulnerability chain combined two flaws that allowed unauthenticated attackers to exploit vulnerable sites and ultimately execute malicious code remotely, potentially taking control of them.
In the first week after the disclosure, more than 45 million exploit attempts from nearly 150,000 unique network sources were made. And as the volume continued climbing, we saw just how fast vulnerability disclosure can turn into mass exploitation. For comparison, this scale was roughly 20x what was observed during Drupalgeddon, illustrating how much automated attack capacity has increased.
Coming off the incident, we shouldn’t be looking at the vulnerability alone, but at how little time defenders now have between disclosure and widespread exploitation. Security teams must throw away vulnerability-management processes built around days or weeks of assessment and remediation. That timeline is no longer accurate. They now need to prepare for a response window increasingly measured in just hours.
Mass exploitation no longer requires precise targeting
This attack tells us a lot about modern attacker behavior. One critical tell is that attackers are no longer taking their time to carefully identify vulnerable environments before acting.
During this incident, we saw automated wp2shell scanning hitting Drupal environments using the same WordPress-specific URL patterns – sites that could never have been vulnerable to this particular flaw in the first place.
That’s a meaningful detail, because it shows the scanning wasn’t curated or reconnaissance-driven. It was blasted indiscriminately at anything reachable on the internet, with the URL pattern doing the only “targeting” involved. At the scale of this attack, any failed requests cost attackers very little. This significantly changes the economics of exploitation from “identify, then attack” to “attack broadly, then identify what worked.”
While exploit automation isn’t new, today’s AI and LLMs can potentially compress parts of the process further by helping interpret disclosures, adapt proof-of-concept code, generate payload variations, or troubleshoot scripts. Security leaders are already seeing AI act as a force multiplier for legitimate security work, and the same underlying economics apply to attackers: repetitive technical tasks can increasingly be performed faster and at greater scale.
Now, AI is not solely responsible for the magnitude of this attack. Security teams should operate on the assumption that new vulnerabilities can be operationalized faster than ever, regardless of exactly which automation tools attackers use.
Organizations should no longer assume obscurity, platform differences, or lack of attacker interest will buy them meaningful time, because this instance showed us exactly the opposite.
Breaking an exploit chain doesn’t necessarily mean the underlying vulnerability has disappeared. For example, container-based isolation and runtime controls can block the remote-code-execution component of an attack chain, significantly reducing potential impact even when a vulnerability is actively being exploited at scale. However, unpatched applications may still remain vulnerable to other components of the chain, such as SQL injection, until application-level fixes and broader network protections are fully implemented.
Infrastructure defenses, such as containerization, segmentation, WAF rules and edge controls, can provide critical protection, but they should be treated as layers that buy defenders time, not substitutes for patching. No single safeguard should be expected to carry the full burden of protection. The purpose of defense in depth is to ensure that when one control fails, or only blocks one stage of an attack, another stands between the attacker and full compromise.
That gap matters because patch adoption after a disclosure like this is never instant, and it isn’t even. Weeks out from the initial fix, we’re still seeing a mixed picture. Some organizations patched within days, while others remain exposed today.
That long tail is exactly where compensating controls earn their keep, because they’re what stands between a slow patch cycle and an active compromise.
The window between disclosure and mass exploitation is shrinking, so organizations might not realistically be able to patch every affected application immediately. This is why architecture is so important, and it should limit how much damage an attacker can do during the gap between disclosure and remediation.
When it comes to defense, the goal is not to lessen the importance of patching. It’s to prevent one missed or delayed patch from immediately becoming a big compromise and a full-blown attack.
Vulnerability management needs to move at attacker speed
When we look at traditional vulnerability prioritization, we typically see severity scores, asset criticality, and scheduled patch windows. While these factors still matter, active exploitation should dramatically change the equation.
For critical internet-facing vulnerabilities, defenders should quickly determine:
● Whether exploitation is already occurring at a meaningful scale.
● Whether existing controls block the entire exploit path or only one component.
● Which systems remain exposed and which patches need to bypass normal maintenance cycles.
● What hosting, cloud, CDN or security-provider telemetry reveals beyond the organization’s own environment.
Effective response also depends on connecting what security operations teams observe in real time with the broader security posture engineered into the environment. Telemetry tells defenders what is happening; architecture determines how much damage that activity can actually cause.
For a single website owner, they may see a handful of suspicious requests, while a hosting platform operating across a broad footprint can recognize those same requests as part of a coordinated global campaign. In our case, that visibility extended to standing up a honeypot environment to capture live exploit samples and study what attackers were actually trying to achieve post-compromise. This is the kind of pattern that’s effectively invisible from a single site’s vantage point, but obvious in aggregate. This partnership is extremely important when preventing widespread damage from attempted attacks.
The key is also making that response repeatable. Security teams should define emergency vulnerability-response procedures before the next major disclosure happens, including who can authorize expedited patches, which compensating controls can be deployed immediately and what evidence triggers escalation. A major vulnerability disclosure is the wrong time to start defining those roles and processes.
Prepare for the vulnerability you have hours to address
The 45 million attempts to exploit the wp2shell vulnerability is only a look at what is to come in the future as technology gets smarter and attackers get faster.
But it’s important to understand that not every single CMS vulnerability in the future is going to produce tens of millions of exploit attempts. The real takeaway is to assume attackers have the automation and infrastructure required to test a newly disclosed weakness across enormous numbers of systems almost immediately. While speed is important, speed alone will never be enough.
To be best prepared for the next major vulnerability, security teams should combine rapid patching with architectures that contain exploitation, infrastructure-level controls that can be deployed quickly, and telemetry that helps them recognize when a vulnerability has moved from theoretical risk to active campaign.
Disclosure used to buy defenders a head start. Increasingly, it’s the starting gun for the attackers, too. The organizations that treat it that way will be the ones still standing when the next wp2shell shows up.
Author:
Joey Stanford , CISO at Pantheon, is a highly qualified security and data protection practitioner with over 30 years of experience in the United States, the United Kingdom, and France, managing programs and budgets valued in excess of millions of dollars.
