AI-assisted security research has exposed critical vulnerabilities in software underpinning much of the internet. Within hours of public disclosure, exploitation attempts were escalating into the millions, prompting precautionary website shutdowns around the world. At the time of publication, Friday morning, 23 October 2026, organisations are still patching systems and restoring services. The PHP2Shell crisis reveals just how rapidly the cybersecurity response window is shrinking.

On Wednesday, 21 October, websites belonging to government departments, universities, hospitals and businesses began disappearing from the internet. Across Europe, services were temporarily suspended as administrators scrambled to protect their systems. By Thursday, the disruption had spread visibly to major organisations in Japan, including banks, airlines and railway operators.

For many users, the result was straightforward: websites that had worked the previous day were suddenly unavailable. Behind those precautionary shutdowns, however, was a security emergency developing at a speed that traditional software maintenance processes were struggling to match.

The cause was the discovery of two critical vulnerabilities in PHP, the programming language that powers a substantial proportion of the world’s websites and applications. Known collectively as PHP2Shell, the flaws could allow an unauthenticated attacker to execute malicious code on vulnerable web servers, potentially gaining control of systems and accessing sensitive information.

The vulnerabilities, identified as CVE-2026-109618 and CVE-2026-109619, were assigned critical severity ratings of 9.2 under CVSS v4.0. They affected fundamental parts of PHP’s memory management and error handling, rather than simply a particular website application or plugin.

What makes this incident especially significant, however, is the sequence of events leading up to the emergency.

A vulnerability years in the making

The underlying software weakness was recognised as early as 2024, during work following an external security audit of PHP. Developers understood that a problem existed, but establishing a practical route to exploitation proved difficult. Proposed fixes also presented significant technical challenges, including compatibility concerns and potential effects on third-party software.

In its statement following the emergency release, the PHP Foundation acknowledged that limited resources and difficulties in reaching decisions had delayed progress. It described the situation as a structural failure in its security processes. That changed in August 2026, when security researchers began demonstrating how the longstanding weakness could be exploited to execute code remotely.

Researchers at Calif (a California-based cybersecurity research company specialising in vulnerability discovery, penetration testing and AI-assisted security research) reported a working attack on 11 August, with OpenAI independently identifying the same underlying problem. Later that month, Wiz researchers used advanced AI models to develop and demonstrate additional exploitation techniques against widely deployed web platforms.

The implications were considerable. According to Wiz, AI-assisted analysis helped researchers navigate extremely complex combinations of software weaknesses, reducing work that might previously have required months of specialist effort to a matter of days or even hours. The vulnerabilities had been present in PHP for years. What changed was the practical ability to find, understand and exploit them.

From years to hours: the PHP2Shell timeline

Date	Development
2024	The underlying memory-management weakness is recognised during security work following an external PHP audit. Attempts to resolve it stall.
11 August 2026	Calif demonstrates remote code execution. OpenAI independently reports the same underlying problem.
19–24 August	Wiz discovers additional exploitable weaknesses using AI-assisted research, demonstrates attacks against popular web platforms and reports its findings.
17 October	Amazon threat intelligence detects an attempted PHP2Shell exploit, four days before public disclosure.
20 October	Vulnerability identifiers circulate prematurely. The PHP Foundation accelerates its planned security release by one day.
21 October	Defensive protections and emergency PHP patches are deployed. Websites are taken offline as a precaution, while exploitation attempts surge following disclosure.
22 October	Millions of attempted exploits have been reported. Organisations worldwide continue patching, investigating exposure and restoring services.

The timeline reveals two very different speeds of cybersecurity.

The work of understanding a difficult software problem, agreeing on a safe fix and distributing updates took months. Yet once information began escaping the coordinated disclosure process, attackers and defenders were operating on a timescale measured in hours.

Perhaps most concerning was Amazon’s discovery of an apparent exploitation attempt on 17 October, before the vulnerabilities had been publicly disclosed. The company could not establish how the actor had acquired the relevant information, but the observation demonstrates that a planned disclosure date can no longer be assumed to mark the beginning of exploitation.

When the attack window collapses

Cloudflare’s observations provide a remarkable illustration of what happened when the vulnerabilities became public. According to figures reported by Reuters on 22 October, Cloudflare recorded thousands of attempted exploits during the ten hours preceding public disclosure. In the first 45 minutes afterwards, that figure rose to tens of thousands. Within two hours, it had reached hundreds of thousands, before climbing into the millions.

Further evidence published on 22 October by Check Point Research suggests that the scale of attempted exploitation is extending well beyond the initial surge. The company reported that 10% of organisations in its global monitoring data had experienced PHP2Shell exploitation attempts, rising to 14% in Europe and 16% in Germany. These figures do not represent confirmed successful breaches, but they illustrate how quickly a newly disclosed vulnerability can become the focus of widespread automated attacks. For defenders, the question is increasingly whether protection can be deployed before an exploit reaches their systems.

These figures represent attempted exploitation, rather than confirmed successful intrusions. Nevertheless, they demonstrate how quickly information about a vulnerability can be translated into widespread attack activity.

The growing capabilities of AI add another dimension to this process. The same tools that allow security researchers to uncover previously inaccessible weaknesses can also help reduce the time and expertise required to develop attacks.

This does not establish that AI was used in the attacks observed during the PHP2Shell incident. It does, however, reveal why cybersecurity researchers are increasingly concerned about the shrinking interval between vulnerability disclosure and attempted exploitation.

Cloudflare had already deployed additional web application firewall protections ahead of the public announcement. Other security providers worked with PHP’s maintainers and researchers to prepare defences. Yet many organisations still faced the more difficult task of identifying vulnerable systems, applying updates and testing that their services would remain operational.

When switching off becomes the safest option

For website operators, the decision to take services offline was often a precaution rather than evidence of an actual compromise. Authorities including Britain’s National Cyber Security Centre advised organisations to prioritise immediate updates and consider disconnecting systems that could not be adequately protected.

The consequences were visible internationally. German public authorities, universities and hospitals temporarily suspended websites, while organisations in Japan, Finland, France and elsewhere restricted access to vulnerable services.

Finland’s government IT services provider warned that restoration could take days or even weeks because updates needed to be tested carefully before services could safely return.

There is an important distinction between a website that has been successfully attacked and one deliberately taken offline to prevent an attack. But for the people depending on those services, the immediate outcome can be similar: access disappears.

This creates a difficult operational calculation. Organisations must weigh the consequences of temporarily losing availability against the potentially greater damage of allowing an attacker to compromise their systems. And the time available to make that calculation is becoming increasingly limited.

What the experts says about the shrinking window

Speaking to German broadcaster SWR on 21 October, Professor Dr. Jörn Müller-Quade, a cryptographer at the Karlsruhe Institute of Technology (KIT) and spokesperson for KASTEL, the institute for information security and dependability, explained why the traditional response to software vulnerabilities is becoming increasingly difficult.

Previously, there was often a period between the disclosure of a vulnerability and the development of a working attack. Today, growing numbers of people can potentially use AI to assemble the necessary tools much more quickly, dramatically reducing that interval.

Müller-Quade argued that this was precisely why affected website operators could not simply wait for security updates. With exploitation potentially following disclosure so quickly, taking websites offline was the safer immediate option.

His observations point towards a wider change in cybersecurity. The assumption that defenders will have sufficient time to respond after a vulnerability becomes public is becoming less reliable.

And this is where the PHP2Shell incident becomes particularly relevant to the future of digital trust.

Digital trust at machine speed

For years, cybersecurity has relied on a combination of vulnerability research, responsible disclosure, software updates and operational response. Each stage has its own requirements, involving researchers, developers, infrastructure providers and the organisations ultimately responsible for deploying the technology.

AI is beginning to accelerate some of the most technically demanding elements of this process. It can help researchers identify obscure weaknesses, explore attack paths and validate potential exploits. Defenders can also use it to analyse reports, assess exposure and develop protections.

Yet other parts of the process remain fundamentally dependent on human expertise and organisational decisions. Complex patches must be engineered and tested. Compatibility must be considered. Legacy systems have to be maintained, and responsibility for deploying fixes has to be established.

The PHP Foundation’s admission about the long-running nature of the underlying problem is therefore particularly revealing. An issue identified years earlier became an international emergency once its exploitability was demonstrated and information began circulating more widely.

The resulting security response was substantial, involving software developers, cloud providers, cybersecurity researchers and national security agencies. It also demonstrated the limits of relying on emergency intervention once the threat becomes urgent.

For organisations operating critical digital services, the lesson extends beyond maintaining an up-to-date version of PHP.

They need to know where vulnerable components are deployed, understand how quickly they can respond, establish alternative protections and decide in advance when disconnecting a service becomes necessary. Software supply chains, maintenance arrangements and operational governance all become part of the same security question.

More fundamentally, the incident challenges the timescales around which many cybersecurity processes have been designed. A remediation policy measured in weeks may offer little protection against an attack that can be developed and deployed within hours.

The next vulnerability is already waiting

PHP2Shell provides a striking example of both the promise and the danger of AI-assisted cybersecurity. Researchers used advanced tools to demonstrate serious vulnerabilities that had remained unresolved for years, creating an opportunity for defenders to prepare fixes. But as the disclosure process came under pressure, exploitation attempts emerged before the public announcement and rapidly multiplied once the details became available.

The resulting shutdowns were largely preventive measures. They demonstrated organisations choosing to protect the integrity of their systems, even when doing so meant sacrificing availability. The deeper concern is what happens when the next major vulnerability leaves even less time to make that decision.

The PHP Foundation has also accused a security vendor of releasing patched software images before the coordinated embargo expired, highlighting how the urgency of protecting individual customers can create additional risks for the wider disclosure process.

Digital trust depends on systems remaining secure, available and reliable. Maintaining that trust will increasingly require defensive capabilities and decision-making processes that can keep pace with the speed at which vulnerabilities are discovered and exploited.

The clock has changed. Cybersecurity now has to change with it.

Sources and Further Reading

1. The PHP Foundation (21 October 2026) — Today’s PHP Security Release, and How We’re Strengthening PHP Security
   Official account of the vulnerabilities, their discovery, the disclosure timeline and the challenges of coordinating fixes.
2. Wiz Research (21 October 2026) — PHP2Shell: AI Uncovers Critical RCE Vulnerabilities Affecting 70% of the Internet
   Technical research explaining how AI-assisted vulnerability discovery exposed longstanding weaknesses in PHP.
3. OpenAI (21 October 2026) — Patch the Planet: Global Response Coordination as Agents Uncover Critical Vulnerabilities
   Details of AI-assisted security research involving Calif, OpenAI, Wiz and the coordinated disclosure process.
4. Amazon Threat Intelligence (21 October 2026) — Amazon Threat Intelligence Identifies PHP2Shell Exploitation Prior to Public Disclosure
   Evidence of exploitation attempts detected on 17 October, before the official disclosure.
5. Cloudflare (21 October 2026) — Cloudflare Deploys Protections Against PHP2Shell Vulnerability
   Explains the defensive measures deployed ahead of disclosure and the coordinated security response.
6. Reuters (22 October 2026) — Millions of Hacking Attempts as Companies, Governments Rush to Patch PHP Flaws
   International reporting on the rapid escalation of exploitation attempts, website shutdowns and disruption to services.
7. SWR / Tagesschau (updated 22 October 2026) — Das rät ein Experte Nutzern nach weltweiter IT-Sicherheitslücke
   Interview with Professor Dr. Jörn Müller-Quade of KIT/KASTEL discussing the vulnerabilities, their risks and the implications for website operators and users.
8. NHS England Digital (21 October 2026) — Critical Vulnerabilities in PHP (PHP2Shell)
   Official security advisory identifying the affected PHP versions, vulnerability severity and recommended remediation measures.
9. Check Point Research — PHP2Shell Update, 22 October
10. Computer Weekly — Disclosure controversy, 22 October