This was a very hard week for anyone working in IT. The biggest story was PHP2Shell. On October 21, PHP shipped four security releases at once, 8.5.12, 8.4.27, 8.3.36 and 8.2.35, fixing two vulnerabilities that allow remote code execution without logging in. The next day Arista disclosed a vulnerability in its SD-WAN management platform, and it was already being exploited when the advisory went out. The day after that, PHP published another notice: one more RCE had not been fixed in this round. In the same period, LiteLLM was compromised. Plenty of companies use it as a single gateway to call every model provider, and the attacker pushed out a new version carrying an infostealer.
The problem was not only the number of issues, it was also the speed. Amazon’s honeypot sensors, set up to lure attackers, recorded PHP2Shell exploitation attempts on October 17, four days before the patch. The Wiz research team that found the bugs wrote in their report that these were long-standing flaws in PHP, and AI models greatly reduced the skill needed, which turned them into a working exploit. The same week, Microsoft published its write-up on Storm-0940. The group uses an open source agentic AI penetration framework called ARTEX, where the AI decides the next step and calls the tools itself, and several times it went from targeting an organization to privileged access in under 3 hours. Microsoft also notes that AI-automated attacks can run around the clock, weekends and public holidays included.
How long between the patch and exploitation for these Critical vulnerabilities?#
AI has made finding vulnerabilities, writing exploits and breaking in faster and easier. Yet on the defending side, patching and alert handling are still arranged around the assumption that the attacker is a human, which is why so many teams are not ready when the attack comes.
Mandiant’s M-Trends 2026 estimates that for vulnerabilities exploited in 2025, the average time to exploit was minus 7 days, meaning they were exploited before a patch was even out. PHP2Shell and Arista in the table below are real examples.
When Fortinet shipped its hardening release in October, its explanation said AI tools can now help attackers reverse a patch into a working exploit within hours to days. Langflow and Plex in the table are cases of exactly that, and by Fortinet’s account the buffer between a patch release and the first attack will keep shrinking.
| Incident | Patch released | Advisory or PoC public | Exploitation began |
|---|---|---|---|
| PHP2Shell (PHP core RCE) | 10/21 | 10/21 | 10/17, already seen by honeypot sensors |
| Arista VeloCloud Orchestrator (SD-WAN management platform) | 10/22 | 10/22 | Already exploited at disclosure |
| Langflow (AI workflow tool) | April (v1.9.0) | 9/10 advisory | 9/19 |
| Plex2Shell (Plex media server) | 8/4 | 10/16 researcher PoC | 10/17 |
Lining up the timelines of recent Critical vulnerabilities and breaches against the vendor advisories and research reports, two gaps stand out:
- The patch gap runs from the vendor releasing a fix to the fixed version actually running in production
- The detection gap runs from the attacker getting in to the attack actually being stopped (deliberately counted to the point it is stopped, not to the point the alert fires)
The patch gap: a monthly patch window is scheduled at human speed#
At most companies, patching works like this. Once a month, someone checks for security updates to systems, frameworks and packages. Before anything is patched, it runs through a test environment, goes through change management, and only after approval does the upgrade get scheduled. In the recent cases, though, the attacks had already started by the time the patch came out, so patching and mitigation have to be measured on a much shorter clock.
AI has also made researchers faster at finding vulnerabilities, so the volume keeps growing. Microsoft’s October Patch Tuesday fixed more than 1,400 CVEs in a single release, Oracle’s October quarterly update carried 1,295 security fixes, and 35,364 CVEs were published in the first half of this year alone, nearly 50 percent more than the same period last year. Reading advisories one by one and debating every month what to fix first simply cannot keep up. Which classes of vulnerabilities skip the monthly review and go straight to an emergency upgrade has to be written into company policy ahead of time.
Installing the patch is not the end of it either. PHP2Shell is an example of something you cannot finish fixing in a week. For 8.1 and older, there is no official release, only source patches for users to compile themselves. And the notice PHP published on October 23 did not offer a fix at all, only a mitigation: turn off session.upload_progress.enabled for now.
The detection gap: ARTEX reached privileged access in under 3 hours. How fast can you stop it?#
On October 21, Railway published a security disclosure: the system storing customers’ environment variables had been breached, and every customer should immediately rotate all API Keys stored in their environment variables.
According to Railway’s preliminary report, Railway detected the attack early. As soon as the attack began, internal monitoring alerted the on-call engineer because of abnormal latency. Within 3 hours they had concluded an external attacker was trying to escalate privileges, and they stopped Builds. At hour 15, Railway revoked access to the systems known to be compromised, but within the next two hours the attacker still got hold of a CI environment Credential and used it to obtain some customers’ environment variables. About 19 and a half hours after the alert, Railway asked upstream providers including OpenAI, Anthropic and GitHub to revoke those Keys. By the time every internal system had been rebuilt with new Credentials, roughly a day and a half had passed since the first alert. Even with detection and response as quick as Railway’s, data still leaked.
flowchart TD
A["Hour 0
Monitoring alerts on-call engineer about abnormal latency"]
B["Within 3 hours
Confirmed external attack, Builds stopped"]
C["Around hour 15
Access to known compromised systems revoked"]
D["Hours 15 to 17
Attacker obtains a CI environment Credential"]
E["Hours 17 to 19
Some customer environment variables confirmed decrypted"]
F["Around hour 19.5
Upstream providers asked to revoke Keys"]
G["Hours 38 to 40
Internal systems rebuilt with new Credentials"]
A --> B --> C --> D --> E --> F --> G
In Taiwan, the Economic Daily News (in Chinese) reported on 91APP’s investigation. The attacker used an AI-automated penetration tool, got into the internal network through an unpatched Appsmith instance, then obtained database keys from GitLab, and traces of tools including ARTEX were left behind. The attack began in early October. 91APP only started investigating after customers reported that shoppers were receiving scam messages, and it took about 11 and a half days from the start of the attack to fully cutting it off. The regulator, the Administration for Digital Industries, followed up with an administrative inspection (in Chinese), and one of its focus points was whether the abnormal access had been detected in time.
During an intrusion, who has the authority to disconnect and isolate first?#
In Q3 this year I went to an organization that had been breached by an APT to help the blue team analyze what the attacker did. The attacker had taken a large number of credentials and network diagrams in a very short time. Over the course of the meetings, I noticed the client cared most about two things:
- Whether forensics could produce everything needed for the incident report
- Evaluating a SIEM purchase to get visibility across the whole attack surface
A SIEM takes months to evaluate, purchase, deploy and tune. It does solve whether you can see the next attack, but how do you stop a similar attack in time?
NIST’s incident response guidance, revised in 2025 as SP 800-61r3, says that if an organization has defined its criteria and procedures in advance, deciding how to contain and how to eradicate in the moment becomes easier and faster. The same document also calls for spelling out in advance which roles have the authority to confiscate, disconnect or shut down equipment.
How does NIST AI RMF governance apply to AI-automated attacks?#
NIST AI RMF does not tell you how to defend against attackers using AI on your company, but the way it handles risk has a few ideas that can be reused here:
Reassess likelihood: AI RMF defines risk in terms of how likely an event is and how big the impact would be if it happened. Mass login attempts used to rely on fixed scripts, and once inside, a human still had to decide the next move. Once ARTEX is inside, the AI decides the next step and calls the tools itself. For every internet-facing service and entry point, both the likelihood of being hit and the impact afterward need to be reassessed.
Authorize in advance: GOVERN in AI RMF asks leadership to set the risk tolerance. Which classes of vulnerabilities (for example, high-risk vulnerabilities that are already exploited or have a public PoC) can skip change management and go straight to emergency patching, which hosts can be isolated first and reported afterward as soon as something looks wrong, and who makes the decision after hours and on holidays. Write all of that into policy first, so when something happens people can act right away instead of waiting on a long process.
Measure both gaps: An AI RMF Profile puts the current state next to the target state to find the gap between them. Turn the patch gap and the detection gap into two numbers, put the current and target values into your KPIs, and recalculate every quarter, instead of looking only at patch completion rates.
The technology hasn’t caught up, so start with policy#
Checking for updates once a month, upgrading only after testing and change management, and waiting for managers to meet before deciding whether to isolate a host: this whole process is designed for the speed of an attacker who is human. In this month’s cases, PHP2Shell was being exploited before a patch existed, Langflow was exploited just 9 days after its advisory, and ARTEX reached privileged access in under 3 hours several times. At the old pace, both patching and defense will happen after the attack.
Many companies already have detection in place, but once an alert fires, it still has to wait for a person to see it and decide whether it is an attack before anyone decides to stop it. Even Railway, whose detection was fairly fast, still had some customers’ environment variables decrypted. For a company that only starts meeting about what to do after discovering the incident, the response will take even longer. Write into policy which vulnerabilities go straight to emergency patching, which hosts get isolated the moment something looks wrong, and who makes the decision after hours and on holidays, and have management sign off in advance. Then use the patch gap and the detection gap as two numbers, and check every quarter whether they are getting shorter.