23 OCT 2026 — The PHP project shipped emergency releases on 21 October for two critical flaws that let an attacker run commands on a web server without logging in first, and at least one attacker appears to have been trying them out four days earlier. Amazon Threat Intelligence says its honeypots recorded an exploitation attempt on 17 October, while the bugs were still under embargo. Singapore's Cyber Security Agency (CSA) issued an alert the same day as the fix, telling organisations to patch immediately.
The fixed versions, in ascending order, are PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12. The two bugs, CVE-2026-109618 and CVE-2026-109619, are known collectively as PHP2Shell, and the PHP project rates each at 9.2 on version 4.0 of the Common Vulnerability Scoring System.
What the two flaws do
According to the project's security advisory, CVE-2026-109618 fires when a request exhausts PHP's memory while some internal data is still half built. The cleanup routine at the end of the request can then trust that broken data. CVE-2026-109619 involves internal state that outlives the memory behind it, so a later request served by the same worker can act on stale pointers.
Any PHP setup handling web traffic is exposed, the project says, from PHP-FPM and php-cgi to FrankenPHP, LiteSpeed and Apache's mod_php, with mod_php at the highest risk. On that setup, the first flaw's technical advisory says full remote code execution was validated over HTTP with default memory and input limits, before any application code had started.
An embargo that broke two days early
The release was planned for 22 October. The PHP Foundation, which funds much of the project's security work, gives the sequence in a blog post published on release day. At around 15:00 UTC on 20 October the two CVE numbers began circulating on forums and social media, attached to the wrong release time and a wrong score of 10.0. The project posted a pre-announcement that evening and pulled the release forward by a day, to 14:00 UTC on 21 October.
A firm that had reported the bugs then mistakenly posted a video of its proof of concept hitting several targets, the foundation says. Copies outlived the deletion and sped up public exploit writing. It adds that one distributor shipped patched builds over six hours ahead of the agreed time, letting anyone study the fix early. Even so, it says its team "did not identify any functional exploits at the time of release/public disclosure".
Exploit attempts before the patch
Amazon's account goes further back. In a post signed by CJ Moses, chief information security officer of Amazon Integrated Security, the company says its MadPot honeypot network caught an attempt on 17 October from an IP address linked to a commercial anonymisation service. It says "it remains unclear how the actor acquired exploit information prior to disclosure". More attempts from other anonymised infrastructure followed between 02:00 and 08:00 UTC on 21 October, with payloads varied enough to suggest several actors.
Amazon says its analysis is ongoing and it does not know whether any attempt would have worked on a real system. Its advice to defenders is blunter: investigate from 17 October onwards.
watchTowr, a security firm, says its honeypot network saw both flaws exploited in the wild on 21 October. Palo Alto Networks' Unit 42 research team wrote in a threat brief that it had seen proof-of-concept code and that at least one European government had taken its website offline as a precaution. Neither names a confirmed victim, and the 22.6 million figure is Palo Alto's count of exposed instances that may be vulnerable, not of systems known to be breached.
What CSA and the NCSC advise
CSA's alert, dated 21 October and updated on 22 October, says all versions of PHP are affected. "There have been reports of widespread exploitation attempts targeting these vulnerabilities," it adds, along with several proof-of-concept exploits. The agency tells organisations to find every system running PHP, put internet-facing ones first, and check web servers where a third-party component may have installed PHP, even if their main website does not use it.
The UK's National Cyber Security Centre went a step further in its own alert on 21 October. Where a system cannot be updated or mitigated quickly, it says operators should consider taking it offline, and should look for evidence of compromise and attacker backdoors before upgrading.
Patching and the stopgaps
Updating is the only complete fix. The release notes for each version say so in plain terms: "There are no complete mitigations, updating is the only safe choice." Linux distributions received the patches in advance, so most administrators will get them as routine package updates.
Versions 8.1 and below are out of support, but given the severity the project has posted minimal source backports for 7.4, 8.0 and 8.1. Support for 8.2 ends on 31 December 2026. For anyone who cannot update at once, the advisory lists partial measures, including setting memory_limit to -1 and turning off session upload progress. It warns that these only narrow specific attack paths and do not make a server safe.
A bug first spotted in 2024
The foundation's post is frank about why the first flaw took so long. A PHP core developer found the first signs of the out-of-memory problem in 2024 while fixing an issue from an external audit by Quarkslab. No route to code execution was known then, and the security team struggled to choose between competing fixes. The work stalled and restarted for months. "We won't pretend otherwise: the delay was a structural failure, caused by both the security team's decision process and its lack of resources," the foundation writes.
That changed in August 2026. A researcher at the security firm Calif reported an unconditional remote code execution bug with the same root cause on 11 August, and further attack routes came from Wiz on 24 August and OpenAI on 18 September. The team is now moving to majority decisions, the foundation says.
View author profile → · Editorial policy
