What happened

PHP released 8.5.12, 8.4.27, 8.3.36 and 8.2.35 on 21 October 2026 to fix two critical vulnerabilities in the PHP engine, together called PHP2Shell. Both can let an unauthenticated attacker run code on a server. This is a vulnerability story: the sources do not report that PHP's infrastructure or any release was breached. Both are rated 9.2 on CVSS v4.0.

One flaw comes from out-of-memory handling, which can leave half-built request data that cleanup code treats as valid. The other lets request state outlive its freed memory, so a later request on the same worker can use it. PHP says risk is highest with Apache mod_php, where an attack can run before any application code.

The PHP Foundation says the out-of-memory problem was first noticed in a 2024 audit, but the fix stalled. Calif reported a working remote code execution in August 2026, and OpenAI and Wiz also reported related issues.

The disclosure leaked early. According to the PHP Foundation, the CVE IDs circulated online on 20 October, Calif mistakenly posted a proof-of-concept video, and Chainguard published patched images before the embargo lifted. PHP moved the release forward a day.

AWS says its honeypots saw an exploitation attempt on 17 October, four days before disclosure, and more attempts after release. AWS says it is unclear how the actor got exploit information. watchTowr also reports exploitation in the wild since 21 October.

Timeline

  1. Calif reported a remote code execution exploit that shares the out-of-memory flaw's root cause.[4]

  2. AWS saw a PHP2Shell exploitation attempt in its MadPot honeypot telemetry, four days before disclosure.[6]

  3. Both CVE IDs started appearing on forums and social media, with a wrong score and release time.[4]

  4. PHP security team announced a security release for the following day.[7]

  5. Calif published a proof-of-concept video, later deleted; copies circulated.[7]

  6. Chainguard published built images containing the fix, breaking the embargo.[4]

  7. The fixed releases were announced on php.net, followed a minute later by the GitHub advisories.[7]

Who is affected

  • Internet-facing servers running PHP are the high-risk case. The sources name PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed; mod_php is the highest risk.
  • Older branches are affected too. PHP 8.1 and older get no official releases, only minimal source backports for 7.4, 8.0 and 8.1.
  • For most developer Macs the risk is medium rather than high. It matters when a PHP you run accepts requests from other machines, such as a local server reachable from your network, a published Docker port, or a server you deploy to.
  • Products that embed PHP as a backend can also be affected even if they do not expose PHP directly.

How to check

  1. Check the version of every PHP install on your Mac and compare it with the fixed releases: 8.5.12, 8.4.27, 8.3.36 or 8.2.35.
  2. Check PHP-based Docker images and running containers; a container keeps its old PHP until it is rebuilt and recreated.
  3. Check whether any local PHP server listens on all network interfaces rather than only on the Mac itself.
  4. A Mac is not expected to show any indicator of compromise. For servers, AWS suggests reviewing web logs, looking for unexpected process execution or file changes, and investigating from at least 17 October.
  5. AWS's published IP addresses include shared anonymization infrastructure; its advice is to investigate them, not simply block them.

What to do

  1. Update every PHP install to the fixed release for its branch and restart all PHP workers so the fix takes effect.
  2. Rebuild Docker images on fixed PHP versions rather than relying on images pulled before the release.
  3. On PHP 8.1 or older, use a vendor package or PHP's source backports, or upgrade to a supported branch.
  4. If a server cannot be updated at once, PHP lists partial mitigations, but none is complete; restrict internet access to that system until it is patched.
  5. Check your Linux distribution or LTS vendor for updated packages if you deploy to servers.

Affected packages

The package versions named in this report.

EcosystemPackageVersions
PHPphp8.5 before 8.5.128.4 before 8.4.278.3 before 8.3.368.2 before 8.2.358.1 and older

Indicators of compromise

Shown defanged so they can't be clicked. Copy copies the real value. Every indicator appears in the cited source.

TypeIndicatorNoteCopy
IP address103[.]216[.]220[.]92Observed exploitation attempt IP, dated 10/17/2026[6]
IP address31[.]223[.]184[.]166Observed exploitation IP, dated 10/21/2026[6]
IP address37[.]19[.]200[.]5Observed exploitation IP, dated 10/21/2026[6]
IP address134[.]209[.]159[.]64Observed exploitation IP, dated 10/21/2026[6]
IP address103[.]114[.]163[.]188Observed exploitation IP, dated 10/21/2026[6]
IP address95[.]217[.]98[.]37Observed exploitation IP, dated 10/21/2026[6]

Sources

  1. github.com · RCE via OOM corruption
  2. github.com · RCE via stale global state
  5. cert.europa.eu · Critical Vulnerabilities in PHP
  7. scherzer.dev · PHP2Shell: a Timeline

Changelog

  1. First published.