PHP2Shell: Critical PHP RCE, Fixed Releases for 8.2 to 8.5 and Source Patches for 7.4 to 8.1

By Scott Bissett  ·  Published: October 22, 2026  ·  EOL Watch  ·  Affected versions, fixed releases and the end-of-life statement read twice on the day of publication from php.net's security advisory of October 21, 2026 (raw HTML and in a browser); branch dates from php.net's supported versions page, re-checked at every build; KEV checked against CISA's live catalog.

On October 21, 2026, the PHP project published a security advisory for two critical vulnerabilities that can allow unauthenticated remote code execution, and fixed them in PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Public reporting calls the pair PHP2Shell. The php.net advisory names CVE-2026-109618, remote code execution through out-of-memory corruption, and CVE-2026-109619, remote code execution through stale global state. It also says PHP 8.1 and older no longer receive updates from the PHP project, so there is no PHP 8.1, 8.0 or 7.4 release with the fix; for those three branches the PHP security team published source-only patches instead, and distributions and LTS vendors ship backported packages. Live status and EOL Risk Scores for every branch are on the PHP page.

Key Dates at a Glance

• PHP 8.5: active support ends 2027-12-31; end of life 2029-12-31
• PHP 8.4: active support ends 2026-12-31; end of life 2028-12-31
• PHP 8.3: active support ends 2025-12-31; end of life 2027-12-31
• PHP 8.2: active support ends 2024-12-31; end of life 2026-12-31

Which PHP branches get a fix

The advisory says the risk applies to all PHP installations serving web requests, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed. The PHP project considers the risk highest for mod_php, where it describes a demonstrated exploit in which an unauthenticated request triggers the attack before any application code runs.

What the advisory says about end-of-life PHP

php.net is direct about the branches it no longer maintains. PHP 8.1 and older no longer receive updates from the PHP project. Some distributions and LTS vendors provide backported fixes, and php.net tells users of those branches to contact their vendor or upgrade to a supported version. Linux distributions and LTS vendors received the patches in advance.

Because of the severity, the PHP security team also published minimal source backports for PHP 7.4, 8.0 and 8.1, as branches in the php-src repository, for people who build PHP from source or have no LTS vendor. These are patches to build, not supported releases: the branches stay end of life, and php.net says the backports were provided given the severity of these two vulnerabilities.

The advisory also asks anyone relying on the volunteer-maintained rpms.remirepo.net repository to switch to distribution packages or build from source, because that repository would not have updates on the day of release.

PHP 8.2: patched now, ending soon

PHP 8.2.35 carries the fix, but PHP 8.2's security support ends on December 31, 2026. A flaw found after that date will leave 8.2 where 8.1 is today. Our PHP 8.2 end-of-life guide covers the move to 8.3 or newer and the extended support options.

If you cannot update today

The advisory lists measures that reduce exposure to specific attack paths and says plainly that they do not make an installation safe; only an update is a complete solution. In summary: for CVE-2026-109618, remove the controllable memory-limit failure (memory_limit set to -1 where applications cannot override it), keep post_max_size low and enforce request-size limits at the web server or proxy; for CVE-2026-109619, set session.upload_progress.enabled to 0 and restart every worker, and on PHP 8.5 set fatal_error_backtraces to 0. Read the advisory and its two GitHub security advisories for the exact settings and caveats before applying any of them.

Exploitation status

Neither CVE is in CISA's Known Exploited Vulnerabilities catalog as of the catalog dated October 21, 2026. SecurityWeek reported on October 21 that watchTowr and Huntress had not seen either flaw exploited in the wild; its later updates report that security firms have since seen exploitation attempts, including attempts Amazon observed four days before the fixes were released. Those are reports of attempts, not of confirmed compromises.

What to do

1. Find every PHP runtime, including containers and old servers: php -v on the command line, or the PHP version your web server reports.
2. On 8.2 to 8.5: update to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 or newer, or to your distribution's patched package, and restart PHP-FPM or the web server.
3. On 8.1, 8.0 or 7.4: ask your distribution or LTS vendor for a backported package, build from the PHP security team's source backport, or upgrade. Our PHP 7 migration guide covers the upgrade path from 7.x.
4. On 7.3 or older: there is no fix from the PHP project; upgrade, or isolate the server until you can.
5. Check the rest of the estate with the EOL Checker and the PHP end-of-life guide.

Frequently Asked Questions

Related

• PHP end of life — every branch and its dates
• PHP 8.2 end of life — security support ends December 31, 2026
• Migrating off PHP 7 — the upgrade path to 8.x