PHP remote code execution vulnerabilities and the early leak of their IDs

PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October, fixing two vulnerabilities, CVE-2026-109618 and CVE-2026-109619, which researchers and the media call php2shell. The php.net advisory says both may allow an attacker who is not logged in to execute code remotely on the server, that every PHP installation handling web requests is at risk, and that users should update immediately. According to W3Techs statistics for 21 October, 69.3% of websites whose server-side language is known use PHP. WordPress.org's announcement explains that this is not a vulnerability in WordPress itself and that no WordPress update will be released for it, since the PHP on the server is what needs updating.

According to a PHP Foundation blog post on 21 October, the two CVE IDs began circulating on forums and social media at around 15:00 UTC on 20 October (23:00 Taipei time). They came with a wrong release time and a wrong severity score (CVSS, out of 10) of 10.0, where PHP's own rating is 9.2, and no technical details leaked. At 19:30 UTC (03:30 on 21 October, Taipei time) PHP brought its pre-announcement forward and moved the release from 14:00 UTC on 22 October to 14:00 UTC on 21 October (22:00 Taipei time). It did not release at once because Linux distributions such as Debian, Ubuntu and Red Hat were still packaging the fix, and releasing immediately would have left many users without an easy way to update.

The same post says that after the pre-announcement, one of the security firms that had reported the vulnerabilities mistakenly published a demonstration video, and copies quickly spread on social media. In the post's account, the video was one of the reasons various parties sped up work on proofs of concept (PoCs, code showing that a vulnerability can be exploited). By the time of public release, the PHP security team had not found a working exploit among the PoCs in circulation.

Cloudflare's blog post of 21 October says it observed attack traffic aimed at its customers during the leak, and that matching WAF (web application firewall) rules have been enabled by default for free and paid customers since 03:02 UTC on 21 October (11:02 Taipei time). As of 16:30 US Eastern Time on 21 October (04:30 on 22 October, Taipei time), security firm Huntress had not observed exploitation on its partners' systems. After the fixed versions came out, Taiwan's TWCERT/CC (Taiwan Computer Emergency Response Team/Coordination Center) noted in an alert on 22 October that PoCs had appeared online.

Perspective

According to the PHP Foundation's post, both vulnerabilities sit in memory management and error handling, parts of PHP that nearly every request touches. The php.net advisory describes the first as occurring when memory use reaches its limit, at which point PHP may be interrupted while internal data is only partly initialised. A later clean-up step may then treat that data as valid.

The second involves internal state left behind by an earlier request, which may be used by a later request handled by the same worker process after its memory has been freed. The php.net advisory rates Apache with mod_php (a setup that loads PHP directly into the web server) as the highest risk, and an exploit has been demonstrated in which an unauthenticated request triggers the attack before the site's own code runs.

According to php2shell.com, an explainer site set up by the researchers, the flaws are in PHP itself, so even a securely written site can be affected, including a simple one that only prints "Hello World". Automattic, the company that runs WordPress.com, likewise explains that this is a fix to the runtime, and that updating WordPress, themes or plugins alone does not protect against it.

The PHP Foundation's post also looks at why the fix took so long. During an external security audit in 2024, PHP developers had already found early signs of the first vulnerability, though no path to remote code execution was known at the time. Each of the fixes considered then had a cost, whether breaking compatibility, opening up denial of service (making a site stop working normally) or requiring changes to many third-party extensions. The security team, which operates by consensus, struggled to choose, and the post calls the delay "a structural failure, caused by both the security team's decision process and its lack of resources."

The same post says AI-assisted vulnerability research has brought PHP far more reports than before. Since 1 July the security team has published 15 CVEs and handled more than 100 reports that were invalid, duplicates or could not be reproduced. The PHP Foundation is changing its process so that serious vulnerabilities stuck on hard trade-offs reach its leadership sooner.

Japan's Information-technology Promotion Agency (IPA) announced on 21 October when the fix would be published. That evening, according to ITmedia NEWS, Japan's prime minister urged organisations on X to prepare to apply it, adding that temporarily taking a website offline is one effective way to reduce the risk where patching is difficult.

According to a tally by the security blog piyolog, compiled from organisations' notices and news reports, 211 organisations in Japan had suspended services or announced emergency maintenance by just after 1 a.m. Japan time on 22 October (just after midnight Taipei time), including 2 national government bodies and 4 local governments. Sapporo took its official website offline on the evening of 21 October. As of 22 October, its temporary home page said no unauthorised access or tampering had been found and that the shutdown was a precaution.

On 22 October the Korea Internet & Security Agency (KISA) published guidance for companies, recommending that those unable to update or to apply interim settings consider blocking external access or temporarily suspending services. It also asks companies to check logs from at least 20 October onwards after updating, and recommends changing database passwords, API keys and administrator passwords on servers that were exposed to the internet before the update.

Taiwan's Administration for Cyber Security, under the Ministry of Digital Affairs, issued a press release the same day asking organisations to take stock of their PHP systems and patch them, without asking anyone to suspend services. As of 22 October we, a community based in Taiwan, found no notices of Taiwanese organisations going offline over these flaws, and no confirmed intrusions in Japan, South Korea or Taiwan.

We also compared the rules on disclosure timing in mainland China, Japan and Taiwan as of 8 October. What follows summarises each system, and we have not assessed how any of them would apply to this incident.

In mainland China, the Regulations on the Management of Network Product Security Vulnerabilities, in force since September 2021, apply to network product providers and operators in mainland China and to those who discover, collect or publish vulnerabilities. They require providers to report a vulnerability to a platform run by the Ministry of Industry and Information Technology (MIIT) within two days of discovering or learning of it. Anyone publishing vulnerability information may not do so before the provider offers a fix, and those who think early publication is necessary must consult the provider and report to MIIT and the Ministry of Public Security, which assess the case and publish. The regulations do not define whether open source maintainers count as providers, and we could not find whether they apply to maintainers of projects abroad or to researchers outside mainland China.

Under the 2026 edition of the guidelines for Japan's Information Security Early Warning Partnership, published on 1 October, IPA receives reports, and JPCERT/CC, the designated coordination body, contacts developers and arranges when information is published. The target, which is not a legal deadline, is 45 days after JPCERT/CC first tries to reach the developer, taking into account the time a fix needs, coordination with counterparts abroad, the risk of the information leaking and the risk of exploitation. For open source software, JPCERT/CC also notifies distributors and the developers of products that include it when necessary. IPA does not require reporters to keep the information secret, nor does it require developers to fix the flaw.

In Taiwan, TWCERT/CC's vulnerability disclosure policy (version 2.2, March 2025) says it publishes a report's basic details within 90 calendar days of confirming that the report is complete, though it may delay publication after assessing the impact. The full details go on its Taiwan Vulnerability Note (TVN) platform only after the reporter, TWCERT/CC and the vendor all confirm that a fix or mitigation is in place. The policy does not say whether it covers open source projects based abroad, and we did not check reporting obligations under Taiwan's laws such as the Cyber Security Management Act.

Organisations often build their websites and blogs on PHP software such as WordPress. According to Automattic, sites on its own managed services such as WordPress.com are already protected, and their administrators do not need to change any settings. WordPress.org's announcement advises people on hosted plans to check with their host about the update, and notes that the PHP version is shown in the dashboard under "Tools > Site Health > Info > Server" (in the English interface). That version number can be compared with the fixed versions above, but it can mislead when a distribution backports the fix, as the next paragraph explains.

People who run their own servers and installed PHP from distribution packages should check their distribution's security advisories. Some distributions backport the fix to the original version, so comparing only the PHP version number can mislead; Ubuntu 24.04's fixed package, for example, is 8.3.6-0ubuntu0.24.04.13. Red Hat's advisory of 21 October says Red Hat Enterprise Linux uses PHP-FPM (which runs PHP in separate processes) by default, making exploitation harder, and that some updates were still being prepared. The PHP Foundation's post, for its part, says the first vulnerability has also been confirmed to allow remote code execution on PHP-FPM through the site's own request handling.

According to php.net's supported versions page, PHP 8.1 and earlier have reached end of life, and 8.2 reaches end of life on 31 December 2026. For this release PHP also provided minimal source patches for 7.4, 8.0 and 8.1 for people who compile PHP themselves, but none for 7.3 or earlier. TWCERT/CC's alert lists affected versions from 5.4 onwards. For those who cannot update yet, php.net lists several configuration changes that narrow some attack paths, while warning that only updating fully resolves the problem.

Whether either vulnerability turns out to have been used in confirmed intrusions, whether they are added to the Known Exploited Vulnerabilities catalog of the US Cybersecurity and Infrastructure Security Agency (CISA), and whether Red Hat and other distributions complete their updates are the things to watch next.