Patch or Disconnect: AI-Accelerated Flaws in Ubiquitous Foundations

Key Takeaways

On October 21, 2026, the PHP project shipped fixes for two critical remote code execution flaws, CVE-2026-109618 and CVE-2026-109619, collectively called “PHP2Shell.” The flaws are reachable without authentication and affect every PHP version released in the last decade [1][2]. Wiz and OpenAI attribute the discovery in substantial part to frontier AI models, although some reporting states that human researchers found the flaws and that AI was used mainly to build exploits [1][5][6]. Under either account, AI shortened the path from latent flaw to working exploit. The government guidance that followed was unusual. National security and cybersecurity agencies in the United States, the United Kingdom, the European Union, and Japan told operators that if they could not patch at once, they should consider taking affected systems offline [3][5][8][10], and several government and public-sector websites did exactly that [5][8].

This note argues that PHP2Shell is a preview of a recurring pattern rather than a one-off. AI-assisted discovery and exploitation are now reaching the oldest, most widely embedded layers of the software stack, and when a flaw lands in a component that sits beneath a large share of the internet, every organization that depends on it is exposed at the same moment. This is the correlated-exposure problem. Its first consequence is that exposure arrives simultaneously across whole sectors, so response capacity at hosting providers, managed service providers, and downstream vendors becomes a shared bottleneck that individual organizations can do little to bypass. Disclosure timing is also less reliable at this scale. PHP2Shell details leaked before the planned release, and separately, Amazon reported an exploitation attempt against its honeypots four days before patches shipped, earlier than the publicly reported leak and from a source it could not identify [7].

The remaining consequences concern the products and runtimes that organizations cannot fix directly. Products that embed a foundational component typically lag the upstream fix. As of October 22, Palo Alto Networks listed all PAN-OS and Panorama versions as affected with no fixed releases, and Fortinet and Cisco were still assessing dozens of products [2]; the Log4j experience suggests such embedded exposure can persist for years [15]. End-of-life components, in turn, convert a patching problem into a migration problem: PHP 8.1 and older received no official packaged fixes, only minimal source backports [2][3]. Taken together, these conditions make “disconnect” a legitimate control rather than an admission of failure. CSA recommends that organizations establish a pre-approved decision path and a tested isolation procedure for every internet-facing system that runs on a ubiquitous foundation.

Background

PHP2Shell and “Black October”

PHP is the server-side language behind WordPress, Drupal, Joomla, and a long tail of custom applications. Wiz describes it as powering about 70% of websites, a figure that measures market share rather than exposed, vulnerable hosts [1]. According to Wiz’s timeline, its researchers found the first issue on August 19, 2026, confirmed unauthenticated remote code execution against Drupal and WordPress within two days, and reported to the PHP security team on August 24. The PHP team acknowledged the reports on September 21 and published patched releases with public disclosure on October 21 [1]. The fixed versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35, and the project also published minimal source backports for the end-of-life 7.4, 8.0, and 8.1 branches [2][4].

The two CVEs are technically distinct. CVE-2026-109618 involves memory corruption when out-of-memory handling interrupts PHP while request data is only partially initialized, whereas CVE-2026-109619 involves request-owned state that survives after its memory is freed and is then used by a later request on the same worker [2]. Both are rated 9.2 under CVSS v4.0 [3][10]. Because the flaws sit in the core engine rather than in application code, exploitation does not depend on what the site does; Wiz reports that the attack works even when an application never starts a session [1]. Every unpatched PHP installation in the affected version range that serves web requests is affected, regardless of server API, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed [2]. CERT-EU later noted a third related issue, CVE-2026-115560, with details held for a subsequent release [3].

Credit for the discovery is still contested in public reporting, and readers should weigh the competing accounts. Wiz credits its own Wiz Atlas tooling together with Google’s Gemini 4 Argon and OpenAI’s GPT-5.6 Sol, and it also credits Calif and OpenAI with discovery, coordination, and patch verification [1]. OpenAI said it led a coalition of researchers and security providers that worked on the problem for two months, and it called the flaws “one of the most impactful security issues in recent memory” [5]. TechCrunch, however, published a correction stating that human researchers found the vulnerabilities and that AI was used to exploit them [6]. For its part, Wiz states that frontier AI models “substantially reduced that barrier, turning a longstanding flaw into an exploit” [1][2]. Whichever account proves accurate, AI materially compressed the path from latent flaw to working exploit in a decades-old, widely deployed component.

PHP2Shell did not arrive alone. The same week brought a Brotli decoder out-of-bounds write, CVE-2026-111497, which Node.js patched on October 21, crediting “OpenAI Codex Security” among the reporters [11]. Six days later, an autonomous agent from Causal Security found four flaws in EPICS Base in under four hours. EPICS is the open-source control-system toolkit used at roughly 90 scientific and industrial facilities, and the most severe of the four flaws carries a CVSS v3.1 score of 9.8 [12]. Some commentators have taken to calling the month “Black October” [19]. The pattern is consistent with Anthropic’s Project Glasswing results earlier in 2026, in which AI-driven scanning surfaced thousands of high-severity findings across open-source projects faster than maintainers could absorb them [13][14].

The Guidance: Patch, Mitigate, or Go Dark

The official response converged on a three-tier sequence: patch, then apply temporary mitigations, then isolate or take the system offline if neither can be done quickly. Agencies varied in how forcefully they stated the final step, and only some addressed end-of-life versions explicitly. Table 1 summarizes the public positions as reported.

Table 1. Selected government guidance on PHP2Shell (as reported, October 21–23, 2026)

The interim mitigations deserve attention because CERT-EU states plainly that they “do not make an installation safe.” They include disabling session.upload_progress.enabled, disabling fatal_error_backtraces on PHP 8.5, and setting memory_limit=-1 while lowering post_max_size, both through settings that applications cannot override [3]. Operators should note that the memory_limit change removes the limit rather than tightening it. Cloudflare deployed web application firewall rules for known exploit vectors to all plans, including free accounts, before the fixes landed [2][8]. These measures buy time against known exploit patterns, but they do not remove the underlying memory-safety defect.

Security Analysis

Why Correlated Exposure Is Different

Conventional vulnerability management assumes that exposure is roughly independent across organizations. Each enterprise has its own patch queue, its own change windows, and its own risk tolerance, and attackers must work target by target. A flaw in a ubiquitous foundation breaks that assumption. When the vulnerable component underlies a large fraction of all websites, attackers can scan broadly with a common exploit chain, adapting it per target [1], and every defender is racing the same clock at the same time. Cloudflare’s chief executive reportedly said exploitation attempts reached millions within hours of disclosure [5][6]. Reporting on actual compromise was mixed: Dataminr observed only scanning and non-working exploits, while Amazon described the flaws as “now being broadly exploited in the wild” [7]. Defenders should plan for the worse of those two readings until the picture settles.

Correlation also concentrates load on the intermediaries most organizations depend on. Linux distributions and long-term-support vendors received fixes before public release, but the volunteer-maintained Remi repository, a common source of PHP packages for Red Hat–family systems, had no updates available on release day [2][3]. Organizations that relied on it had to switch package sources or build from source in the middle of an emergency, while hosting providers, managed WordPress platforms, and municipal IT contractors faced the same surge at once. TechCrunch’s reporting notes that many site operators do not realize their sites run PHP at all, and that there is no reliable way to reach every party that controls part of a site [6]. Insurance Business observed that the event resembled the shared-software aggregation scenario cyber underwriters have long modeled [8]. The analysis here suggests that the binding constraint in correlated events is less often a single enterprise’s diligence than the throughput of the shared supply chain beneath it.

The Embedded-Component Lag

The most persistent exposure is likely to sit inside products rather than in directly managed servers. PHP is embedded in network appliances, management consoles, and vendor-hosted software that customers cannot patch themselves. As of October 22, the day after disclosure, Palo Alto Networks listed all versions of PAN-OS and Panorama as affected with no fixed releases yet shipped, while Fortinet was assessing 12 products and Cisco 31 products and cloud services [2]. Commentators quoted by SecureWorld expect patching windows for embedded and operational technology products to stretch to several months [10]. For customers of those products, “patch” means waiting for a vendor release, which leaves isolation and access restriction as the only immediate levers. This is the layer where correlated exposure tends to persist longest: the U.S. Cyber Safety Review Board’s review of Log4j concluded that vulnerable instances of that library would remain in systems for “perhaps a decade or longer,” largely because of how deeply it was embedded in downstream products [15].

Because remediation authority differs so sharply across these layers, it helps to separate them explicitly. Table 2 distinguishes the layers at which a foundational flaw appears and who controls remediation at each.

Table 2. Where foundational-component exposure lives and who controls the fix

AI Changes the Rate, Not Only the Count

Two features of AI-assisted vulnerability work make correlated events more likely to recur. First, AI-assisted tools appear effective against old, heavily reviewed code. Project Glasswing surfaced long-latent flaws in mature open-source projects [13][14], and the PHP2Shell bugs had persisted across a decade of releases [1], although the role of AI in their discovery is disputed [6]. The foundations that organizations treat as “known good” because they are old and widely used are therefore candidates for renewed scrutiny with these tools. Second, AI reduces the effort of turning a bug into a reliable exploit, a point on which the competing accounts of PHP2Shell agree [1][6]. Wiz notes that exploitation still required per-target adaptation to memory layout and PHP version [1]; CSA expects that this adaptation work will increasingly be accelerated by frontier models.

The disclosure system is under matching strain, as CSA has examined in earlier work on open-source disclosure [21]. PHP2Shell went from report to fix in roughly two months, yet details still leaked two days before the planned release, forcing the PHP team to accelerate its schedule [7]. Separately, Amazon observed an exploitation attempt four days before patches shipped, earlier than the publicly reported leak, which suggests that at least one other party had working knowledge of the flaws before disclosure; Amazon said it was unclear how the actor acquired the exploit information [7]. Amazon’s advice is direct: defenders “should not assume the public disclosure date is the earliest date of exploitation” [7]. When the affected population is most of the web, the number of parties who must be pre-briefed grows, and each additional party increases the chance of a leak. Coordinated disclosure built for single-vendor flaws may not hold for foundation-level flaws at this scale, and organizations should plan for the possibility that patch day and exploitation day coincide.

“Disconnect” as a Control

A notable element of the PHP2Shell response was the willingness of multiple governments to recommend taking systems offline. U.K. reporting lists Edinburgh and Oxford councils and the Metropolitan Police among sites that became unavailable, and other councils displayed error messages [8]. Japan took parts of some government sites offline “just to be safe,” and the U.K. government said some limited services might be temporarily offline [5]. No successful break-ins had been confirmed in these cases at the time of reporting [8], which suggests the outages were precautionary.

Precautionary disconnection carries real costs. It interrupts public services, may not be covered by business interruption insurance depending on policy wording [8], and in the aggregate may degrade the availability of the web itself as sites go dark [6]. CSA’s assessment, consistent with the NSA, FBI, NCSC, CERT-EU, and Japanese government guidance in Table 1, is that disconnection is nonetheless the appropriate default when a system is reachable, unpatched, and exposed to an unauthenticated remote code execution flaw under active scanning, unless the service owner has explicitly accepted the risk. Public reporting suggests that many organizations, including public bodies, made these decisions ad hoc and under time pressure, with security leaders having to advocate for taking core applications offline against operational uptime priorities [5][8][10]. Few appear to have had a pre-agreed authority for taking a public service offline. The governance gap is therefore as important as the technical one.

Recommendations

Immediate Actions

Organizations should first confirm PHP2Shell remediation across every exposure layer in Table 2, not only on directly managed servers. That means verifying fixed versions (8.5.12, 8.4.27, 8.3.36, 8.2.35, or vendor backports) on every self-managed host and confirming that any third-party package repositories those hosts rely on have actually shipped fixed builds. It also means obtaining written confirmation of patch status from hosting providers and checking vendor advisories for every appliance or product that embeds PHP. Because exploitation attempts preceded the patch, with Amazon reporting activity from October 17 [7], CSA recommends looking for evidence of prior compromise with a lookback to at least mid-October, not only checking for current vulnerability. Indicators described by Wiz include unusual multipart requests followed by memory-limit errors, bursts of HTTP 500 responses, malformed or oversized PHPSESSID cookies, and unexplained worker churn [1].

Any internet-facing system still on PHP 8.1 or older should be treated as unpatched unless an upstream source backport, commercial backport, or distribution backport has been verified as applied [2][4]. Where that cannot be confirmed, the system should be isolated from public networks, in line with CERT-EU and NSA guidance [3][9][10]. For vendor products awaiting fixes, management interfaces should be restricted to trusted administrative networks, and interim mitigations should be applied with the explicit understanding that they reduce, rather than remove, risk [3].

Short-Term Mitigations

Over the next quarter, organizations should build a foundational-component register. This is a short list of the runtimes, interpreters, parsers, compression and cryptographic libraries, and frameworks that sit beneath a large share of their estate, mapped to every system and product that uses them. Software bills of materials help, but embedded components in vendor products often require direct questioning of suppliers. For each component, the register should record which assets can be patched internally, which depend on a provider or vendor, and which run end-of-life versions.

Alongside the register, organizations should pre-authorize a “patch or disconnect” decision path. Each internet-facing service should have a named owner empowered to take it offline, a defined threshold that triggers that authority (for example, an unauthenticated remote code execution flaw in a foundational component with no applied fix), and a tested procedure such as a maintenance page, edge block, or network isolation that can be executed within hours. Edge protections such as managed WAF rules should be enabled in advance, since providers can push rules before disclosure [2][8]. Contracts with hosting and managed service providers should also specify emergency patch timelines for foundational components, so that the shared bottleneck described above is addressed before the next event rather than during it.

Strategic Considerations

At the strategic level, the PHP2Shell episode argues for treating correlated exposure as a distinct risk category in enterprise risk registers and in third-party risk programs. Board-level reporting should state how many critical services depend on a small set of foundational components and how quickly the organization could patch or isolate each. End-of-life runtime retirement should be funded as security work, because an end-of-life foundation converts a routine patch into an unplanned migration under attack.

Organizations that benefit from open-source foundations should also consider their stake in maintainer capacity. AI-assisted discovery is producing findings faster than volunteer projects can triage them [13][14][20]. Coordinated disclosure for foundation-level flaws will likely need pre-notification channels that are broader and better secured at the same time. These two goals are in tension, since every additional pre-briefed party raises leak risk, so wider reach must be matched by stronger confidentiality controls. Enterprises, cloud providers, and AI developers all have a role in funding that capacity. Finally, organizations should expect further events of this kind and should run a tabletop exercise built on a PHP2Shell-like scenario, adjusted for a different foundational component, before the next one arrives.

CSA Resource Alignment

CSA’s research note Project Glasswing: AI Discovery Outpaces Open Source Patching Capacity [14] is the most direct precursor to this analysis. It documented the gap between AI-driven discovery and open-source maintainers’ ability to remediate, and it recommended compensating controls for extended patch windows. PHP2Shell shows that gap materializing in a single, internet-scale foundation, and this note extends the Glasswing analysis from maintainer capacity to the downstream correlated exposure that results. CSA’s AI-Accelerated Vulnerability Discovery and the Patch Debt Crisis [20] addresses the same underlying dynamic of AI-driven discovery outpacing remediation and collapsing exploitation windows, and When Discovery Outruns Remediation: Open-Source Disclosure Strain [21] examines the pressure on coordinated disclosure that PHP2Shell’s leak illustrates.

The “AI Vulnerability Storm”: Building a “Mythos-ready” Security Program [16], authored by Gadi Evron, Rich Mogull, and Rob T. Lee with a group of senior contributors, frames vulnerability operations as a permanent organizational capability with actions staged over one week, 45 days, and 12 months. The pre-authorized “patch or disconnect” path and the foundational-component register recommended here are concrete instances of that capability, and they suit the 45-day and 12-month horizons the briefing describes.

CSA’s The AI-Driven Patch Wave [17] argues for exploitability-based prioritization, continuous validation, clear remediation ownership, and documented compensating controls for systems that cannot be patched quickly. Each of those recommendations applies directly to correlated events: internet reachability and unauthenticated exploitability should dominate prioritization, and isolation is the compensating control of last resort.

Finally, the AI Controls Matrix (AICM) v1.1 [18] provides the control baseline for operationalizing these recommendations. Its Threat and Vulnerability Management domain addresses remediation timelines and compensating controls. Its Supply Chain Management, Transparency, and Accountability domain covers the supplier commitments and component visibility that embedded-component exposure demands, and its Business Continuity domain supports planning for precautionary service shutdowns.

References

[1] Wiz Research. “PHP2Shell: AI Uncovers Critical RCE Vulnerabilities Affecting 70% of the Internet.” Wiz, October 21, 2026.

[2] Help Net Security. “PHP2Shell: Critical PHP Vulnerabilities Patched, Update Now!” Help Net Security, October 21, 2026.

[3] CERT-EU. “Security Advisory 2026-018: Critical Vulnerabilities in PHP.” CERT-EU, October 23, 2026.

[4] The PHP Group. “PHP News Archive 2026.” php.net, October 21, 2026.

[5] Associated Press. “AI Discovered a Software Vulnerability That Could Impact 70% of Websites Worldwide. The Rush Is On to Patch It.” PBS NewsHour, October 22, 2026.

[6] Anthony Ha. “Will AI Expose the Rickety Infrastructure of the Internet?” TechCrunch, October 24, 2026.

[7] Sergiu Gatlan. “Amazon Says PHP2Shell Exploitation Began 4 Days Before Patches.” BleepingComputer, October 22, 2026.

[8] Insurance Business UK. “UK Councils and Met Police Among Sites Pulled Offline After NCSC Alert.” Insurance Business, October 21, 2026.

[9] National Security Agency. “NSA Advisory: Critical Patches Recommended for PHP Vulnerabilities.” NSA, October 21, 2026.

[10] SecureWorld. “Patch PHP Vulnerability Now or Take It Offline, NSA Warns.” SecureWorld, October 22, 2026.

[11] Node.js Project. “October 2026 Security Releases.” nodejs.org, October 21, 2026.

[12] The Register. “AI ‘Hacker’ Finds 4 Severe Bugs in Popular Industrial Control Software in Under 4 Hours.” The Register, October 27, 2026.

[13] Anthropic. “Project Glasswing: Securing Critical Software for the AI Era.” Anthropic, April 2026.

[14] Cloud Security Alliance. “Project Glasswing: AI Discovery Outpaces Open Source Patching Capacity.” CSA, June 2026.

[15] Cyber Safety Review Board. “Review of the December 2021 Log4j Event.” CISA, July 11, 2022.

[16] Cloud Security Alliance. “The “AI Vulnerability Storm”: Building a “Mythos-ready” Security Program.” CSA, April 12, 2026.

[17] Cloud Security Alliance AI Safety Initiative. “The AI-Driven Patch Wave.” CSA Labs, May 10, 2026.

[18] Cloud Security Alliance. “AI Controls Matrix (AICM) v1.1.” CSA, June 22, 2026.

[19] YourStory. “Black October: AI Hacking Fears Rise Globally After PHP Flaws.” YourStory, October 2026.

[20] Cloud Security Alliance AI Safety Initiative. “AI-Accelerated Vulnerability Discovery and the Patch Debt Crisis.” CSA Labs, June 17, 2026.

[21] Cloud Security Alliance AI Safety Initiative. “When Discovery Outruns Remediation: Open-Source Disclosure Strain.” CSA Labs, October 7, 2026.