A worldwide cyber panic sparked by the discovery and disclosure of two critical vulnerabilities – dubbed PHP2Shell – in the core PHP code underpinning almost three quarters of the world’s websites has sparked widespread commentary and debate in the cyber security community after the disclosure process went horribly wrong.
As already reported, the AI-discovered flaws in the 32 year-old PHP server-side language enable unauthenticated threat actors to attain remote code execution (RCE) capabilities on affected servers given certain conditions.
An emergency patch dropped on Wednesday 21 October addressing both CVE-2026-109618 and CVE-2026-109619, but it has now emerged that thanks to a series of unfortunate events, the disclosure process ended up being somewhat botched.
The PHP Foundation said that work had been ongoing on disclosure since August, and this had been working well until the afternoon of Tuesday 20 October when the two CVE designations assigned to the vulnerabilities began to circulate online accompanied by misinformation about their planned release and severity.
This leak forced the Foundation to move up its timeline with the release moving forward by approximately 24 hours. As a result of this, cyber firm Calif, whose researchers first flagged one of the flaws and had been working on the coordinated disclosure process with the Fountaion, mistakenly released a video it had prepared showed a proof of concept in action and revealing some key details about the vulnerabilities. This quickly made its way to social media and accelerated the development of other exploits.
The Foundation added that mitigation advice given to critical infrastructure providers may also have leaked, but the final straw came when a company which had had early access to enable its users to immediately apply the patch released built images containing the fix
In a write-up of the incident, the Foundation accused Chainguard, an open source cyber specialist, of unilaterally breaking the embargo on PHP2Shell.
“Any attacker could now study the fix in binary form while every other PHP user was still waiting for the release. This disregarded weeks of work by many parties toward a coordinated disclosure,” wrote the Foundation.
Writing on LinkedIn, Chainguard CEO Dan Lorenc acknowledged the company’s role in the process. He said: “The PHP Foundation and maintainers did an amazing job here in a high stress situation. I’m sorry that my decision led to even more stress for them.”
Lorenc explained he took the decision to ship the patch early after noting spreading online gossip and coordinating with other researchers. “This decision was based on how easily we were able to independently discover the vulnerability and build an exploit, how much information was already out there on the coming vulnerabilities and fixes, and the evidence shared on active exploits in the wild,” he said.
Lorenc added: “We’re all on one team here, trying to minimise harm on end users from attacks…. We’re not always going to get it right, and not everyone is going to agree with our decisions, but that is always our goal. This is unfortunately the new normal for the industry.”
John Bruggeman, virtual chief information security officer (vCISO) at IT services house CBTS, described coordinated disclosure as a trust exercise. “The bad news is that this week someone let go of the rope.
“An embargo isn’t a formality. It’s the only mechanism the security community has for giving defenders a head start over attackers on something this widespread. It only works if every party holding early access treats ‘early’ as ‘early for patching,’ not ‘early for publishing’.
“One broken link, and the thing that was supposed to protect millions of PHP servers becomes the thing that tips attackers off faster,” said Bruggeman. “What this means for security leaders is that you need to be able to patch fast, sometimes faster than you’ve planned, even if you’re on the inside.”
Mind-boggling scale of disruption
In the UK, the PHP2Shell vulnerabilities are already known to have affected multiple central and local government bodies, which have been forced to pull services offline, as well as the BBC. Given the extent to which web services – particularly ecommerce operations – rely on PHP, thousands of other private sector organisations will inevitably be affected.
And the scale of the potential disruption is mind-boggling. According to figures provided by Qualys’ Threat Research Unit (TRU), there are hundreds of millions of PHP package installations in the wild, with almost three quarters of them on internet-facing assets leaving them within range of remote attackers.
To make matters worse, the available patches only cover versions 8.2 and newer of PHP, leaving millions of websites relying on older versions dangerously exposed, and dramatically widening the scope of the incident.
Thankfully, with the PHP2Shell incident having received extensive publicity, patching rates are thought to be increasingly rapidly, with a live tracker provided by UK-based cyber startup Infrawatch showing that as of approximately 20:20 UTC on Thursday 22 October, almost 140,000 visible PHP instances had been patched, rising at a rate of about 7,000 every hour.
However, according to Infrawatch this represents barely 6% (8.5% in the UK) of the publicly visible total, and as of late afternoon on Thursday 22 October, a surge in attempted exploitation of the two PHP flaws is being widely observed, and according to Amazon’s threat intel researchers, may have been ongoing since at least 17 October.
According to the PHP Foundation, the two flaws are particularly dangerous because they sit in parts of PHP – memory management and error handling – that virtually every request makes.
“Their central place in PHP is what made both vulnerabilities serious, and also so hard to fix without breaking compatibility, hurting performance, or forcing changes on the large ecosystem of third-party extensions,” said the Foundation.
The Foundation said CVE-2026-109618 arises from an out-of-memory corruption condition. Should a request reach PHP’s memory limit at the wrong moment it could leave partially initialised internal data behind and later assume it to be valid, corrupting the memory. In some circumstances, an unauthenticated request could trigger this situation before any application code runs, enabling RCE to take place.
CVE-2026-109691 arises from a stale global state condition. In this situation, a fatal error at an inopportune moment leaves internal state pointing to memory belonging to a previous request. If the same worker then handles a later request, it could then use that memory, leading to what is known as a use-after-free condition, and a crash, also enabling RCE.
For Sai Molige, senior manager of threat hunting at Forescout, the PHP2Shell incident has the potential to become an event on the same scale as the 2021 Log4Shell incident affecting the Apache Log4j library, but not for quite the same reason.
“With Log4j, the main problem was finding a library you didn’t know you had. With PHP, much of the forgotten infrastructure will be found, but won’t have an upstream fix,” he explained. “The durable lesson from Log4j is that organisations should treat ‘how quickly can we identify where we run X?’ as a measurable capability separate from patching speed.
“Discovering vulnerable infrastructure, however, is only the first step. When older systems have no available fix or depend on a vendor update, organisations need to reduce exposure, restrict unnecessary connections, and isolate affected systems while planning remediation.”
