PHP2Shell was known since 2024. What the case teaches us about coordinated disclosure, zero-days and modern vulnerability and supply chain management.
When terms like “CVSS 9.8” and “critical software vulnerability” suddenly appear on the evening news instead of just in Dependabot or Trivy, you know Germany is in a state of emergency. After thousands of websites belonging to government agencies, public institutions and private companies had to be taken offline temporarily on Wednesday, the full extent of the situation is only now becoming clear.
PHP2Shell was not just a massive IT security incident, but a textbook example of how radically software supply chain security has changed.
The underlying vulnerability had been known since 2024, but the PHP team ignored it – until AI models recently showed how it can be exploited in practice. A patch was then developed under high pressure, with the plan to release the update in a controlled way on Wednesday.
In this post, we explain why things turned out so differently in the end, what the chain of failures around PHP2Shell teaches us about modern CVE disclosure, and what the current flood of zero-days means for our vulnerability management.
Known for Two Years, Proven Exploitable Only Through AI
A PHP core developer discovered the first signs of the memory bug behind CVE-2026-109618 back in 2024 while fixing another finding from a Quarkslab audit—an audit that, ironically, had been funded by the German Sovereign Tech Agency.
Although potential exploitation was discussed, a concrete attack vector had not been proven. Attempts to fix it were certainly made, but they repeatedly failed due to backward compatibility issues, potential new security risks, and necessary adjustments to PHP extensions. The work repeatedly stalled in consensus processes, leaving the known memory issue unresolved for almost two years—a circumstance that the PHP Foundation itself now refers to in its post-mortem as a “structural failure.”
In August 2026, AI-assisted security research finally demonstrated how the flaw could be exploited in practice: Calif reported an unauthenticated Remote Code Execution (Pre-Auth RCE) on August 11. OpenAI independently stumbled upon the same root cause, while Wiz and OpenAI followed up shortly thereafter with additional attack vectors. Only then did the full potential for damage become clear, making remediation the highest priority.
This also puts a widespread assumption in vulnerability management to the test: a bug whose exploitation seems unrealistic today can become a concrete attack path tomorrow with better tools.
Why the Coordinated Disclosure Model Is Collapsing
To understand Wednesday's chaos, one has to keep the planned sequence of a Coordinated Disclosure in mind: following a report, maintainers quietly develop an update, distribute it in advance to distributors under a strict embargo, and publish the patch and advisory at an exact, coordinated time.
As I explained in detail back in July in my guest post for Security-Insider on the “bikini/exploitarium” repository, this coordinated process is currently collapsing due to the massive use of AI on both sides of the barricade. Even in the summer, 23 ready-to-use exploits—including for PHP, libssh2, and FFmpeg—suddenly surfaced online via AI-supported workflows before a CVE or advisory even existed.
In the case of PHP2Shell, technological pressure was compounded by a complete failure in coordination.
The Problem with Zero-Days
The scenario of a zero-day vulnerability—a flaw for which no patch yet exists and which forces entire systems to be taken offline—is known to most IT professionals, at least in theory. In practice, however, and on such a scale, very few have actually experienced it until now.
Looking at current figures, there is unfortunately reason to fear that scenarios like PHP2Shell will occur more frequently in the future: in the last 12 months alone, the number of monthly zero-day vulnerabilities has more than quadrupled. In this blog post, we want to examine how we can handle zero-day vulnerability scenarios in the future, how the processes surrounding reporting and triage can be optimized, and whether it is really necessary to immediately take entire applications offline every time.
How Farion Supports Modern Vulnerability Management
An incident like PHP2Shell clearly shows that point-in-time scans in the pipeline are no longer sufficient when only minutes lie between a patch leak and the first waves of attacks. We are developing Farion to equip development and security teams for this exact dynamic in vulnerability and supply chain management:
- Continuous Real-Time Monitoring & Alerting: Instead of waiting for the next build or commit, Farion permanently cross-references the SBOM of running systems in the background against current vulnerability databases and sounds the alarm immediately as soon as a new CVE is published.
- AI-Assisted Patching: When every minute counts, as with PHP2Shell, Farion helps teams prepare necessary updates and patches with AI support and deploy them into the code as quickly as possible.
- Reachability, Dataflow, and Exploitability Analysis for Software Vulnerabilities: Farion automatically verifies reachability via code and dataflow analyses (documented via VEX). In day-to-day operations, this makes it possible to quickly separate which vulnerabilities can actually be exploited by attackers and which ones do not affect your own system.