How AI is driving a surge in web application attacks, and why proving detection now matters more than patching faster
A vulnerability is disclosed in the morning. By lunch, someone has fed the advisory to an AI model and has a working exploit. By the afternoon, a scanner built from that exploit is sweeping the internet for every exposed instance. By evening, it’s a global campaign.
That is not a hypothetical. It is what October 2026 looked like for public-facing web applications. The gap between disclosure and exploitation in the wild, once measured in weeks, is now measured in hours. If your patch cycle runs in days, you are already behind before the first ticket is opened.
The reason isn’t a smarter attacker. The tedious part of weaponizing a disclosure, reading the advisory, writing a proof of concept, building a scanner and pointing it at the internet, is exactly the kind of work an AI model does well and cheaply. The skill floor dropped and the speed ceiling lifted at the same time.
The good news is that speed changes the attacker’s way in, not what they do once they’re inside. That is where defenders can still win.
Four of the five campaigns picked no target at all. They scanned the internet and hit whoever was exposed. The fifth was a targeted espionage operation that had been inside its victims for weeks before anyone knew the flaw existed. A lot of the volume came from low-skill actors running AI-generated tools they didn’t fully understand, which is why the entry points churned so fast.
Diamonds mark the disclosure date; bars show the gap between disclosure and exploitation. ARMORY CASTLE runs the other way: attackers were inside for seven weeks before the flaw was disclosed.
PHP2Shell. A memory-safety flaw in the PHP runtime itself (CVE-2026-109618, CVE-2026-109619), disclosed on 21 October, gave unauthenticated code execution. No application bug was needed, so any PHP endpoint was in scope. Payloads changed with every request, defeating signature-based WAF rules. Rated CVSS 9.2; fixed in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12.
UNC6984. More than 20 different web shells deployed on IIS and Linux servers, followed by privilege escalation using well-known “Potato” techniques. Every tool used after the break-in, such as curl and certutil, ships with the operating system. There was nothing unusual to hash-match.
ARMORY CASTLE. A suspected China-nexus espionage group exploited a zero-day in BeyondTrust Remote Support appliances (CVE-2026-102764) from 29 August, seven weeks before it was disclosed. It dropped a web shell and a SOCKS5 tunnel, escalated to root, harvested credentials and wiped local logs. Actors like this have a history of switching to mass exploitation once a flaw goes public. Rated CVSS 9.3 and listed in CISA’s Known Exploited Vulnerabilities catalog. An appliance is a web application you can’t patch, harden or instrument yourself.
Atlassian Data Center. A path traversal flaw across eight Atlassian Data Center products, including Confluence and Jira (CVE-2026-21589), was mass-exploited within hours of technical details going public. Attackers read plaintext credentials straight off the server and used them to create administrator accounts. Rated CVSS 9.3 and also on CISA’s Known Exploited Vulnerabilities list.
ARTEX and WP2Shell. Autonomous attack frameworks chained a WordPress REST API flaw (CVE-2026-63030) with SQL injection (CVE-2026-60137) to bypass login and install a malicious plugin that doubled as a web shell. The REST API flaw alone is rated CVSS 9.8. Affected versions are WordPress 6.9.0–6.9.4 and 7.0.0–7.0.1, fixed in 6.9.5 and 7.0.2. Disclosed in July, the chain was still being mass-exploited through October because it is now built into automated scanners. The attacker here is a script that doesn’t stop at a 403. Cloud WAFs often block the large plugin upload but let through the small follow-on requests that complete the chain. Having a WAF is not the same as being protected by one.
Alongside these, we’re seeing account takeover of public apps that lack SSO and MFA, and business tools such as BI, CRM and ERP systems with broad production access being used as quiet back doors.
Pick the one that worries you most, whether it is PHP2Shell, a web shell campaign like UNC6984, an appliance zero-day like ARMORY CASTLE, the Atlassian traversal or WP2Shell. Our security architects will show you how it would unfold in your environment and what would stop it.
The runtime and the CVE changed from campaign to campaign. The shape of the attack didn’t. Every October campaign followed the same seven stages.
Steps one and two change every week. Chasing them is an endless cycle of patches and WAF rules, and AI has made that cycle faster than any team can keep up with.
Worse, some doors aren’t yours to close at all. ARMORY CASTLE used its appliance flaw for seven weeks before anyone disclosed it. No patch, WAF rule or amount of diligence at the edge could have caught it, because there was nothing public to defend against. If your detection is built around knowing the CVE, you lose that race every time, and you lose it completely against a zero-day.
The exploit is disposable to the attacker. It is permanent work for you.
Steps four through seven are different. However an attacker got in, they have to run something, persist, look around and talk to the outside world. Those behaviors are durable across every campaign and every future CVE, which makes them where detection actually holds up.
The clearest early signal is almost embarrassingly simple: a web server process (php-fpm, w3wp.exe, httpd) launching a command shell or a download tool. That almost never happens legitimately on a production web server, and it comes minutes before privilege escalation and command-and-control.
So the right mindset is: assume they are in. Then make sure you see them within minutes.
None of this means patching stops or the WAF comes down. Those controls reduce the number of ways in and buy you time, and they still matter. It means you stop expecting to win at the edge, and put your detection where the attacker has no room to maneuver.
Your exposure is exactly the set of applications a scanner can reach, including the forgotten staging site, the old Confluence server and the remote-support appliance someone bought outside IT. Build that list from the outside in (DNS, certificates, cloud public IPs) and reconcile it against what you actually monitor. The gap between the two is usually where the risk lives.
Then review each application for the four weaknesses AI-assisted scanners test first:
An EDR agent that is installed but not forwarding is the same as no agent. You need two layers:
EDR for the first minute, NDR for everything after. Of all the controls we mapped against October’s campaigns, blocking outbound traffic from web servers paired with network-level C2 visibility was the only combination that covered every one, including the appliance zero-day. Neither cares how the attacker got in. You are no longer defending against a list of vulnerabilities. You are defending against the small, fixed set of things an intruder must do once inside.
Most of these are configuration changes, not projects. Together they make a web shell close to useless, even if one gets through.
October exposed the gap at the heart of most security programs: coverage that is assumed, not proven. Dashboards say the agents are installed. Whether the detections actually fire when an attacker shows up, most teams only find out during an incident. Netenrich Autonomous Security Operations (ASO) closes that gap.
Every security leader needs answers to three questions, and the answers change week to week:
When exploits arrive within hours of disclosure, last quarter’s answer is already out of date. Netenrich ASO answers all three continuously, as your environment and the threats against it change.
| Phase | What happens | Draws on | The question it answers |
|---|---|---|---|
| See it | Continuous exposure visibility: the attack surface is mapped and live threat intelligence is correlated to your attack paths | Attack surface and threats | Where are we exposed, and to what? |
| Prove it | Continuous controls validation: simulated adversary tactics confirm your detections fire, before an attacker tests them for you | Controls, tested against real threats | Would we actually see it? |
| Run it | AI agents investigate and correlate signals into one incident, with Netenrich analysts in the loop | Validated controls and the context from See it and Prove it | How fast does detection become resolution? |
Run it is where faster resolution comes from. Netenrich ASO correlates signals across identity, endpoint, web, WAF, network and cloud, so a web server spawning a shell, an unexpected outbound connection and an identity anomaly become one investigation, not three alerts in three consoles. Routine alerts are investigated and contained at machine speed, and analysts spend their time on the decisions only humans should make.
The result: your exposure is always known, your coverage is always proven, and resolution no longer waits on a queue. That is how you answer the question boards are now asking: is our current security spend actually protecting us?
AI didn’t change what attackers do once they’re inside. It changed how fast they get there, and how many of them can. The organizations that come through this are not the ones that patch fastest. They’re the ones that see a web server misbehaving within minutes, and can’t be reached from it when it does.
Patching closes the door. Proving no one got through before you closed it is what gives security leaders confidence.
Schedule a 30-minute executive briefing with our security architects to see your provable readiness score in action.