Table of contents
Everyone wants the cinematic version of offensive AI. The model finds a path nobody knew existed, ignores the controls, and lands on the objective using an attack class that did not previously exist. Noclip mode. Walk through the wall, skip the level.
That framing is fun. It is also mostly wrong about the near-term risk.
The practical advantage is more boring and more dangerous. AI makes it cheap to keep trying against attack paths we already understand. It can test more variations, explain why something failed, change approaches, connect findings across a codebase nobody has time to read end to end, and continue long after a human operator would have burned the engagement budget and moved on.
That matters. It is also not magic, and the difference between those two statements is where most of the current commentary falls apart.
The Walls Are Real
Known attack paths generally have controls built around them. Conditional Access with device compliance and phishing-resistant authentication breaks a lot of credential abuse. WDAC or AppLocker in enforcement mode breaks a lot of execution. ASLR, DEP, CFG, CET, and the rest of the memory protection stack made entire exploit classes harder, less reliable, and more expensive. Segmentation limits movement. Tiered administration and LAPS limit what a foothold is worth. Rate limits, lockouts, logging, and behavioral detection still work at machine speed.
A model does not reason its way past those controls because it tried hard enough. A blocked process is still blocked. A token that does not satisfy Conditional Access is still rejected. A memory corruption bug still has to survive whatever mitigations are compiled into the target. A host that cannot route to another segment does not acquire a route because someone wrote a better prompt.
The problem is that almost nobody has one clean wall—a single, consistently enforced defensive boundary where the same controls apply everywhere. Instead, they have fifteen years of overlapping products, exceptions, legacy workflows, trusted paths, exclusions, stale systems, half-finished deployments, and controls enforced in one OU and left in audit mode in another. The result not exactly a wall, but a patchwork of defenses with gaps, seams, and inconsistent enforcement that attackers can work around.
As I wrote in The Defensive Stack Is Exposed, the decision logic inside defensive products is increasingly part of the attack surface. Rules, thresholds, exclusions, trusted paths, and management states can now be studied together instead of one at a time.
AI makes finding those seams cheaper. It can test every door, window, vent, service entrance, and badly patched section of drywall, compare versions, watch how the defensive product behaves, recover from dead ends, and keep refining until it finds the place where two controls do not quite overlap.
Reachability is the Variable Nobody Prices
There is another part of this conversation that keeps getting skipped: The attacker has to be able to reach the vulnerable surface.
This is straightforward when the target is an unauthenticated Internet-facing application. Scan for it, send requests, and iterate without compromising anything first.
Once the vulnerable component sits behind authentication, on an internal VLAN, inside a specific workflow, or behind a configuration almost nobody runs, the economics change. Now the attacker needs credentials, a foothold, routing, a particular role, a specific dependency version, or an earlier bug just to get within arm’s reach of the interesting code.
That does not make the bug irrelevant. It changes what the bug is worth. The questions that matter are:
- Can an attacker reach the vulnerable surface, and from where?
- Is the vulnerable behavior present in a default or common configuration?
- Are the required preconditions realistic in production?
- Does exploitation produce something operationally useful, or just a crash?
RCE that requires an unusual configuration, existing administrator access, a disabled security control, and network proximity is technically interesting. It is not operationally equivalent to anonymous RCE against a default Internet-facing install. Security has always been full of bugs that are real and difficult to turn into compromise. AI does not alter that distinction.
Why wp2shell Matters
wp2shell is useful because it landed on the dangerous side of nearly every one of those questions.
Adam Kues at Searchlight Cyber adapted a published multi-agent research prompt, pointed it at a clean copy of the WordPress source with the git history removed, and told it to find a pre-authentication path to RCE in a typical production deployment with MySQL. The run used four agents, forced diversity of approach, and explicit instructions not to stop when the first wave failed.
It came back with a route-confusion bug in the REST API batch endpoint that bypassed parameter validation, chained into a pre-auth SQLi, and then spent several more hours turning a read-only injection into administrator access and code execution.
The constraint about a typical production deployment is the part worth stealing. Kues noted that models will happily satisfy a task by selecting improbable configuration options or inventing preconditions an attacker could never achieve. Requiring a realistic deployment is a large part of what made the result meaningful instead of merely technically valid.
Score it against the questions above:
- The attack surface is routinely Internet-facing.
- The vulnerable functionality is in core, not a plugin.
- No authentication is required.
- No exotic configuration is required; a stock install with zero plugins is exploitable.
- Exploitation produces administrator access and then code execution.
WordPress shipped fixes in 7.0.2 and 6.9.5, backported a related injection issue to 6.8.6, and enabled forced automatic updates because of the severity. The research was legitimately impressive. Pretending otherwise would be coping.
Ten Thousand Eyes
The technical chain is worth reading on its own merits, and Kues wrote it up better than I would have. The part I keep coming back to is simpler.
WordPress is one of the most examined codebases on the planet. Half a billion installs. Twenty-plus years of scrutiny. Commercial scanners, bug bounty programs, academic research, and every offensive shop that has ever needed a warm-up target. The bug was sitting in core the whole time, and one researcher with a well-written prompt and a weekend found it.
I do not know how many people looked at that code without seeing it, and I am not going to invent a number. But “many eyes” was never a control. It was an assumption that enough independent attention would converge on the same defects. This is a clean demonstration that attention does not distribute the way we assumed. Instead, it clusters on the surfaces people already expect to be interesting.
That is the capability shift. Not that the model saw something no human could see, but that a single operator can now apply that kind of attention to a surface nobody had gotten around to, cheaply, and then repeat it.
Another operator can point the same model at the same code and get nothing. A run can find the injection and miss the escalation, spend its context on a configuration nobody uses, or produce findings that die during validation.
The model did not simply walk through WordPress. It explored a large surface, found one weakness, kept going, and connected several unrelated gadgets into a path that worked under realistic conditions. The interesting part is not that AI somehow ignored the defensive walls; it is that it could be told to keep looking, keep testing assumptions, and keep trying different paths long after a human researcher might have moved on. “How to instruct AI to try harder” could probably be its own post, but in this case the advantage looked much more like giving a researcher a nearly unlimited supply of persistence than giving an attacker the ability to ignore walls.
Humans Are an Attack Surface Too
AI will make targeting people cheaper and more effective. Models can write better pretexts, personalize at scale, vary language to defeat content matching, hold a conversation, and generate far more attempts than a human could type.
A better phish only solves the part where someone has to believe it. It does nothing about most of the controls behind the mailbox.
The message still has to survive email filtering and impersonation protection. The user has to receive it, believe it, and act on it. The attacker may still have to defeat phishing-resistant MFA, Conditional Access, browser protections, application control, EDR, restricted privilege, segmentation, and identity monitoring. The user may also just report it.
None of those controls are perfect, and attackers get through them every day. The point is not that people are immune to AI-assisted social engineering. The point is that a perfectly written phish cannot persuade a FIDO2 authenticator to release a credential. A convincing pretext does not grant local administrator. A personalized message does not make an unsigned binary pass WDAC.
An AI-generated phish still needs a delivery path. Stolen credentials still need to satisfy access policy. A payload still needs to execute. A foothold still needs useful privileges. Every stage is another chance for a defender to break the chain, and the stages that do not depend on human judgment are the ones worth funding.
AI Changes the Economics, Not the Requirements
We have seen this cycle before. Exploit kits did not make browser defenses irrelevant. They industrialized attacks against an ecosystem where vulnerable plugins, weak defaults, and unpatched users made exploitation economical. Browser architecture changed, the dangerous plugin model died, sandboxing and site isolation arrived, and mitigations raised the cost and cut the reliability of entire attack classes.
AI offense will do some version of the same thing. It will increase the number of attempts, reduce the cost of analyzing products and environments, and help operators keep going after failure. It will also generate dead ends, unrealistic chains, findings that collapse during validation, and exploits for surfaces the operator cannot reach.
Cheap iteration only matters when it meets real exposure. A capable model pointed at an internal service the attacker cannot route to is not a compromise. A brilliant exploit for a feature nobody enables is not a default pre-auth RCE. A perfect phishing message that runs into FIDO2, application control, and a suspicious employee is not an intrusion.
What Defenders Should Actually Do
Defenders do not need to throw out the existing stack. They need to focus their energy on the principal attack surfaces AI is most likely to target and, more importantly, the places where a successful compromise would be most damaging. That means reducing unnecessary exposure, tightening controls around high-value paths, removing legacy exceptions, and making sure the defenses already in place are actually enforced consistently. The goal is still to frustrate, detect, and stop the attacker; AI simply raises the importance of doing that well in the places where persistent automated exploration is likely to pay off.
Know What is Anonymously Reachable
wp2shell is a reminder that pre-auth bugs in core functionality of ubiquitous software still happen. Know every Internet-facing application and version, including the marketing site nobody claims. Turn off functionality you do not use. Confirm that forced auto-update actually landed instead of assuming it did.
Patch Based on Exploitability, Not One Severity Field
The batch confusion was filed as high severity in the WordPress release notes and Critical in the corresponding GitHub advisory, with a CVSS of 7.5 that does not reflect a chained pre-auth RCE on a default install. If your patch process reads one field from one source, an anonymous RCE can get queued behind something cosmetic.
Limit What One Foothold Can Reach
Do not let one compromised identity or workstation make every internal service reachable. Segmentation and identity-aware access determine whether a foothold is a nuisance or a breach. AI-assisted iteration hurts most when an attacker can cheaply touch ten thousand internal endpoints and keep looking for the one with a seam.
Make Authentication Resist Phishing, Not Bad Writing
Phishing-resistant authentication, device compliance, and token protection remain useful regardless of how good the pretext was. Awareness training gets weaker as the attacker’s writing gets better. Technical controls do not have that problem.
Enforce Controls That Still Work When the Attacker Knows How You Detect
Application control in enforcement mode, ASR rules in block mode, LSA Protection, credential hygiene, modern memory protections, and limited administrative privilege still work when the attacker understands your EDR logic. Assume the attacker has read your agent.
Then make sure defense in depth is actually providing independent layers of protection rather than just a large number of products. Map high-severity detections and prevented attacks back to the controls responsible for them. If nearly all of the meaningful outcomes come from one product, that does not necessarily mean the rest of the stack is useless, but it may expose places where the program is more dependent on a single control than defenders realize. The goal is to understand those dependencies and make sure failure, bypass, or misconfiguration of one layer still leaves other meaningful opportunities to prevent or detect the attacker.
Organizations with enforced phishing-resistant MFA, real identity policy, application control, modern memory protections, actual segmentation, limited administrative privilege, and detection across independent telemetry sources are not suddenly defenseless because an attacker has a model.
Organizations whose security depends on product complexity, hidden detection logic, inconsistent enforcement, undocumented configurations, and an attacker eventually getting frustrated have a much larger problem. They had it before any of this.
Persistence is Not a Skeleton Key
The advantage AI gives offense is not noclip. It is cheaper reconnaissance, faster analysis, more persistent iteration, and more attempts to find the places where the walls were never properly connected.
Most attempts will still fail. The problem is that trying again is becoming cheap enough that failure matters a lot less.
References
- Searchlight Cyber, wp2shell: https://slcyber.io/research-center/wp2shell-pre-authentication-rce-in-wordpress-core/
- Adam Kues on the research process and full chain: https://slcyber.io/research-center/exploit-brokers-pay-500000-for-a-wordpress-rce-i-found-one-with-gpt5-6/