The Cracked Shell of the Internet Turtle
PHP, the language that powers nearly 70% of websites worldwide, has officially become the talk of the month. Two critical vulnerabilities spanning multiple PHP releases were discovered via AI-assisted security research, and a large portion of the global Internet - including the dark web and a few of our own Helmholtz Cloud services - had briefly gone offline. The world and its numerous IT administrators held their breath for several hours until the patches were officially released on Oct 21st, at 14:00 UTC.
CVE-2026-109618 and CVE-2026-109619
The vulnerabilities, collectively referred to as PHP2Shell, target PHP’s memory handling.
When exploited, they allow an attacker to run malicious code on a vulnerable server to steal data, distribute malware, etc.
This is referred to as remote code execution (RCE), and it is one of the oldest and most dangerous types of vulnerability.
You may recall the chaos caused by the Log4j vulnerability several years ago; that was an RCE, too.
Both PHP2Shell vulnerabilities received a CVSS score of 9.2 out of 10, making them a critical and urgent problem.
There is an excellent writeup on the technical details and the discovery timeline by Calif, one of the companies that reported the original bugs to PHP.
Down memory lane
PHP and its extensions have a long history of memory issues. One of the first such bugs was unearthed as early as 2004, over two decades ago. PHP is a memory-unsafe language, meaning that there is no explicit mechanism preventing improper use of memory by software programs. Speaking of memory issues outside PHP: the earliest documented practical memory exploit dates back to 1988. It was part of the Morris worm, a self-replicating piece of software that unintentionally infected 10% of the Internet.
The PHP2Shell vulnerabilities are not completely new either: one of these had already been discovered in 2024. Back then, engineers found no proof that the bug could be exploited. However, two years later the situation had changed.
The quiet work
In 2026, security researchers unleashed their AI hounds on PHP again. This time they found a way to exploit the 2024 bug, and alerted PHP maintainers, following a coordinated vulnerability disclosure process. Engineers at the PHP Foundation started preparing security patches for all affected versions of PHP immediately. The security releases were scheduled to be published on October 22nd, at 14:00 UTC. Until then, an embargo - a prohibition - was imposed on publishing any information related to these vulnerabilities to limit possible exploitation attempts and buy defenders and maintainers time to fix the issue.
From August to mid-October, everything went as planned. Until it didn’t.
October 20th
At around 15:00 UTC, two CVE IDs (unique identifiers assigned to vulnerabilities) started appearing in various online forums and on social media, along with incorrect information about the security release date and severity score. No technical details appeared to be released.
At 19:30 UTC, in response to the brewing rumors, the PHP Foundation made a pre-announcement confirming the upcoming security release. The release date was moved from October 22nd to October 21st. The patches were still being prepared.
At around 20:00 UTC, Calif - one of the original vulnerability reporters - published a video with a demonstration of the PoC. Although the video was deleted later, the Internet Almighty remembers everything. The tension kept spiking, with the PHP Foundation alleging that screenshots of the video may have been used in the development of PoCs, though no definitive link had been established.
At around 23:00 UTC, PHP maintainers started giving early mitigation advice to few critical infrastructure providers.
In their later statement, the PHP Foundation suspected that mitigation advice may have leaked, too.
They started monitoring for possible PoCs - proof-of-concept scripts that could lead to real exploits.
Despite these hiccups, the situation was still under control, until…
October 21st, 07:41 UTC
The release of the official security updates was still more than six hours away when Chainguard, another cybersecurity company, released emergency patches ahead of time, unilaterally breaking the embargo. People at the PHP Foundation were, for the lack of a better word, not amused. The untimely release of the Chainguard patches created an opportunity for anyone to investigate them and discover the exact location of the vulnerable PHP code - still hours before the official release. The threat became real and tangible.
In the pre-AI world, this would have been an extremely undesirable and risky situation. In the AI-enabled world, where the development of exploits can take minutes, such an oversight may have catastrophic consequences. This is why multiple government cybersecurity agencies around the world urged website operators to take sites offline to prevent exploitation while waiting for the official security patches.
To disclose or not to disclose?
Embargoes and public disclosure mechanisms have been debated for years in the security community. According to Chainguard, the embargo offered poor protection in the case of PHP2Shell because knowing that the vulnerability exists was enough to find it via a simple AI prompt. Additionally, the company had been receiving reports of exploitation attempts in the real world. Given those circumstances, the company decided to publish the fixes.
This claim about exploitation attempts is somewhat supported by Amazon Threat Intelligence.
Amazon detected PHP2Shell exploits in its traffic as early as October 17th, five days before the planned security release.
However, it is unclear whether any such attempts were successful against real-world systems.
Nonetheless, given this timeline, Amazon strongly advises administrators to check for possible PHP2Shell intrusions as early as October 17th:
“An embargo protects defenders only until someone else finds the same bug.
Coordinated disclosure is still the right model.
But defenders should not assume the public disclosure date is the earliest date of exploitation.”
Conclusion
The PHP incident serves as a stark reminder that human decisions in cybersecurity matter enormously. Chainguard’s actions have sparked wide backlash within the security community - yet in other circumstances, early release of patches could have indeed been the right solution. This incident could have resulted in widespread exploitation of vulnerable web servers. Instead, the combined efforts of security researchers, agencies, companies and website administrators helped ensure that the threat was identified, addressed, and ultimately patched.
Even though attackers use AI capabilities to create exploits and find vulnerabilities faster, defenders are not merely waiting either. Through numerous security initiatives led by AI giants such as OpenAI and Anthropic, defenders use frontier models tailored for security research - and perhaps for the first time, their capabilities may match those of their adversaries. In the case of PHP2Shell, the vulnerability was discovered by security researchers - not attackers - using GPT-5.6 Sol as part of OpenAI’s Patch the Planet initiative. In 2024, PHP underwent a comprehensive security audit, and multiple security issues were subsequently identified and fixed. The defenders are patching the planet - one codebase at a time.
