Two critical PHP vulnerabilities knocked large parts of the German internet offline for a while on October 21, and even the evening news covered it. The flaws themselves are not the most interesting part. The case shows how little time may be left between a security update and its exploitation, especially now that AI helps with the analysis. For poorly maintained software, that is becoming a real problem.
What happened on October 21
Government agencies, universities, hospitals and companies took their systems offline as a precaution, and even the portal of Germany's BSI was affected for a time. The cause was CVE-2026-109618 and CVE-2026-109619 in PHP. Under certain conditions, they allow arbitrary code execution on the server without any login.
Memory bugs, use-after-free and remote code execution have been around for decades, and so have critical flaws in widely used software. What is new is the speed at which vulnerabilities can now be analyzed and exploited.
A known bug turns into an emergency
The backstory goes back to 2024. After an external audit, a PHP developer found signs of a memory management bug. It looked exploitable, but nobody could prove it. The fix stalled: the proposed solutions had drawbacks for compatibility and stability, and experienced developers were busy elsewhere. The PHP Foundation itself now calls the delay a structural failure.
Priorities changed overnight once Calif, OpenAI and Wiz, among others, used AI to demonstrate concrete attack paths in August 2026. The updates shipped on October 21. The lesson: no known working exploit does not mean no exploit exists. It only means you have not seen one yet.
Coordinated disclosure, with hiccups
Coordination between security researchers, PHP developers, distributors and infrastructure operators went remarkably well at first. Cloudflare was able to switch on protections before the release. Then the first details leaked on October 20, and the PHP team moved the planned release from October 22 up to October 21.
On top of that, an exploit video was published by accident, and fixed container images were available before the embargo ended. Attackers could study the changes before the official updates were widely available. Amazon says it saw an exploitation attempt in its honeypots as early as October 17. How the attackers got their information is unknown.
The patch as a roadmap
AI cuts both ways, as usual. The Wiz researchers describe how a single person, with AI help, did in about a week what used to take a team of specialists months. Treat claims like that with caution, but the direction is clear.
As soon as an update ships, attackers can compare the new version with the old one. This patch diffing is nothing new, and the patch essentially shows where to look. Until now, turning that into a reliable exploit took a lot of experience and time, especially for complex memory bugs. In the near future, attackers with little expertise might manage it quickly and roll it out at scale. That makes the job easier for attackers and the clock much tighter for defenders.
When half the internet goes into maintenance mode
Measurements by UptimeRobot show that the number of unreachable .de websites it monitors rose by about 113 percent between October 20 and 21. At European measurement points, downtime alerts peaked at roughly twenty times the usual level. Not all of those outages were caused by PHP2Shell.
State administrations, municipalities, universities and hospitals pulled services offline. The invoicing software provider easybill shut down both its application and its website. At the hosting provider D&T Internet, older applications partly blocked quick updates, so systems had to be moved to other servers. The economic impact is considerable: shops lose orders, cloud applications are unavailable, and public bodies cannot offer digital services.
In many cases shutting down was the right call, not least because the official updates only became available on October 21. Still, it is a bad sign when parts of our infrastructure can only choose between running with serious risk and going dark.
Legacy comes back to bite
Poorly maintained software stays poorly maintained software. For years, applications have been running on outdated PHP versions, relying on unsupported libraries, or coming from vendors that stopped shipping updates long ago. People like to call them legacy applications: business critical, so they stay online, but no longer maintainable.
The reasons are familiar. An update might break features, a migration costs money, the original developers are gone, and nobody wants to own a bigger change. So the update gets postponed, and then postponed again. The patch gap grows and the application becomes even harder to maintain. As long as nothing happens, this strategy even seems to work.
Déjà vu: ProxyLogon
In March 2021, four critical flaws in Microsoft Exchange made headlines as ProxyLogon. Microsoft shipped out-of-band updates after the Hafnium group had already exploited the flaws. Back then, too, the evening news and the papers picked it up.
The BSI spoke of tens of thousands of vulnerable Exchange servers in Germany and wrote directly to more than 9,000 companies. A spot check a little under a week after patch day found that half of the servers examined, all belonging to organizations with more than 1,000 employees, were still unpatched. Whether things look better today is doubtful.
Hafnium and PHP2Shell are not the same story: the Exchange flaws were exploited successfully before the updates came out. The parallel lies in operations, because the patching process is broken in many places.
So what now?
In theory, the demands on IT operations have not changed. But the window for applying patches is shrinking fast. It is not enough to park responsibility for updates somewhere in the IT department. Companies need to know which systems are business critical, which software components they depend on, and what happens if those have to be shut down overnight. That takes working information security management and business continuity management.
AI will also help defenders find flaws, test fixes and roll them out quickly. The takeaway is still simple: in 2021 the warning was called Hafnium, in 2026 it is called PHP2Shell. Not patching is not an option.