Written by Julien Ricciarelli-Bonnal
24 October 2026
The Essentials
On October 21, 2026, the PHP project released emergency updates addressing two critical vulnerabilities discovered through research involving advanced artificial intelligence models. The flaws, collectively known as PHP2Shell, can under certain conditions allow attackers to execute code remotely on vulnerable servers. The announcement triggered an international security response, with some organisations temporarily taking services offline while preparing protections. Because PHP is used by approximately 70% of websites, the potential impact extends far beyond individual applications. The incident also raises a broader cybersecurity question: if AI accelerates vulnerability discovery, can software maintainers and organisations deploy reliable fixes quickly enough to stay ahead of attackers using similar capabilities?
For years, identifying serious vulnerabilities in widely used software has required specialised knowledge, extensive code analysis and considerable patience. Researchers investigate unusual behaviour, reproduce defects and determine whether an unexpected interaction between software components can become a practical security threat. Discovering a weakness is often only the beginning of a lengthy technical investigation.
The disclosure of two critical PHP vulnerabilities on October 21, 2026, illustrates how artificial intelligence is changing parts of that process. Researchers using advanced models helped establish the practical severity of weaknesses in one of the most widely deployed web programming languages. PHP’s maintainers, security providers and infrastructure companies then coordinated emergency updates and defensive measures.
The episode does not mean that every website using PHP became vulnerable, or that AI independently performed every stage of the investigation. Its significance lies in the changing relationship between the speed of finding exploitable weaknesses and the much more complicated task of protecting the systems that depend on them.
Two Vulnerabilities Inside PHP’s Core Engine
PHP is a server-side programming language used by content management systems, online stores and countless business applications. Estimates cited during the incident place its use at approximately 70% of websites. That figure describes the language’s prevalence, not the percentage of installations exposed to these particular vulnerabilities.
The two flaws, CVE-2026-109618 and CVE-2026-109619, both received critical severity ratings of 9.2 under CVSS version 4.0. They involve internal memory-management and error-handling mechanisms rather than an individual website feature. The first concerns memory corruption associated with an out-of-memory condition. The second involves internal state that can remain invalid after certain fatal errors, potentially allowing memory previously released by the system to be reused incorrectly.
Under specific conditions, these defects can create remote code execution opportunities without requiring an attacker to authenticate first. Successful exploitation could allow malicious instructions to run within the affected server environment, creating risks for applications and accessible data. The precise exposure depends on the PHP version, web server configuration and application execution paths.
The PHP project released fixed versions 8.2.35, 8.3.36, 8.4.27 and 8.5.12 on October 21. Developing those corrections was unusually difficult because the affected mechanisms are central to the language. A modification must eliminate the security flaw without unnecessarily breaking applications, changing expected behaviour or introducing new problems across a large ecosystem of extensions.
AI Accelerates Discovery but Does Not Replace Security Engineering
OpenAI’s involvement attracted considerable attention. Under its Patch the Planet initiative, cybersecurity company Calif identified a critical flaw using GPT-5.6 Sol. Wiz independently discovered and reported both vulnerabilities, also incorporating AI-assisted tools into its research. The contribution was therefore distributed among researchers, software maintainers and technology providers rather than originating from one autonomous system.
An important historical detail complicates the idea that AI discovered an entirely unknown problem. The PHP Foundation says signs of the underlying issue behind the first vulnerability had already emerged during security work in 2024. At the time, investigators had not established sufficiently concrete exploitation paths, and attempts to determine an acceptable correction became entangled in compatibility and resource constraints.
The research conducted in 2026 helped demonstrate why a previously difficult-to-characterise weakness represented a serious, exploitable risk. Advanced models can assist researchers in examining complex interactions, generating hypotheses and exploring unexpected execution paths. Tasks requiring extensive manual investigation may become faster when human expertise is combined with these capabilities.
Yet identifying an exploitable condition does not automatically produce a trustworthy patch. Maintainers must validate the finding, understand its root cause, assess affected configurations and test modifications against real software. The PHP Foundation emphasised that people continue to make the decisions and implement the fixes. AI can accelerate technical research without eliminating the responsibility or specialised judgement required to repair foundational software.
The Defender’s Advantage Can Disappear During Disclosure
Vulnerability disclosure requires more than deciding when to publish a technical report. Before revealing details, maintainers need time to prepare corrections, software distributors may need to package updates, and infrastructure providers must assess whether additional protections are required. The objective is to make defensive measures available before the information becomes useful to potential attackers.
OpenAI describes the period between AI-assisted discovery and public disclosure as a Defender’s Window. In the PHP case, participating researchers and security providers coordinated for weeks to prepare protections. But events immediately preceding the planned release illustrated how easily that window can narrow.
On October 20, vulnerability identifiers began circulating prematurely, accompanied by inaccurate information. A proof-of-concept video was also published by mistake. PHP’s maintainers moved the coordinated release forward from October 22 to October 21. The PHP Foundation subsequently criticised a distributor for publishing updated components before the agreed release time, potentially exposing information useful for reconstructing the vulnerability.
Once a patch becomes public, attackers can compare corrected software with previous versions to understand which behaviour changed. This technique, known as patch diffing, has long been part of vulnerability research. AI-assisted analysis may further accelerate the process, reducing the time between disclosure and the development of potential attack methods against systems that remain unpatched.
The threat should nevertheless be distinguished from confirmed successful attacks. By October 23, security companies had reported scanning, testing and attempted exploitation, while CrowdStrike stated that it had not observed successful exploitation in its monitoring environments. It also warned that turning available proofs of concept into reliable remote code execution was technically difficult. The seriousness of the vulnerabilities does not justify treating every attempted attack as a confirmed compromise.
The Hardest Part May Be Finding Every Vulnerable Installation
The international response demonstrated how deeply PHP is embedded in digital infrastructure. Government agencies, businesses and online services assessed their exposure, and some temporarily suspended operations while applying updates or other protective measures. These disruptions were not necessarily evidence of successful cyberattacks. Some reflected precautionary decisions made during an urgent security response.
For an organisation, the first obstacle may be knowing where the language is actually running. PHP can exist behind a corporate website, an e-commerce platform, a hosting control panel, an internal application or a legacy service maintained by an external contractor. Business leaders may know which application they purchased without knowing which programming language or runtime version supports it.
That distinction matters because affected versions and exploitable conditions vary. A website’s reliance on PHP alone does not establish that a particular attack will succeed. Security teams must identify installations, verify their versions and configurations, examine dependencies and follow official vendor or hosting-provider instructions. Interim web application firewall protections can reduce exposure, but they do not replace the underlying software correction.
This challenge is also organisational. When several departments and suppliers operate different parts of an information system, no single person may possess a complete picture of the software inventory. As previously explored in the difficulty of understanding what autonomous OpenAI agents have actually done, increasingly complex digital systems can create gaps between operational activity and the organisation’s ability to observe and control it. The technical circumstances differ, but the underlying need for clear oversight remains relevant.
Faster Discovery Exposes the Economics of Open-Source Maintenance
One of the most revealing aspects of the PHP incident is the difference between the economic importance of a technology and the resources available to maintain it. Open-source software can support millions of commercial services while depending on relatively small groups of specialists to review reports, investigate vulnerabilities and maintain compatibility.
The PHP Foundation acknowledged that work on the earlier weakness had stalled partly because of limited resources and difficulties reaching decisions about technically risky changes. It has since been modifying its security processes. At the same time, AI-assisted research is increasing the volume of vulnerability reports, including duplicates, false positives and findings that cannot be reproduced. More discoveries do not automatically mean that maintainers have the capacity to process them.
This creates a potential imbalance. AI systems may identify weaknesses faster than human teams can validate them, design repairs and coordinate updates. The bottleneck can move from finding problems to deciding which problems matter, which fixes are safe and how those fixes should reach the organisations using the software.
The response consequently requires more than better vulnerability-detection tools. Businesses need clear responsibility for software inventories, maintenance decisions, supplier coordination and emergency changes. The broader principles resemble those involved in AI business governance: technological capability becomes operationally valuable only when organisations establish responsibilities, priorities and adequate human oversight.
Patch the Planet represents an attempt to address that coordination problem by bringing together researchers, maintainers, security providers and public institutions. The initiative’s significance is not confined to the performance of any particular AI model. It recognises that discovering a serious weakness produces a defensive benefit only when the information can be translated into tested, distributed and deployed protection.
PHP2Shell does not establish that artificial intelligence will inevitably favour attackers or defenders. It demonstrates that both may increasingly have access to more powerful methods of analysing software. Discovery can accelerate, while the work of maintaining complex systems remains constrained by expertise, compatibility requirements and organisational resources. Finding a vulnerability before criminals exploit it creates an opportunity. Protecting the systems affected before that opportunity disappears is the much harder achievement.
Written by Julien Ricciarelli-Bonnal
24 October 2026
