$_ stdout
~/posts/vulnerability-disclosure.md · on main · 55 min read
/**
* @topic#security #disclosure #vulnerabilities #ai
* @statuspublished
*/

AI & The Death of the 90-Day Embargo

For nearly three decades, coordinated vulnerability disclosure has run on a countdown. CERT/CC set it at 45 days in 2000, Google proposed 60 days for critical bugs in 2010, and in 2014 Project Zero settled on the number the industry still uses: 90 days. For a dozen years, disputes adjusted its edges, with grace periods and patch-adoption windows, but never the number itself. It held because of an economic assumption nobody bothered to write down: finding exploitable flaws is hard, and turning them into reliable exploits is harder. With attacker time and attention scarce, defenders could afford a gentleman's agreement to wait.

In October 2026 that agreement met PHP2Shell, a pair of unauthenticated remote code execution bugs in the PHP interpreter: reported by Calif, Wiz and OpenAI's Codex Security with AI-assisted analysis, probed by exploitation attempts before the patch, leaked as a single bit (a critical PHP bug exists) through forums and Hacker News, followed by a researcher's briefly posted proof-of-concept video, and independently rediscovered during the embargo by prompting a frontier model. This post is about what that fire drill tells us.

The argument runs in four steps. Discovery is no longer the bottleneck: exploitation has overtaken stolen credentials as the leading way in, and mean time-to-exploit is now negative. Remediation is the bottleneck: a queueing model shows that once AI-accelerated arrivals outrun human triage, prioritization quality collapses and backlogs grow nonlinearly. PHP2Shell shows both at once, and adds a more devastating lesson: when a frontier model can turn the bare knowledge that a critical bug exists into a working exploit within hours, a leak of that one bit is nearly as costly as a leak of the exploit. And the institutions around disclosure were all sized for the old bottleneck: the 90-day embargo, NVD enrichment and the SEC's four-business-day incident rule.

The post closes with four defenses that still work when exploits arrive within hours: knowing what you run; blocking malicious requests before they reach the parser; fixing faster, by prioritizing on exploitation data and letting AI draft patches that humans review; and removing memory-unsafe patterns while isolating workers and segmenting the network. After each patch, it treats the system as if the attacker got in first.

BL Dr. Ben Livshits October 26, 2026 · 100 commits

The coordinated disclosure ritual is familiar to anyone who has worked on either side of it. A researcher reports a flaw privately, through a security.txt contact or GitHub Private Vulnerability Reporting (GitHub, 2026c). The vendor takes something like 90 days to engineer and test a fix across thousands of configurations. Distribution maintainers stage patches under embargo, and the public advisory lands together with a ready remediation. The whole arrangement works only if the secret stays a secret for as long as the fix takes.

PHP2Shell (CVE-2026-109618 and CVE-2026-109619) shows why that condition no longer holds. By W3Techs' count, PHP runs on roughly 70% of websites whose server-side language is known. Both bugs sit in the interpreter itself, below any application code.

They were (1) reported by teams working with frontier models, (2) targeted by exploitation attempts against honeypots four days before the official release, (3) leaked through a broken chain of contacts, and (4) independently rediscovered during the embargo. The incident was a five-alarm infrastructure fire. It was also a preview of how disclosure behaves once AI has changed the economics of discovery and weaponization at once.

Figure 1 is the infographic's framing of the argument: machine-speed exploitation on the left, the defensive adaptations that answer it on the right.

Infographic titled 'AI & The Death of the 90-Day Embargo,' split into two panels. Left, 'The problem: machine-speed exploitation': exploitation hits 31% of breaches, becoming the #1 access vector, knocking stolen credentials off the top spot for initial network access; mean time-to-exploit drops to minus 7 days, so active exploitation routinely starts a full week before official patches ship; report volume runs 12x ahead of known fixes; and AI bug hunting overwhelms human triage capacity, leading to severe backlog growth. Right, 'The solution: defensive adaptation': implement pre-parser edge containment, enforcing strict proxy bounds before malformed payloads reach underlying language runtimes; shift triage to active exploitation data, replacing static CVSS scoring with CISA KEV and live threat telemetry; scale patch service rates with human-reviewed AI synthesis; and automate test generation while retaining human review to catch semantic errors.
// Figure 1. The infographic's framing: machine-speed exploitation on the left, defensive adaptation on the right.

01 The End of Discovery Scarcity

None of the trends in this section is new to this blog. I have written about the shrinking gap between disclosure and exploitation in Patchmageddon? Or Not So Much, about AI-found bugs swamping bounty programs and maintainers in Mutiny on the Bounty and The Algorithmic Siege, and about the falling cost of exploitation in Cheap, Fast, and Local. What follows brings the latest numbers together, because PHP2Shell is where those trends meet.

Until this year, stolen credentials held the top spot in the Verizon Data Breach Investigations Report as the way attackers got into enterprise networks. The 2026 edition is the first in the report's 19-year history to knock them off it: vulnerability exploitation became the leading initial access vector, at 31% of breaches against 13% for credential abuse (Verizon, 2026; Help Net Security, 2026a).

Attacker microeconomics explains it. Getting in with stolen credentials takes an industrial supply chain of infostealer logs, combolists and validation infrastructure, and even then the attacker still has to get past multi-factor authentication and behavioral identity controls. Exploiting an unpatched, internet-facing vulnerability skips authentication entirely. As AI drives down the cost and time of turning a latent flaw, or a patch diff, into a working exploit, exploitation becomes the path of least resistance.

Figure 2 contrasts the old disclosure timeline, where defenders patched before a proof of concept appeared, with the 2026 one, where exploitation can start before the patch exists. That reversal changes what a patch accomplishes. An attacker who gets in during the pre-patch window can plant a backdoor, in PHP usually a web shell, so they can return after the hole is closed; NCC Group warns that attackers who already gained access "may have installed backdoors to get back in once the patch has been applied" (Hull, 2026). The patch stops new break-ins but does nothing about attackers already inside, so defenders now have to patch and then hunt for what was left behind.

Traditional versus 2026 exploit timeline Two timelines aligned on the day the patch ships. Traditional coordinated disclosure before 2025: a bug is found, a 90-day embargo follows, the patch and CVE are released, and weeks pass before a proof of concept appears; defenders patch during those weeks, before the PoC. In 2026: an AI audit or a leak leads to rediscovery within hours, exploitation in the wild starts about seven days before the patch, and backdoors are installed before the patch exists. patch ships TRADITIONAL CVD (PRE-2025) 90-day embargo defenders patch here Bug found Patch + CVE weeks PoC 2026 rediscovery in hours exploited in the wild ~7 days before patch patch, then hunt backdoors AI audit / leak Patch backdoors installed pre-patch
// Figure 2. The disclosure timeline before 2025 and in 2026, aligned on the day the patch ships.

The telemetry from 2025 and 2026 shows how far the window has compressed, and how cheap the offense has become:

// the ordinary, industrialized

The 2026 DBIR, drawing on misuse data from Anthropic, reports, according to Delinea's summary, that fewer than 2.5% of the AI-assisted cases it examined used rare techniques; I could not check the report's own wording.

I don't think novelty is the point. Frontier AI, together with campaigns like GTG-1002 (Anthropic, 2025, where Claude Code carried out 80–90% of operations autonomously against about 30 targets), the JadePuffer campaign (Sysdig, 2026), and single-operator intrusions issuing thousands of AI commands against government agencies (Gambit Security's account of the breach of nine Mexican agencies, which I have seen only in press coverage such as TechRadar's), has industrialized the ordinary.

In the first half of 2026 alone, Flashpoint's midyear threat report tracked more than 22 million posts in illicit forums sharing and advertising criminal AI toolkits. I look at GTG-1002 and JadePuffer in detail, and at why they are a different kind of incident from emergent agent behavior, in Agentic Swarms.

02 When Arrivals Outpace Remediation

Security engineering has long treated vulnerability management as a search problem: find more bugs through static analysis, fuzzing or bounties, and security improves. Mohammad Reza Faghani's recent queueing model (Faghani, 2026) shows why AI breaks that premise and turns the field into a question of remediation capacity.

The Queueing Model

Model an enterprise as a weighted dependency graph of n systems. Each node i holds a replenishing pool of latent vulnerabilities Ui(t), governed by

dUi(t)dt=ηi(t)−di(t)−χi(t)

where ηi is the rate at which new vulnerabilities arrive through deployment, dependency upgrades and configuration drift, di is the discovery rate, and χi is structural removal that never enters the ticket backlog, such as decommissioned code or architectural simplification.

When AI multiplies discovery by a factor k (Faghani's simulations sweep k∈{1,2,3,4,6,8,10}), two regimes follow:

  1. Transient discovery shock. Frontier models drain decades-old pools of latent bugs that resisted fuzzing, which is, on my reading rather than the paper's, what happened in OpenSSL and in the PHP interpreter.
  2. Persistent arrival floor. Continuous deployment keeps ηi>0, so discovery never drops to zero even after the legacy bugs are flushed out.

Faghani's simulations also show the limit: at k=8, remediation automation cuts the backlog while systemic risk stays high, and pairing it with segmentation does more than automation alone.

For a node's remediation queue to stay stable, its long-run arrival rate of actionable vulnerabilities has to stay strictly below its effective remediation service rate:

a¯i=lim supT→∞1T∫0Tθiλi′(t)Ui(t)dt<μ¯i

The load is the ratio of long-run actionable arrivals to human triage capacity, LT=A¯H¯. Figure 3 traces how the overload propagates from the triage queue to the patching queue and out into the network.

How triage overload propagates An AI-accelerated arrival stream feeds a triage queue whose long-run load is L_T = A / H; when L_T exceeds 1, triage quality Q_T collapses. Two outcomes follow: low-risk bugs are misprioritized and critical remote-code-execution bugs are delayed in the backlog. Both feed a finite patching queue with service rate mu_i, which leads to a compressed exploit window and cascading compromise across the network graph. AI-accelerated arrival stream A(t) Triage queue LT = A / H when LT > 1, triage quality QT collapses Low-risk bugs misprioritized Critical RCEs stuck in backlog Finite patching queue service rate μi Compressed exploit window Cascading graph compromise
// Figure 3. How an overloaded triage queue feeds a finite patching queue and, from there, the network.

Here λi′(t) is the AI-accelerated per-vulnerability discovery rate and θi the fraction of discoveries that are actionable. Summed across the graph, the long-run actionable arrival rate meets a finite human triage capacity H¯, and their ratio is the triage load:

A¯=∑ia¯i,LT=A¯H¯

Once AI-driven discovery pushes LT above 1, Faghani models prioritization quality as

QT=11+γ(LT−1)+

where (x)+=max⁡(x,0) and γ measures how sensitive the organization is to overload.

// what γ does

Below capacity, with LT≤1, the penalty term vanishes and QT=1: every actionable finding gets proper triage. Above it, quality falls, and γ sets how fast. At twice capacity (LT=2), an organization with γ=1 sees prioritization quality halve to 0.5, while one with γ=3 falls to 0.25. Two organizations with the same load can therefore end up in very different places.

A low γ describes triage that degrades gracefully: accurate asset inventory, automated deduplication and exploitability scoring keep the queue roughly sorted even when people are swamped. A high γ describes triage that rests on a few experts' judgment, where every extra finding takes attention from the ones that matter.

What the Data Shows

The model makes three predictions that can be checked against 2026 data: actionable arrivals rise, the service rate does not keep up, and triage degrades under the load. I take them in that order.

Start with arrivals. Zero Day Clock, an independent observatory that grew out of the first Unprompted conference in San Francisco in early 2026, counts them from public catalogues. In the first half of 2026, 35,849 vulnerabilities were published, 491 were newly named as exploited, and 141 of those "were already being exploited when they went public"; in its latest quarter, 132 CVEs were listed as exploited no later than publication, against 85 a year earlier (Zero Day Clock, 2026a).

Google's threat intelligence group measures how much of that flow is actionable. Only 0.23% of vulnerabilities disclosed in 2026, roughly 1 in 431, were observed in active exploitation, but exactly half of the AI-discovered ones are remote code execution, against 26% across all CVEs (Grunewald et al., 2026). Most of the queue is noise; the part that matters is getting worse.

Meanwhile the service rate is moving the other way. The 2026 DBIR puts the defender side at a median 43 days to full resolution, up from 32, with 50% more critical vulnerabilities to patch (Verizon, 2026). The queueing model treats the service rate as a capacity; the DBIR's two numbers move in opposite directions, with more critical findings and slower resolution in the same year. Set against Mandiant's attacker clock, measured from the same disclosure event, the gap between minus seven and 43 is roughly fifty days in which the exploit is public and the fix is not.

That minus seven is an average, and Zero Day Clock declines to publish a time-to-exploit number at all. In its words the metric "fails in three separate ways, and each of them flattens the line for reasons that have nothing whatever to do with attacker behaviour": it ignores aging, so recent years look artificially fast; it saturates at zero, so once much exploitation lands on publication day it cannot show further acceleration; and an average hides shifts at both ends of the distribution (Zero Day Clock, 2026b).

// reading minus seven days

Zero Day Clock's caveats apply to Mandiant's number as well. When a catalogue date comes before the CVE date, "the sign is about which record came first, not about attackers," often because a vendor advisory went out before the CVE record, and published CVE counts grew partly because more organisations can now issue identifiers. A negative time-to-exploit does not mean every vulnerability is exploited before a patch; it means the median has crossed the line, so the defender is no longer racing the attacker to the same deadline.

The third prediction, that triage degrades under overload, is where the evidence is thinnest, but what practitioners report fits the equation. In Flashpoint's 2026 enterprise threat intelligence survey, as covered by Let's Data Science, 65% of respondents named alert noise and false positives as their main obstacle and 55% named insufficient analyst bandwidth; I could not check either figure against the report itself. Under overload, triage quality collapses. Critical, reachable vulnerabilities get buried behind lower-risk findings, and the unresolved backlog grows nonlinearly.

The Sending Side

The queue starts on the sending side, with the labs that find the bugs.

Anthropic's policy shows the pressure: details go public after 90 days or once a patch ships, whichever comes first, with a seven-day target for actively exploited critical bugs, and volume to any single project is paced at what its maintainers say they can sustain (Anthropic, 2026c). The discovering vendor now sits in the policy seat: the party finding the bugs sets the clock and the volume it reports, a conflict the old researcher-vendor model never had to resolve.

The researcher's incentive was credit; the AI vendor's incentive is to demonstrate capability without becoming the maintainer of every project its model touches. Anthropic's dashboard is open about the imbalance. Transparency is not accountability, though.

OpenAI's Patch the Planet (CSO Online, 2026) and Anthropic's Glasswing put the same labs on the funding side of the audits, which makes the disclosure relationship recursive: the vendor pays for the audit, finds the bug, sets the deadline and reports the result. The Linux kernel cuts that knot one way, by treating AI-found bugs as public. Independent disclosure review is another.

// the queue in one number

The AI vendors' own numbers show the same queue from the sending side. As of October 2, Anthropic's disclosure dashboard counted 6,157 vulnerabilities reported across 591 open-source projects, of which, to its knowledge, 516 had been patched upstream (Anthropic, 2026b). Reports are running about twelve times ahead of known fixes.

The Receiving Side

On the receiving side, intake is buckling. curl ended its bug bounty in January 2026 after the share of submissions that turned out to be real fell from north of 15% to below 5% (Stenberg, 2026), the trend Seth Larson of the Python Software Foundation had called a "new era of slop security reports" in 2024 (Larson, 2024).

Bugcrowd reported its queues up more than 334% in three weeks and began suspending and banning submitters (Bugcrowd, 2026). GitHub added rate limits to private vulnerability reporting and a structured report form with an "I used AI assistance" checkbox (GitHub, 2026a, 2026b). These are maintainers and platforms reacting to LT>1 in practice.

03 Anatomy of the PHP2Shell Fire Drill

Nowhere did AI-accelerated discovery, fragile embargoes and compressed exploit windows collide more visibly in recent months than in PHP2Shell.

The Bugs and Who Found Them

Two memory-handling flaws in the PHP interpreter, CVE-2026-109618 and CVE-2026-109619, both scored 9.2 under CVSS v4.0, were coordinated under an embargo that held for about two months, short of the 90-day norm, while maintainers and partners prepared fixes and network detections.

Those 70 days were not a courtesy. The fix had to land in four supported branches (8.5, 8.4, 8.3, 8.2) and three end-of-life branches (7.4, 8.0, 8.1), then be packaged by the distributions, with Zeek and Suricata rules staged in parallel (PHP Group, 2026a; Reardon, 2026). Each branch has its own test matrix and its own users; the EOL backports are volunteer work, and the timeline shows one volunteer RPM repository without day-one builds.

The patch itself was the easy part. The hard part was coordinating a release across maintainers, distros and detection vendors without a single party able to see the whole schedule. The leak exploited that structure.

The reports came in three stages:

The credits show what vulnerability research now looks like. Wiz says it used Gemini and GPT models throughout its research (Tzadik et al., 2026), and the PHP Foundation traces the first signs of the underlying out-of-memory problem to a 2024 audit by Quarkslab that found no exploit path at the time. The GitHub advisories also list a fourth reporter account, tomash-areion (PHP Group, 2026b, 2026c).

Because the bugs live in the engine rather than in any application, every web-facing PHP deployment was exposed, including Apache mod_php, PHP-FPM, php-cgi, FrankenPHP and LiteSpeed, on nearly every release back to PHP 5.4, according to Wiz. Stock WordPress, Drupal, Magento, Joomla and Laravel installs could be compromised by an unauthenticated HTTP request before a single line of application or authentication code ran.

The Embargo's Final 23 Hours

Almost everything that mattered happened in the last 23 hours of a 70-day embargo. Figure 4 puts the disclosure timeline, from the embargo through the release, on a time axis broken to fit 70 quiet days beside one busy one.

PHP2Shell disclosure timeline A timeline with a broken axis. Left, compressed: the embargo from August 11, with reports from Calif and OpenAI on August 11 and Wiz on August 24. Right, at hour scale from noon on October 20 to 16:00 UTC on October 21: the CVE IDs leak around 15:00 and are posted to Hacker News at 15:20; PHP publishes a pre-announcement at 19:30 and moves the release forward a day; Calif briefly posts a proof-of-concept video that evening; at 07:34 on October 21 hosting partners report exploitation incidents to Patchstack; at 07:41 Chainguard ships patched images; Cloudflare's WAF had protected its customers by default since 03:02; government and commercial sites go offline during the morning; PHP releases the fixes at 13:52. Aug 11 Calif, OpenAI Aug 24 Wiz embargo, 70 days Oct 20 12:00 18:00 Oct 21 00:00 06:00 12:00 Oct 20, 15:00–15:20 IDs leak; HN post 19:30 PHP moves release up a day evening Calif posts PoC video 07:41 Chainguard ships fixed images exploitation reported to Patchstack 07:34 Cloudflare WAF on by default 03:02 sites taken offline Oct 21, morning 13:52 PHP releases fixes leak or embargo break disclosure or defense attack outage release
// Figure 4. The PHP2Shell disclosure timeline on a broken time axis, from the embargo to the release, in UTC.

Cloudflare's WAF was protecting customers by default from 03:02 UTC on October 21, nearly eleven hours before the release (Cloudflare, 2026). The exploitation reports to Patchstack and Chainguard's early images landed seven minutes apart, more than six hours before it. Figure 5 gives each row with its source.

Date / time (UTC)EventOperational impact
Aug–Oct 2026Calif and OpenAI (Aug 11) and Wiz (Aug 24) report the flaws; held under a multi-party embargo with PHP, distributors and detection partners such as Corelight (PHP Foundation, 2026)Upstream patches and Zeek/Suricata rules prepared behind closed doors
Oct 20CVE IDs leak along a chain of contacts (~15:00) with a wrong release time and a wrong CVSS 10.0; user petecooper posts them on Hacker News (item 50167754); at 19:30 PHP publishes a pre-announcement and moves the release forward a day, to Oct 21, 14:00 UTC; Calif briefly posts a PoC video (petecooper, 2026a; PHP Group, 2026a)Defenders know a critical RCE exists but have no patch or technical detail
Oct 20, 21:57First memory-pressure probes reach OffSeq's honeypots; the trigger field had appeared zero times in the previous six weeks (OffSeq, 2026)The one-bit leak turns into probing within hours
Oct 21, 03:02Cloudflare's WAF protects free and paid customers by default against php2shell, nearly eleven hours before public disclosure (Cloudflare, 2026)Protects only origins that drop non-Cloudflare traffic
Oct 21, 07:34Hosting partners report active exploitation incidents to Patchstack (Virkus, 2026)Pre-patch scanning and weaponization accelerate
Oct 21, 07:41Chainguard publishes patched PHP images more than six hours before the coordinated release (PHP Foundation, 2026)The fix is public in binary form while most users wait
Oct 21, 07:43Cloudflare's CTO confirms early attack traffic (Virkus, 2026)Attack traffic is visible at the edge before any patch exists
Oct 21, morningDutch government services (DigiD, MijnOverheid, House of Representatives, NCSC site), UK council and police sites, Tweakers, The SEO Framework and, reportedly, Japanese platforms (Kodmon, Shadowverse: Worlds Beyond, Sakura rental server) go offline (Insurance Business, 2026; Rijksoverheid, 2026)Civic and commercial infrastructure shut down voluntarily for lack of a patch
Oct 21, 13:52PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, eight minutes ahead of the planned 14:00 UTC, plus minimal source backports for EOL 7.4, 8.0 and 8.1 (PHP Group, 2026a)Volunteer repo rpms.remirepo.net lacks day-one builds; source builds, distro migration, mass patching and backdoor hunts begin
// Figure 5. The PHP2Shell disclosure timeline row by row, with sources and times in UTC.

Read top to bottom, Figure 5 runs the coordinated release backwards. The release was meant to be the moment everyone learned of the bug together, with fixes and detections ready. Instead it is the last row. Probes reached honeypots about seven hours after the leak, before any protection was public; Cloudflare's rules, the exploitation reports and Chainguard's patched images all came before PHP's fix; and organizations with no patch and no indicators took their sites offline to wait. The 70 days of preparation bought the fixes. The final 23 hours decided who had them first.

Assessing the Damage

The operational cost was real. The October 20 notice (PHP Group, 2026a) confirmed two CVSS 9.2 flaws without fixed packages or technical indicators, so CERT-EU advised organizations that could not patch immediately to isolate internet-facing PHP systems (CERT-EU, 2026, Advisory 2026-018), and the UK's National Cyber Security Centre told them to consider taking such systems offline (NCSC, 2026).

Public infrastructure in the Netherlands, the UK and, reportedly, Japan went dark for hours, as Insurance Business and Rijksoverheid reported, waiting for the embargo lift. Coming back took longer than going dark: NOS reported MijnOverheid reachable again just after 18:00 Amsterdam time and the DigiD site around 20:30 (NOS, 2026), two to four and a half hours after PHP's release.

// attempts, not compromises

Nobody had confirmed a successful breach by then: AWS says it is unclear whether any of the attempts it saw would have succeeded, the Dutch government said on October 21 (Rijksoverheid, 2026) that there were still no signals of active exploitation as it took its own sites offline, and the PHP Foundation found no functional exploit among the circulating proofs of concept at release.

Two days later the picture had barely changed. None of the PHP2Shell CVEs was in CISA's Known Exploited Vulnerabilities catalog as of its October 23 release (CISA, 2026d), and Rapid7 had not observed exploitation in the wild (Rapid7, 2026b).

The Dutch NCSC moved in both directions within a day. On October 22 it said it was investigating the first signals of successful exploitation, which had reached it through its international network rather than from Dutch victims. By the afternoon of October 23, after further research, it told ANP that exploiting the two flaws is complicated and that the chance of large-scale abuse is lower than first estimated (Reformatorisch Dagblad, 2026; my translation).

For two days the closest thing to a confirmed intrusion was Unit 42's threat brief. Its October 23 update described attackers at a European government agency who had password hashes and MFA secrets within two hours of initial access, using agentic AI tooling for the post-exploitation work. On October 25 Unit 42 retracted that update: the attack ran "in the context of a vulnerable PHP application," but it was "unable to confirm that initial access is associated with the specific PHP2Shell CVEs" (Unit 42, 2026). Attribution moved faster than the forensics, which is its own cost of a disclosure run at this tempo.

Exposure is the slower half of the damage. Brandefense's version checker ran against 30,027 sites between October 21 and 25. Only 3,532 of them disclosed a PHP version, and 59% of those (2,071) showed one older than the fixed releases, 1,157 of them on end-of-life branches (Brandefense, 2026). Visitors chose which sites to check, so the sample is not random, and as Brandefense notes, a hidden version is not a safe one. The same ANP coverage carries BNR's report, based on scanner runs, that dozens of Dutch ministry, provincial and municipal sites were still vulnerable, and the ethical hacker Wouter van Dongen's reminder that "a patch closes the hole, but does not undo an earlier break-in."

04 Inside the Interpreter

Why did these bugs resist a decade of audits and fuzzing, and what did AI-assisted research see that earlier tools missed? The mechanics of the two CVEs show a class of subtle cross-lifecycle state corruption that static analyzers miss and coverage-guided fuzzers struggle to turn into deterministic exploits.

Both bugs come from the same violation: a fatal error interrupts the interpreter partway through an operation and leaves its invariants broken. In the first, an out-of-memory error lands between bumping a hash table's bucket count and allocating the key, so shutdown destroys a bucket that was never filled in. In the second, an error cuts off the reset between requests, so worker-wide globals still point at memory the previous request freed. Either way, the cleanup code trusts state that the interrupted code only half wrote.

Interrupted Initialization

When PHP handles a form submission, it fills the $_POST superglobal, storing keys and values in internal hash-table entries called buckets, before any of the target script runs. In Zend/zend_hash.c, the insertion logic increments the bucket counter before it finishes allocating memory for the key.

Figure 6 walks through that pipeline step by step.

The CVE-2026-109618 exploit pipeline Five steps in a vertical pipeline. One: an HTTP POST arrives. Two: PHP parses the form data into the $_POST hash table in Zend/zend_hash.c; the nNumUsed counter is incremented first, then the key allocation fails with out of memory. Three: a fatal error aborts request initialization with "Unknown on line 0", and bucket N stays uninitialized, holding attacker-controlled heap bytes from an earlier allocation. Four: shutdown destroys $_POST, iterating all nNumUsed buckets, and reads bucket N as a fake array. Five: a destructor callback on the fake array hijacks control flow into glibc system("attacker_cmd"), and the worker returns HTTP 200 in 3.10 seconds without crashing. 1 HTTP POST arrives 2 PHP parses form data into $_POST Zend/zend_hash.c ordering bug a. nNumUsed++ runs first b. key allocation fails: out of memory 3 Fatal error halts request init "Unknown on line 0" bucket N stays uninitialized, holding attacker-controlled heap bytes from an earlier allocation 4 Shutdown destroys $_POST iterates all nNumUsed buckets, reads bucket N as a fake array 5 Destructor callback on the fake array hijacks control flow into glibc system("attacker_cmd") worker returns HTTP 200 in 3.10 s, no crash
// Figure 6. The five steps from an HTTP POST to command execution in CVE-2026-109618.

If a carefully sized multipart or form request triggers an out-of-memory failure at exactly that point, PHP aborts request initialization (Allowed memory size of ... bytes exhausted ... in Unknown on line 0) and runs its shutdown routine. Destroying $_POST then walks every counted bucket, including the unfinished one whose memory was never initialized. If the attacker has groomed the heap so that this bucket overlaps controlled bytes from an earlier allocation, PHP reads those bytes as a valid nested array, invokes its destructor callback, and pivots into glibc's system() as www-data. Datadog Security Labs showed a refined exploit on PHP 8.5.11 that runs the command in 3.10 seconds, returns a clean HTTP 200, and leaves the worker alive (Frichette et al., 2026).

Cross-Request Use-After-Free

A PHP worker serves thousands of requests over its lifetime and keeps worker-wide globals that temporarily point at request-scoped memory. If a fatal error interrupts the state reset, or a late shutdown diagnostic recreates state after cleanup has run, those pointers are never cleared, and the next request on the same worker hits a use-after-free.

PHP confirmed two exploitable paths: fatal-error backtraces in PHP 8.5 on mod_php, and multipart upload processing through session.upload_progress.enabled on both mod_php and PHP-FPM. The setting is on by default and runs before script execution, even if the application never calls session_start() (PHP Group, 2026b, 2026c). Tzadik et al. at Wiz Research showed that attackers could use PHPSESSID cookies to leak raw worker memory, including API keys, passwords and live pointers that defeat ASLR, without crashing the process (Tzadik et al., 2026).

The Exploit Was Real

In the Hacker News post-mortem on October 22 (petecooper, 2026b), several commenters first dismissed PHP2Shell as "non-trivial to exploit," because dozens of fake proofs of concept on social media failed against ASLR. The skepticism was only half wrong. Researchers, including cookiengineer in actual-php2shell, showed exploits working against a stock index.php containing nothing but an echo, but the public proofs of concept stayed fragile. Through October 23, Rapid7 found that each one achieved RCE only against a specific combination of operating system, PHP version and web server (Rapid7, 2026b), and Sansec that they do not work against a default PHP installation (Sansec, 2026).

All the same, the capability existed. By the early hours of October 22 VulnCheck had a private exploit that chained a memory leak into RCE on PHP 8.4.26 with ASLR enabled and display_errors=off, the recommended production configuration (VulnCheck, 2026b). Its explanation of the flood of fake proofs of concept is the post's argument in one line: "upon seeing the leaked info, ten thousand LLMs were immediately pointed at PHP source code." Hard to exploit reliably and unexploitable are different claims.

Those bugs had also been waiting a long time. Wiz says every PHP version released in the last decade is affected by at least one of them, including releases back to PHP 5.4, which shipped in March 2012, and that the vulnerable code had been present for more than a decade (Tzadik et al., 2026). The 2024 Quarkslab audit came close: a PHP core developer saw the first signs of the out-of-memory problem while fixing another finding, and an exploit was theorized but no concrete attack vector found. By those dates the flaw sat in shipped code for at least fourteen years, and in partial view for two, before AI-assisted audits found working attack paths in 2026.

05 Why Embargoes Are Fragile

The disclosure debate has historically had two poles. Coordinated disclosure keeps a flaw secret through a multi-month patch window to limit harm. Full disclosure, the 1990s nuclear option, drops a proof of concept immediately to force negligent vendors to act. Both assumed that if the discoverer and the vendor stayed quiet, the vulnerability stayed secret during the embargo.

The 90-day norm is younger than the ritual. Coordinated disclosure dates to the late 1990s, and its deadlines have only lengthened. CERT/CC adopted a 45-day policy in October 2000 (CERT/CC, 2000), and Google's security team proposed 60 days for critical bugs in 2010 (Google Security Team, 2010). The 90-day deadline dates to Google's Project Zero, which kept it from its 2014 launch and extended it across Google in 2015 (Project Zero, 2015). Later revisions changed what happens around the deadline, not the deadline itself: since 2021, when a vendor fixes a bug within the 90 days, Project Zero waits another 30 days before publishing technical details, to give users time to install the patch (Willis, 2021).

// why 90 days

Project Zero's policy was never a proof of optimality. The choice was a bet that 90 days was long enough for a real fix and short enough to limit exposure, with a grace period for a vendor that could show a patch was imminent. The number spread because Google's visibility made it a default, and because it fit the release cadence of large vendors; smaller projects inherited it without the staff to use it.

PHP2Shell ran about 70 days, shorter than the norm, which is the first sign that the norm was already slipping before AI entered the picture. The case also broke the older assumption, that a discoverer and a vendor who stay quiet keep the bug secret, from three directions at once.

"An embargo protects defenders only until someone else finds the same bug."Frank Dickson, Dickson Research, quoted in InfoWorld (Plumb, 2026)

Three Things Changed

PHP2Shell broke the secrecy assumption in three ways at once. Figure 7 sets them side by side before the details.

Three ways the PHP2Shell embargo failed Panel one, independent AI collision: a timeline from August to October 2026 with the embargo shaded from August 11 to October 21. The same root cause was reported by Calif and OpenAI's Codex Security on August 11 and by Wiz on August 24, and found by Chainguard on October 16 after a tip; AWS MadPot saw attack attempts on October 17; the patch shipped October 21. Panel two, the one-bit cascade: reporters and PHP knew the root cause, proof of concept and patch; embargo partners knew the fix, release date and detection rules; their contacts knew the CVE IDs and a release time; the Hacker News post on October 20 carried one bit, that a critical bug exists in PHP. A bar in each box shrinks to show the context lost at each hop. Panel three, no-context exploitation: in Fang et al. 2024, a GPT-4 agent exploited 87% of 15 one-day vulnerabilities with the CVE description and 7% without it; for 2026 cyber-tuned models without the description there is no published rerun. 1Independent AI collision The same root cause, found again and again inside the embargo Aug Sep Oct embargo, Aug 11 – Oct 21 Aug 11 Calif, OpenAI Aug 24 Wiz Oct 16, tipped Chainguard attack attempts AWS MadPot, Oct 17 Oct 21 patch 2The one-bit cascade Each hop outward carries less context Reporters + PHP root cause, PoC, patch Embargo partners fix, release date, detection rules Their contacts CVE IDs and a release time Hacker News Oct 20, 15:20 UTC “a critical bug exists in PHP” bar = context the hop still carries 3No-context exploitation What a bare “bug exists” signal is worth to a model GPT-4, with CVE text 87% GPT-4, without it 7% 2026 models, without no published rerun Fang et al. (2024): GPT-4 agent, 15 one-day vulnerabilities
// Figure 7. The three changes behind the broken PHP2Shell embargo: repeated independent discovery, context lost at each hop of the leak, and exploitation rates with and without a CVE description.

They are not independent, but they arrived together.

  1. Independent AI collision. OpenAI's Codex Security independently reported the same root cause on August 11, the day Calif did; The Record reports that Trail of Bits also found the same vulnerabilities during an audit (Greig, 2026); and Chainguard's team found the same memory corruption in a single night after a one-line tip. AWS Threat Intelligence saw PHP2Shell exploitation attempts against its MadPot honeypots on October 17 (Moses, 2026), four days before the patch and three days before the Hacker News leak. When many offensive and defensive teams point frontier models at the same high-value repositories, collisions on the same zero-day become routine.
  2. The one-bit cascade. To protect 70% of the web, the embargo has to include cloud providers, WAF operators, Linux distributions and network detection vendors such as Corelight, so that Zeek, Suricata and Cloudflare rules are ready on day one. Each extra layer of human contacts strips embargo context. On October 20 the two reserved CVE IDs began circulating on forums and social media, and a PHP user posted them on Hacker News at 15:20 (petecooper, 2026a) with a release time he had heard from a contact, who had been told there was no embargo. He had not leaked an exploit. He had leaked one bit: a critical bug exists in this repository. Probes followed within hours: memory-pressure requests reached OffSeq's honeypots at 21:57 UTC that evening, about 16 hours before the patch, in a field that had appeared zero times in the previous six weeks (OffSeq, 2026). He later apologized on Hacker News for unknowingly breaking the embargo (petecooper, 2026b). The release moved forward a day; the leak cost a day of warning, which the exploit window no longer has to spare.
  3. No-context exploitation. The third change is what that one bit is worth. In 2024, Fang et al. showed GPT-4 autonomously exploiting 87% of a set of 15 one-day vulnerabilities when given the CVE description, and 7% without it. Cyber-tuned frontier models such as Anthropic's Claude Mythos Preview (Carlini et al., 2026) and OpenAI's GPT-5.5-Cyber (Help Net Security, 2026b) arrived in 2026, and I expect they have narrowed that gap, though I know of no published rerun of the comparison. A bug-exists signal is now enough for a model to reconstruct the missing context.

From One Bit to a Working Exploit

Chainguard's CEO, Dan Lorenc, told The Register (Lyons, 2026) that one of the original researchers told him on Friday, October 16, that something was coming in PHP, and that the same night his team found the same memory corruption bugs with its AI harness, a frontier model and a "basic prompt of 'find bad vulnerabilities in PHP.'" That account is his own and I have not seen it checked independently. If it holds, a hint that a bug exists was all a model needed.

The reason a one-bit signal can be enough is that heap feng shui, long treated as dark art, is at bottom a constraint-satisfaction problem over complex input grammars: arrange the exact sequence of allocations, frees and multipart payload sizes so controlled bytes line up with an uninitialized bucket. The AIxCC SoK (Zhang et al., 2026) found that complex input grammars and logical constraints are where LLM components add to what parallel fuzzing can do. Heap layout is not one of the cases it studied; the extension to it is mine. The broader argument for pairing model inference with a deterministic fuzzing oracle is in The Jagged Neurosymbolic Frontier.

// the kernel's rule

The Linux kernel has already drawn the conclusion. Its security-bug documentation now says that "if you resorted to AI assistance to identify a bug, you must treat it as public," because in the security team's experience such bugs "systematically surface simultaneously across multiple researchers." A fix can be held back for at most 7 calendar days, 14 in exceptional cases (Linux kernel, 2026). Linus Torvalds put it more bluntly in May: "AI detected bugs are pretty much by definition not secret" (Sharwood, 2026).

The Early Release

What Chainguard did next turned the rediscovery into a dispute. Like other distributors, it had received the patch in advance, and at 07:41 UTC on October 21, more than six hours before the coordinated release, it published patched images. The PHP Foundation called that a unilateral break of the embargo: any attacker could now study the fix in binary form while every other PHP user waited (PHP Foundation, 2026).

Lorenc's position is that the embargo had already lapsed. "It's coordinated vulnerability disclosure, unless there's evidence of active exploits in the wild," he told The Register; in Socket's account, he says vendors involved in the disclosure had reported exploits by the night of October 20, and he notified the coordination group when he made the call (Gooding, 2026). He did not name those vendors, and their reports carry no public timestamps. The one exploitation report in the timeline with a time on it, from hosting partners to Patchstack, came at 07:34, seven minutes before the images.

Chainguard had also set out its own disclosure policy a week earlier.

// chainguard, october 13

On October 13 Chainguard published the disclosure policy for findings from its AI harness: report privately, wait for the fix to ship, then publish an advisory with the maintainers, and "We don't publish exploit code" (Chainguard, 2026).

Both sides have a case. Shipping a fix once exploitation is reported follows a norm that Anthropic's own policy encodes as a seven-day target for actively exploited critical bugs; shipping it as a binary hands attackers a diff that a firewall rule would not have exposed. The policy was written for a world where the finder controls the clock; PHP2Shell was a case where no single party did.

The Hacker News leak cost PHP a day of warning. The independent rediscoveries cost far more: they showed the secret was never safe to begin with. If a rumor that a critical bug exists is enough for an AI model to find the flaw and work out how to exploit it within hours, then keeping a fix quiet for 70 days across dozens of downstream partners no longer protects anyone. It only sets the deadline for whoever finds the bug next.

06 Institutions Under Load

The embargo is not the only institution sized for the old bottleneck. As AI raises the volume of discovered flaws and shortens the exploitation window, the public institutions built to catalog and regulate cyber risk are buckling under the load too. Two of them matter most here: the national vulnerability database, and the securities rules that force public companies to disclose incidents. Others have started to adapt, and the section ends with them.

The End of Universal CVE Enrichment

According to NIST, CVE submissions grew by 263% between 2020 and 2025. The National Vulnerability Database enriched nearly 42,000 CVEs in 2025, 45% more than in any earlier year, and its human-in-the-loop pipeline still broke.

In April 2026 NIST abandoned universal enrichment, reclassified roughly 29,000 backlogged CVEs as "Not Scheduled," and prioritized future enrichment for CVEs in CISA KEV, in software used by the federal government, or in critical software under Executive Order 14028 (White House, 2021), which the Cloud Security Alliance estimates at 15–20% of incoming volume. With most CVEs left unenriched, vulnerability programs anchored on NVD metadata and CVSS thresholds are flying blind.

When Transparency Becomes a Zero-Day

At the same moment technical embargoes are failing, regulatory mandates are handing attackers targeting data. The sharpest case is the SEC's incident rule, and Figure 8 shows the feedback loop its critics worry about.

The SEC 8-K disclosure feedback loop Day 0: a breach is detected. Materiality is determined, which starts a four-business-day clock. A public Form 8-K Item 1.05 is filed while the victim is still uncontained and the dependency unpatched. Adversarial AI agents mine 8-K filings, press coverage and telemetry to infer the unpatched dependency and the defensive focus, then mutate exploits and scan peer firms. The loop returns to the start: peer firms become the next victims. peer firms become the next victims DAY 0Breach detected Materiality determined 4 business days Public Form 8-K, Item 1.05, filed victim still uncontained, dependency unpatched Adversarial AI agents mine 8-K filings, press and telemetry infer the unpatched dependency and defensive focus mutate exploits and scan peer firms
// Figure 8. The sequence from breach detection through a Form 8-K filing to automated targeting of peer firms.

Under the SEC's cybersecurity disclosure framework, the event-driven obligation is Form 8-K Item 1.05: once a company determines an incident is material, a four-business-day clock starts, and Item 8.01 is reserved for voluntary or non-material updates. Companies cannot wait for forensic closure; they disclose what is known, flag what is not, and amend later.

Patrick Warren of the Bank Policy Institute argued in June 2026 that forcing a breached company to file an Item 1.05 disclosure (SEC, 2023) within four days of a materiality determination, while defenders are still containing the intrusion and before upstream open-source dependencies may even be patched, furnishes attackers with "roadmaps for disruption" and turns disclosure itself into a zero-day. The rule remains in force; BPI's post asks the SEC to rescind it, and the SEC has not done so.

// AI in the 8-K

CB Financial Services' May 2026 Item 1.05 filing, which Wilson Sonsini describes as the first triggered by unauthorized AI use, showed that the trigger can be internal, in that case unauthorized "shadow AI" data exposure. Separately, annual governance reporting under Form 10-K Item 106 is where Strauss, O'Reilly and colleagues at the SSRC's AI Disclosures Project have proposed extending disclosure to AI strategy and risk, alongside a dedicated 8-K item for AI incidents.

Warren's timing argument has precedent. During Log4Shell in 2021, Cloudflare saw the first exploitation attempt nine minutes after the vulnerability was disclosed, and limited testing eight days before it (Graham-Cumming & Martinho, 2021). PHP2Shell repeated the pattern with less to go on: memory-pressure probes reached honeypots about seven hours after a leak that said only that a bug existed (OffSeq, 2026). An 8-K pointing to an unpatched dependency would say considerably more.

Mandated transparency becomes real-time targeting telemetry.

Institutions Starting to Adapt

Not every institution is only breaking. The adaptations so far answer the two failures above in the same order, the catalog first and then the disclosure rules, while US policy and industry add layers of their own.

On the catalog side, CISA's Vulnrichment program has been adding the CVSS and CWE analysis NIST no longer guarantees to CVE records, along with CPE identifiers and known-exploitation flags (CISA, 2026c). Vulnrichment is a triage layer, not a replacement for NVD's analysis: it covers a subset, depends on CISA's capacity, and cannot restore the universal enrichment NIST abandoned.

PHP2Shell showed the lag. CISA's Vulnrichment assessment on both CVE records, dated October 21 and unchanged when the records were updated late on October 22, still read "Exploitation: none" (CVE Program, 2026), five days after MadPot logged the first attempt, and neither CVE was in the KEV catalog as of its October 23 release (CISA, 2026d). Enrichment is being redistributed, not restored. That is better than nothing, but it leaves the dependency on a single catalog intact.

On disclosure rules, Europe is approaching the problem from the manufacturer side. The Cyber Resilience Act requires products with digital elements to ship with vulnerability handling, and since September 2026 manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and national CSIRTs: a 24-hour early warning, a 72-hour notification, and a final report within 14 days of a corrective measure (European Union, 2024). NIS2 puts the same 24-hour and 72-hour clocks on essential and important entities, with a final report inside a month (European Union, 2022).

The SEC rule is issuer-facing; the EU rules are manufacturer-facing, which puts the obligation on the party that can actually ship the fix. They also compress the reporting timeline by law: a 24-hour early warning is shorter than any embargo, so a manufacturer that complies with the CRA is telling regulators, and through them the CSIRT network, that an exploited vulnerability exists while it is still trying to patch. The rules do not resolve the coordination problem; they add a state channel beside the vendor's.

In the US, on June 2, Executive Order 14409 (White House, 2026) launched an effort on AI cybersecurity, and Treasury and CISA answered with Gold Eagle, which lets organizations "report, validate, and track AI-related vulnerabilities at scale" (CISA, 2026a). Eight days later CISA's Binding Operational Directive 26-04 replaced fixed deadlines with risk-based ones, including a three-day tier for remediation and forensic triage of the most urgent flaws, and it warns that attackers' "use of AI may further narrow the time defenders have to react" (CISA, 2026b).

Industry is building its own coordination layer. Anthropic's Project Glasswing, launched in April, is framed as securing critical software for the AI era (Anthropic, 2026a). In June the Linux Foundation launched Akrites, backed by founding commitments from AWS, Anthropic, Chainguard, Google, Microsoft and GitHub, OpenAI and others; where a critical package has no active maintainer, Akrites will act as maintainer of last resort so that fixes still ship (Linux Foundation, 2026). PHP2Shell itself came out of this kind of program: according to the PHP Foundation, Calif began its PHP audit under OpenAI's Patch the Planet initiative.

07 Architecting for Asymmetric Velocity

If AI has squeezed the gap between discovery and mass exploitation toward zero while breaking traditional embargoes, how should security architecture and disclosure change? Faghani's simulations and the PHP2Shell experience point to the same four moves, and Figure 9 arranges them around a single goal: keep the remediation queue stable and the blast radius small.

Four defensive moves around one goal A central goal: stabilize the remediation queue, keeping arrival rate a_i below service rate mu_i, and shrink the blast radius in graph topologies. Around it, four moves. One, live wire inventory: passive Zeek and Suricata parsing of HTTP headers and banners to find shadow and bundled runtimes. Two, edge and proxy containment: strict request and multipart bounds, and coordinated day-zero WAF and NDR signatures before requests reach the parsers. Three, AI-assisted patching: scale the service rate mu_i with automated patch and test synthesis, plus human semantic review. Four, structural memory and isolation: remove metadata-before-allocation anti-patterns and isolate workers in microVMs and cgroups. 01 Live wire inventory Passive Zeek/Suricata parsing of HTTP headers and banners finds shadow and bundled runtimes 02 Edge / proxy containment Strict request and multipart bounds; day-zero WAF/NDR signatures before requests reach the parsers CORE GOAL Stabilize the queue (ai < μi) and shrink the blast radius in graph topologies 03 AI-assisted patching Scale service rate μi with automated patch and test synthesis, plus human semantic review 04 Memory and isolation Remove metadata-before- allocation anti-patterns; isolate workers in microVMs and cgroups
// Figure 9. Four defensive moves arranged around the goal of a stable remediation queue and a small blast radius.

The Four Moves

They map roughly onto the watch, contain, patch and harden pillars I examined in Zero-Day Defense: Going from 0 to 1, and they run in the order an incident needs them, from knowing what you run to removing the bug class:

  1. Continuous wire-speed inventory. During PHP2Shell, organizations scrambled because they did not know which containers, staging environments or third-party appliances bundled their own PHP interpreter. Corelight's argument (Reardon, 2026) is that asset records do not answer that question. SBOMs and VEX statements help, but they answer different questions and both go stale. An SBOM says which components are in an image; a VEX statement says whether a named vulnerability actually affects that component. Neither holds after the next rebuild unless the pipeline regenerates it, and a VEX that says "not affected" for a version you no longer run is worse than no record at all. Version numbers mislead in the other direction. Ubuntu shipped the fix as 8.3.6-0ubuntu0.24.04.13 and 8.1.2-1ubuntu2.28 (Canonical, 2026), and Red Hat as 5.4.16-48.el7_9.1 for RHEL 7, a branch PHP itself no longer patches (Red Hat, 2026b). A scanner that compares against upstream 8.3.36 flags those fixed hosts as vulnerable; the reliable test is whether the package changelog names the two CVEs. The records also disagreed with each other: Defendermate reported that on October 22 Red Hat's bulletin called RHEL 7's default PHP vulnerable while its VEX file still listed it as not affected (Red Hat, 2026a, 2026b; Popli, 2026), which I could not check, because the file has since been revised to list a fix. Live traffic catches what the records miss. It does: Server and X-Powered-By headers, banner fingerprints and behavioral anomalies, parsed by Zeek and Suricata sensors, locate unmanaged hosts the moment an embargo lifts.
  2. Pre-parser containment. Both CVEs are reached before application authentication runs (one during request initialization and shutdown, the other on the next request on the same worker), so defenses inside the application are useless. Resilience means enforcing strict protocol, multipart and body-size limits at the reverse proxy or edge WAF before malformed payloads reach the runtime, together with coordinated distribution of detection signatures such as php2shell-detect across NDR and WAF vendors. Those limits narrow the attack without closing it. PHP notes that a multipart request without a usable declared length can pass the post_max_size check, so the proxy has to bound the decoded body. It calls updating "the only complete mitigation" for the first CVE and says the second has "no complete generic configuration mitigation" (PHP Group, 2026b, 2026c). Stopgaps such as memory_limit=-1 and session.upload_progress.enabled=0 work only if they load before request parsing, which rules out ini_set() and .user.ini, and only once every worker restarts, since a reload leaves workers holding state from earlier requests (Red Hat, 2026a).
  3. Scaling the service rate. Judging defensive AI by how many bugs it finds is counterproductive if the findings swamp the engineers downstream; the metric that matters is queue stability. If AI multiplies arrivals by k, backlogs explode unless remediation throughput μi scales with it. That calls for replacing static CVSS sorting with exploitation-informed prioritization anchored on CISA KEV, the Exploit Prediction Scoring System (EPSS) and graph centrality. EPSS gives a probability that a CVE will be exploited in the next 30 days; KEV says it already has; graph centrality says whether the asset sits on a path to something that matters. The three answer different questions, and none of them is a decision on its own. Scaling the service rate also means adopting automated patch generation and test synthesis. Patchmageddon? Or Not So Much makes the same case from the exploitation data: most disclosed CVEs are never exploited at all.
  4. Memory safety and isolation. Faghani's simulated intervention on a scale-free graph at high discovery acceleration (k=8) shows remediation automation cutting the backlog while systemic risk stays high, and the best result comes from pairing it with segmentation and reduced coupling to bound the blast radius. At the language level, patches that kill workers with _exit(137) while leaving the underlying C anti-pattern in place stop being viable once LLMs can hunt for sibling paths on their own. I make the longer case for structural enforcement in Enforcing Security Invariants in the Post-Zero-Day Era, and Automating C to Safe Rust Translation looks at how far automated migration off C has come. Worker isolation is the other half: microVMs and cgroups contain a compromised interpreter, though that boundary is its own arms race (Escape Artists).

The Limits of Patching

The patch itself shows why the fourth move matters. Datadog's analysis of the emergency patch (commit 31c0ea7) is sobering. Rather than refactoring zend_hash.c so that counters are updated only after allocation succeeds, the patch adds a soft memory limit that defers errors to a safe point and a hard limit that kills the worker with _exit(137). Even in PHP 8.5.12, the hash table still bumps its counter before allocating the key. With the anti-pattern still in place, I expect agents scanning for state-desynchronization paths to find new ways to interrupt initialization, and point-patch backporting turns into whack-a-mole, played across end-of-life branches (7.4, 8.0, 8.1) by volunteer maintainers whose capacity runs out long before the agents' does.

That prediction did not take long. On October 23 PHP disclosed CVE-2026-115560, another remote code execution path in the same session upload-progress feature; Cloudflare notes that it affects fully patched releases, including 8.5.12, and will be fixed only in PHP's next regular release (Cloudflare, 2026). The end-of-life tail is the larger problem. Across its customers Qualys counted 110 million PHP installs on end-of-life versions, 71% of what it saw, and only 199,000 patched in the first 12 hours (Abbasi, 2026); VulnCheck puts 1.1 million internet-facing hosts, about 42% of everything running PHP, on branches with no official patched release (VulnCheck, 2026b).

Automated patching has a limit, though. The AIxCC SoK (Zhang et al., 2026) found that 37.7% and 45.6% of the patches from two baseline coding agents passed every automated check yet were semantically wrong on manual review, and defensive red teams face guardrails that jailbroken adversarial models do not, so automated patching still needs formal verification where it is available and human review where it is not. Trail of Bits' review of its own engineers' merged AI-assisted patches found 21 regressions in more than 130 pull requests, none of them breaking a security protection (Naik & Morales, 2026).

After the Patch

The four moves cover the time before and during the fix. With mean time-to-exploit at minus seven days and MadPot catching PHP2Shell exploitation attempts four days before the October 21 release, applying an upstream update is only the midpoint of incident response.

Before a fix ships, the options narrow to runtime protection; after it ships, the work turns to what attackers may have left behind. The backdoors NCC Group warns about (Hull, 2026) are, in PHP, often obfuscated web shells hidden behind encoding chains (base64, compression, ROT13), byte escapes, string splitting and dynamic sinks such as eval(), system and exec.

// after the patch

Because PHP2Shell lets attackers read raw worker memory through PHPSESSID leaks without a crash or an application error, post-patch remediation has to include rotating every secret, token and API key that lived in memory, along with hunting for anomalous shell processes and early initialization errors (Unknown on line 0).

That cost lands on people as well as systems. When one vulnerability forces governments and companies to take civic services offline overnight, the responders doing the work burn out, and resilience depends as much on protecting that capacity, through workload sharing, realistic drills and automated boundary defenses, as on hardening the code.

Protecting that capacity buys time; it does not change the arithmetic. The longer-term answer is to take people out of the repair loop rather than ask them to run it faster. The autonomous remediation pillar of Zero-Day Defense is the first step, still resting on a thin empirical floor, and From Code Complete to Code Missing follows the idea to its end point: software regenerated from a specification instead of patched as text. In that post-code future, a fix like PHP2Shell's would not be a diff to a decade-old C parser but a tightened invariant at the request boundary, recompiled into every deployment at once, and review would move upstream from the code to the specification. That world has its own weak joint, a probabilistic compiler that has to honor the spec, but it is the one where the queue stops depending on how many people are awake.

08 Conclusions

For decades, defense ran on the premise that discovery was scarce and that a 90-day embargo could protect the public while vendors built and tested patches. That premise has collapsed under what I'd call asymmetric vulnerability velocity: the widening gap between how fast AI-assisted attackers find and weaponize flaws and how fast human-led organizations can triage and fix them. No single actor broke the 90-day embargo; the scarcity assumption underneath it did.

The queueing model, the institutional picture and the PHP2Shell timeline point the same way, and defenders should take three lessons from them:

Disclosure itself has to change in three ways:

Institutions are only starting to adjust. NVD no longer enriches every CVE, and its stand-ins, from CISA's Vulnrichment to the Cyber Resilience Act's 24-hour clock and BOD 26-04's three-day tier, redistribute the work rather than restore the old guarantees.

Security through discovery scarcity is over. When a one-line tip and a night's work can surface a decade-old flaw in an interpreter that runs 70% of the web, security cannot rest on the secrecy of a 90-day embargo. It has to be engineered into the runtime, the network topology, the throughput of the remediation pipeline and the capacity of the people who staff it.

References

PHP2Shell: advisories and vendor records
PHP2Shell: distribution and CVE records
PHP2Shell: research, telemetry and response
PHP2Shell: community, press and government notices
Exploitation telemetry
Industry reports and surveys
AI vulnerability discovery and remediation
AI offensive capability
Vulnerability databases, disclosure rules and regulation
Disclosure policy for AI-found bugs
Maintainer and platform intake
Government and industry coordination
PHP2Shell: exposure data
PHP2Shell: follow-up research, October 21–25
PHP2Shell: the embargo dispute in the press
AI-era disclosure and patching practice
Open exploitation data
US executive orders and rules
Secondary coverage (not independently verified)