PHP2Shell (CVE-2026-109618, CVE-2026-109619): patch the PHP engine, not just your app

What happened

Wiz Research, working with Calif and OpenAI, reported two memory-safety flaws in the PHP engine to the PHP project in August 2026. PHP announced an out-of-band release on 20 October and shipped fixes on 21 October 2026 at 13:52 UTC. Technical details leaked before the coordinated disclosure (Recorded Future).

• CVE-2026-109618: an out-of-memory condition involving partially initialised request memory, plus a use-after-free in the session upload-progress unserializer. Wiz demonstrated unauthenticated remote code execution against WordPress, Drupal and Joomla.
• CVE-2026-109619: stale state where PHP globals point at freed request memory, a use-after-free in fatal-error backtraces, and a separate OPcache type confusion. Wiz demonstrated unauthenticated remote code execution against Drupal and WordPress.

Both are rated 9.2 under CVSS v4.0. Even without code execution, the memory disclosure can leak data from other users’ requests, including passwords, session tokens and API keys (Recorded Future).

Am I affected?

Affected versions are PHP 8.2 before 8.2.35, 8.3 before 8.3.36, 8.4 before 8.4.27, and 8.5 before 8.5.12. Branches 8.1 and older are past end of life and got no official release. PHP published minimal source backports for 7.4, 8.0 and 8.1, and some distributions and long-term-support vendors ship patched packages for them (Pentest-Tools).

Check every place PHP runs, not only your laptop:

# The PHP CLI version
php -v

# PHP-FPM can be a different binary from the CLI (the name varies by distro)
php-fpm -v 2>/dev/null || php-fpm8.3 -v

# Distribution packages: a backported fix often keeps the old upstream version number,
# so compare the full package version against your distro's security tracker
dpkg -l | grep -E '^ii\s+php'      # Debian, Ubuntu
rpm -qa | grep -i '^php'           # RHEL, Fedora, Amazon Linux

# Container images you build or deploy
docker run --rm --entrypoint php your-image:tag -v

What to do now

1. Upgrade PHP on every runtime: servers, base images, CI runners, and serverless or managed PHP hosting (check your provider’s status page).
2. Rebuild your containers. Pulling a new php:8.x tag does nothing for images you have already built. Rebuild from the patched base and redeploy. If you pin base images by digest, update the digest.
3. If you are on 8.1 or older, take your distribution’s or LTS vendor’s backport now and plan the move to a supported branch.
4. Stopgaps if you cannot patch today: restrict external access, put a web application firewall in front (Cloudflare deployed managed rules), and make sure the origin server cannot be reached directly, which would bypass the WAF. These reduce risk; they do not fix the bug.
5. Look for compromise. Attacks were reported before the fixed releases shipped: Patchstack reported active exploitation incidents from hosting partners by 07:34 UTC on 21 October (Recorded Future). Review web server, PHP-FPM and endpoint logs from 20 October 2026, and earlier if you can, for worker crashes, unusual requests and unexpected child processes. Application logs may show little, because the bug sits below your code. If you find signs of compromise, rotate every secret the application could read.

Reports conflict on how far exploitation went. PHP’s security team said it had not identified functional exploits at release, and the public proof-of-concept code has since been questioned by its own author (Pentest-Tools; Recorded Future). Patch anyway: the fix is cheap and the bug is unauthenticated.

Why this is part of the Vulnpocalypse

PHP2Shell is what the Vulnpocalypse looks like at ground level. A code path that has shipped, on by default, since PHP 5.4 in 2012 was found by an AI-assisted research team, leaked before disclosure, and attacked before the fix shipped. Government sites, including Australia’s cyber.gov.au, went offline while operators patched (iTWire). Wiz’s CTO told TechCrunch the Vulnpocalypse is “coming for the internet’s aging code” (TechCrunch).

The lesson for developers is about inventory. Teams that knew where PHP ran, and which of those hosts faced the internet, patched in hours. Teams that had to find out first lost days.

Sources

• Recorded Future Insikt Group: PHP2Shell exploitation
• Pentest-Tools: PHP2Shell, what it is, how to detect, how to patch
• iTWire: the 14-year-old bugs that pulled government sites offline
• TechCrunch: Wiz’s CTO on PHP2Shell and the coming Vulnpocalypse
• CVE-2026-109618 and CVE-2026-109619 on cve.org