PHP2Shell: the long road to the web’s emergency patch

Emergency updates to PHP sent website operators looking for vulnerable servers around the world. Behind the disruption lies a longer story: warning signs from an earlier audit, difficult engineering choices, and new research that turned a suspected weakness into a demonstrable attack.

ICANN took three of its administrative websites offline in October while it prepared to patch the software they ran on. The organisation, which helps coordinate the internet’s naming system, reported no indication that its systems had been adversely affected. By 22 October, it had applied and tested a patch and restored the sites. 1

The Netherlands’ National Cyber Security Centre had also temporarily disabled its own website. Other organisations, including government agencies, took similar precautions. The disruption illustrated the uncomfortable choice facing operators: leave a service available while a serious weakness remained, or interrupt it to reduce the risk. 8

The cause was PHP2Shell, the name given to two critical vulnerabilities in PHP, a programming language and the software engine that runs it. Emergency security releases arrived on 21 October 2026. Under exploitable conditions, the flaws could allow someone without a login to make a web server execute their code. 2

The sudden public alarm followed months of work behind the scenes. PHP’s reach turned a difficult engineering repair into a much wider coordination problem.

The software beneath the page

Much of a website’s work happens before a page reaches the browser. PHP can process a submitted form, retrieve information from a database and generate the page that a visitor sees. The application supplies the instructions; the PHP runtime executes them on the server. A visitor may have no visible indication that PHP is involved. 12

Its origins were modest. In 1994, Rasmus Lerdorf created tools to track visits to his online résumé. He released their source code the following year, inviting others to use and improve them. Successive rewrites turned those tools into a language, with database connections and an expanding system of extensions helping it spread. 13

Today, PHP sits beneath familiar publishing systems including WordPress, Drupal and Joomla. Wiz’s researchers demonstrated PHP2Shell attacks against deployments of all three. The vulnerability lay in their shared engine, leaving even carefully written application code dependent on a faulty component. Repairing that engine meant updating server software, often through a hosting company or software supplier. 5 9

That shared dependency explains the scale of the response. On 24 October, W3Techs detected PHP on 69.3% of websites whose server-side programming language it could identify. The figure measures adoption within that survey, rather than the number of sites that were vulnerable, still unpatched or successfully attacked. 6

The failures concerned how PHP handles work that ends badly. In one, a request could exhaust memory while internal information was only partly prepared. PHP’s cleanup routines could then treat the unfinished information as valid. In the other, a server worker—the process handling visitors’ requests—could retain a reference to memory already released. A subsequent request could encounter that leftover reference. Carefully manipulating these conditions could turn an error into code execution with the worker account’s privileges. 3 4

How the original PHP2Shell pair could turn crafted web requests into code execution in a PHP worker. Onward access depends on existing permissions, credentials and network reachability—not automatic administrator access or execution inside the database engine. Conceptual illustration; the separate follow-up vulnerability is not shown. Credit: YachtByte explanatory diagram.

A warning that was difficult to resolve

An earlier security audit helps explain how the danger remained unresolved. Quarkslab examined PHP in 2024, in work organised through the Open Source Technology Improvement Fund. The published report left two findings’ details blank pending complex fixes. Its account of upload testing also recorded a constraint: setting up automated testing with large numbers of malformed inputs had proved too time-consuming for the audit. 14

Mihail Kirov, one of the auditors and now a researcher at Tolmo, revisited that work after PHP2Shell’s disclosure. His team had reliably caused a crash and pursued it as a way to disrupt service. Their test configuration terminated the failed process, he wrote; another configuration could leave it alive with damaged internal state. That difference helped conceal the more dangerous possibility. His retrospective is an account of the limits of that investigation, rather than evidence that a working takeover attack was known in 2024. 15

The PHP Foundation says a developer following up the audit identified the early signs of the memory-exhaustion problem. Possible fixes threatened compatibility, introduced other risks or required changes across third-party extensions. With no demonstrated route to remote code execution, competing work and too few specialists, progress repeatedly stalled. The Foundation called the delay a “structural failure” involving both resources and the security team’s consensus-based decisions. It says the team has since begun changing that process to allow majority decisions. 10

The evidence changed in August 2026. Calif’s chronology records its first report to PHP on 11 August, a working demonstration supplied on 14 August and confirmation from PHP the following day. A second report followed on 21 August. Researcher Ryan Austin describes using his knowledge of earlier PHP vulnerabilities to direct AI-assisted investigation towards places where an interrupted operation could leave dangerous state behind. 16

Wiz independently developed attacks and reported its findings. 11 Its researchers say AI models helped with the repeated analysis, testing and adaptation needed to make attacks work across different applications. That remains an account of their research, not a measurement of how easily any attacker could compromise any PHP site. Their experiments nevertheless showed that faults in the engine could produce practical attacks against widely used software. 5

The repair demanded sustained human work. Volker Dusch, who worked with PHP’s security team, told the German broadcaster WDR that a core team of four Foundation staff spent about two months on it. He described working 70–80 hours a week himself. The changes reached much further into the language than a typical small security fix, he said. 17

Getting a fix into the world

Producing corrected code was only part of the job. In an interview with Laravel News, Dusch described the delivery chain through Linux distributions such as Debian, Ubuntu and Red Hat, then container images and the further images built from them. Each layer could carry PHP into another service. The project’s release needed to reach the packages people actually installed. 18

OpenAI, which helped coordinate the response, says it worked with maintainers and research partners to test fixes, prepare guidance and involve infrastructure providers and government cyber agencies. PHP’s maintainers led the remediation and release. Advance notice gave other organisations time to prepare protections and updates before the full details became public. 11

The timetable then contracted. According to the PHP Foundation, the vulnerability identifiers began circulating on 20 October. The project moved its planned release forward from 22 to 21 October; distributors still packaging the fixes needed time to provide a usable update route. 10

There was already evidence of attempted exploitation. Amazon subsequently reported that its MadPot honeypot system, designed to observe hostile activity, had recorded an attempt on 17 October. More attempts followed around disclosure. Amazon said it was unclear whether those attempts would have succeeded against real-world systems or how the earlier actor had obtained the information. 7

By 23 October, the Dutch cyber centre had moderated its assessment: exploitation was complex, and large-scale exploitation appeared less likely than initially thought. It knew of one possible overseas exploit without confirmation of success. Its recommendation to install the updates promptly remained unchanged. The emerging evidence supported urgency, while falling short of establishing mass compromise. 8

Even the ordinary update path has a long tail. W3Techs’ snapshot still placed more than a third of PHP-using sites on version 7 or earlier. That does not reveal their individual patch status, but it shows how many older installations sit alongside the current generation. 6 Suppliers may carry security fixes into older packages, making their advice essential when a version number alone cannot settle the question. 2

For the people running websites, the remaining work extends beyond a download: finding PHP inside services and bundled products, obtaining the appropriate fix, and checking for suspicious activity that may predate it. Canada’s Cyber Centre explicitly includes third-party products, appliances and containers in that search. PHP2Shell’s reach follows those dependencies. The emergency patch has a release date; the work of getting it into every affected service has many different owners. 9

Technical note: the fixes and the remaining exception

For supported stable PHP branches, the first upstream releases fixing CVE-2026-109618 and CVE-2026-109619 were: 3 4

Distribution and long-term-support suppliers may backport fixes under different package numbers; check their guidance. 8 PHP considers Apache’s mod_php the highest-risk configuration, with an attack demonstrated before application code runs. Its update guidance also covers other web-serving configurations. 2

The emergency updates do not cover the separate CVE-2026-115560. 9 PHP’s 23 October notice describes an application configured with php_binary or php_serialize that switches to php at runtime before session_start(), while session upload progress remains enabled. PHP recommends session.upload_progress.enabled=0 pending the next regular bugfix release. Follow PHP’s implementation guidance: apply the setting in server/startup configuration so it takes effect before request parsing, then restart all workers. It does not replace patching the original pair. 2 4 Applications that never change that handler at runtime are not exposed to this particular route. Recheck the notice for a subsequent fix. 2

Sources

1. ICANN, ICANN Reacts to Widespread Software Vulnerability, 21 October; restoration update 22 October 2026.
2. PHP, 2026 news archive: security release and session-upload advisory, 21 and 23 October 2026.
3. PHP Security Team, RCE via OOM corruption, 21 October 2026.
4. PHP Security Team, RCE via stale global state, 21 October 2026.
5. Wiz Research, PHP2Shell research report, 21 October 2026.
6. W3Techs, Usage statistics of PHP for websites, snapshot dated 24 October 2026.
7. CJ Moses, AWS Security Blog, Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot, 21 October 2026.
8. NCSC-NL, Update: PHP vulnerabilities remain a reason for immediate patching, updated 23 October 2026, 15:45.
9. Canadian Centre for Cyber Security, Alert AL26-026, Update 1, updated 23 October 2026.
10. The PHP Foundation, Today’s PHP Security Release, and How We’re Strengthening PHP Security, 21 October 2026.
11. OpenAI, Patch the Planet: global response coordination as agents uncover critical vulnerabilities, 21 October 2026.
12. PHP manual, Introduction, accessed 24 October 2026.
13. PHP manual, History of PHP, accessed 24 October 2026.
14. Quarkslab, PHP Security Audit, report 24-07-1730-REP, version 1.4, 14 March 2025; pp. 37 and 52–53, upload-testing methodology and redacted findings.
15. Mihail Kirov, Tolmo, We can now find flaws faster than anyone can fix them, 22 October 2026; first-person account by a 2024 auditor.
16. Ryan Austin, Calif Research, A tale of two PHP remote vulnerabilities, October 2026 disclosure account; accessed 24 October 2026.
17. Fritz Sprengart, WDR, Wie ein Deutscher das Internet rettete, 22 October 2026; interview with Volker Dusch, paraphrased from German.
18. Eric L. Barnes, Laravel News, Volker Dusch on the PHP RCE Vulnerabilities and Disclosure, 23 October 2026; original interview report.