PHP2Shell (CVE-2026-109618, CVE-2026-109619) — unauthenticated PHP RCE

This tracker is no longer updated. Every tracked Debian suite, NixOS channel, nixpkgs branch, and pkgsrc branch ships the fixes for every PHP branch it carries; nixpkgs’ unstable channels dropped PHP 8.2 rather than update it, so php82 hosts there move to a newer branch.

Summary

PHP2Shell is the name the two vulnerabilities picked up after the leak. Both live in PHP’s own request handling, below any framework or application. CVE-2026-109618 needs nothing from the application at all: on mod_php, the multipart body parsing that runs before any script starts is enough.

⚠️ Updating is the only complete fix. PHP’s advisories say so for both CVEs. The configuration changes under Mitigation narrow the confirmed attack paths but leave others open. Each branch has its own fixed release: a host on PHP 8.4 needs 8.4.27, not 8.5.12.

The vulnerabilities

Both advisories credit the same four reporters (lcfr-hax, sagitzadik-wiz, tomash-areion, amyb-oai). The fix, in the ChangeLog as “Avoid state corruption via bailout”, is one Core change in all four releases. 8.3.36 and 8.2.35 contain nothing else. 8.5.12 and 8.4.27 also carry their branches’ regular bug fixes.

CVE-2026-109618 — OOM corruption

PHP aborts a request that runs out of memory by longjmp()-ing out of whatever it was doing. Some code makes request memory reachable before it is fully initialised, and an allocation failure at that point leaves it invalid for request shutdown to read.

An attacker can reach the memory limit while staying inside PHP’s apparent request limits, through multipart parsing:

• a multipart body without a usable declared length, which passes the post_max_size check and keeps supplying data
• an unbounded number of headers in a multipart part, far larger in memory than on the wire
• empty file controls, which don’t count towards max_file_uploads, with nested field names multiplying the work

CVE-2026-109619 — stale global state

PHP keeps error, session, object, and extension state in worker globals. A fatal error — including running out of memory, or Maximum execution time exceeded — can abandon an operation before it resets that state, and a warning during shutdown can repopulate it after it was cleared, leaving it pointing into the request heap after it is freed. A later request on the same worker then uses it before its own initialisation replaces it.

The advisory confirms two such early consumers:

• INI diagnostics before request start — a warning or deprecation from per-directory settings (.htaccess, Apache php_value, or PHP_VALUE sent by a FastCGI frontend). Silencing it with error_reporting, @, or display_errors does not help.
• Session upload progress — enabled by default, and reached without the application calling session_start().

On PHP 8.5, fatal_error_backtraces — on by default — supplies the producer behind the confirmed mod_php exploit.

Who is exposed

PHP’s advisory names every installation serving web requests as at risk, including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. What has been demonstrated differs by SAPI:

• Apache mod_php — confirmed RCE for both, CVE-2026-109618 with default PHP input and memory limits, before any application code runs. PHP rates the risk highest here.
• PHP-FPM — CVE-2026-109619 validated through session upload progress after an application-level fatal error. CVE-2026-109618 is susceptible by source analysis, but no complete FPM exploit has been shown.
• FrankenPHP — likely susceptible to CVE-2026-109618, as it runs request shutdown unconditionally like mod_php.
• LiteSpeed (LSAPI) — modelled on FPM, so CVE-2026-109618 exploits are likely application-specific; a conditional candidate for CVE-2026-109619, as it can apply environment INI values early.

Patch status

A row is Fixed once its package carries its PHP branch’s 2026-10-21 release or later, or a backport of the fix. Current version is what the release ships today; First fixed is the first build that closed both CVEs. Where a release offers several PHP branches, the one its unversioned php selects is marked default. Debian versions are the apt-installable value, from the <suite>-security archive where it carries the package.

PHP

PHP supports four branches, each with its own fixed release. 8.4 and 8.5 are in active support; 8.2 and 8.3 receive security fixes only.

PHP 8.1 and every older branch are past end of life. They are just as vulnerable — the exploit tool shown in the leak claims every release since 5.4.0 — and get no new releases. Given the severity, PHP published minimal source backports for 7.4, 8.0, and 8.1 for those building from source; otherwise a host needs a vendor that backports the fix, or a supported branch.

Debian

Debian ships one PHP branch per release, as a versioned source package: php8.2 in bookworm, php8.4 in trixie, forky, and sid. The unversioned php, php-cli, and php-fpm packages come from php-defaults and only pull in the branch’s packages, so look at the php8.X-* packages for the PHP release a host runs.

Debian’s PHP maintainer normally imports each upstream point release, security uploads to the stable suites included. Bookworm is in its LTS period, so its PHP updates come as DLAs from the LTS team, into bookworm-security.

pkgsrc

pkgsrc (NetBSD’s package collection, also used on SmartOS, macOS via pkgin, and elsewhere) packages every PHP branch side by side as lang/php82 through lang/php85; the installed package is named after the branch (php84-8.4.26). PHP_VERSION_DEFAULT selects the branch PHP-dependent packages build against — 8.4 on both tracked branches.

pkgsrc-2026Q3 is the quarterly branch most pkgsrc hosts run; it takes fixes from pkgsrc-current by pullup. An nbN suffix comes from the package’s PKGREVISION, which bumps for many reasons besides security patches, so on its own it says nothing about this fix.

NixOS

nixpkgs builds every branch from one expression, pkgs/development/interpreters/php/default.nix, as the attributes php82 through php85. The unversioned php is php85 on unstable and php84 on 26.05. The NixOS services.phpfpm module uses pkgs.php unless a pool sets its own phpPackage.

PHP 8.2 was removed from master on 2026-10-21 without taking the 8.2.35 update, and the removal reached every unstable channel before the fix did: master, nixos-unstable, nixos-unstable-small, and nixpkgs-unstable carry no php82. A host on php82 from unstable has no fix and has to move to a newer branch. php82 remains available — and fixed — on release-26.05 and its NixOS channels.

Flake users

A flake input like github:NixOS/nixpkgs/nixos-unstable resolves to the git branch of that name, which the channel bot advances to exactly the revision the channel publishes, so an input following a channel name is answered by that channel’s rows.

Two branches have no channel gating them and carried the fix earlier — they are listed above as master and release-26.05:

• github:NixOS/nixpkgs/master — the fix’s first appearance anywhere in nixpkgs, the moment it is merged.
• github:NixOS/nixpkgs/release-26.05 — the ungated 26.05 branch, ahead of the nixos-26.05 channel by however long Hydra takes.

Detection

Check the installed package rather than the running interpreter: a host can carry several PHP branches, and the web server’s may not be the one on PATH. Both bugs are exploited through the web server’s PHP, so check that one first.

Debian

List the PHP packages dpkg knows about, with their state and version:

dpkg-query -W -f='${db:Status-Abbrev} ${Package} ${Version}\n' 'php8*'

Lines starting ii are installed. The branch is in the package name (php8.4-fpm) and the upstream PHP release is the version up to the last -. Compare it with the row for your suite above.

pkgsrc

pkg_info -e 'php8[0-9]-[0-9]*'

The output is php<branch>-<version> plus any nb<PKGREVISION> suffix — for example php84-8.4.26nb2. Cross-reference it against the pkgsrc rows above.

NixOS

Query the PHP versions in the current system closure:

nix-store -q --requisites /run/current-system | grep -- '-php-[0-9]'

Each store path ends in the PHP version it builds (php-8.4.26, or php-8.4.26-dev for the development output). Cross-reference against your channel’s rows above; a project built from a flake or a nix-shell carries its own PHP, pinned by its own nixpkgs input.

Which SAPI serves PHP

Apache with mod_php carries the highest risk, but PHP-FPM is exposed too, so a host without mod_php still needs the update. On Debian, a2query -m lists the enabled Apache modules; a php8.X module there means mod_php:

a2query -m

Mitigation

Upgrade to your branch’s fixed release — or to a distribution package that carries it — as soon as one is available. None of the following is a complete fix; PHP’s advisories list them as ways to narrow the confirmed attack paths until the update is installed.

• Disable session upload progress. Set session.upload_progress.enabled=0 administratively and restart every worker. It closes the confirmed session path of CVE-2026-109619 on both mod_php and FPM, and the advisory suggests keeping it off after updating if unused.
• PHP 8.5: disable fatal error backtraces. Set fatal_error_backtraces=0 administratively and restart every worker. This removes the producer behind the confirmed CVE-2026-109619 RCE on mod_php.
• Remove the predictable memory limit. Setting memory_limit=-1 administratively removes the controllable out-of-memory condition the confirmed CVE-2026-109618 exploit uses. Check that no pool, directory, or application setting restores a finite limit. Do not use RLIMIT_AS or RLIMIT_DATA instead — they make allocations fail, which triggers the vulnerable path.
• Shrink the request limits. Set a low post_max_size — PHP suggests 8M without file uploads, 32M with them, with upload_max_filesize below it — and reduce max_input_nesting_level. An application that takes no multipart/form-data can have the frontend reject that content type outright.
• Bound requests at the frontend. Limit decoded body size, input fields, multipart parts, headers, and nesting depth, including for requests without a usable Content-Length.
• Avoid per-request INI diagnostics. Remove obsolete or invalid directives from .htaccess, Apache php_value/php_flag, and any PHP_VALUE/PHP_ADMIN_VALUE a FastCGI frontend sends; prefer php.ini or FPM pool settings, which apply at startup.

“Administratively” means where applications can’t override it: php.ini, php_admin_value/php_admin_flag in each FPM pool or the Apache configuration — not ini_set() or an FPM .user.ini. pm.max_requests=1 stops a worker from serving the second request CVE-2026-109619 needs, at a performance cost.

A web application firewall in front of PHP — Cloudflare has deployed managed rules — helps only if the origin accepts no traffic that bypasses it.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the advisory, repository index, or git reference that established each fact — so any row can be audited or reproduced. Most readers never need it.

References