Technology

How the PHP2Shell Flaws Reached CISA’s Exploited List and What Patching Requires

Two unauthenticated PHP runtime flaws rated 9.2 now sit on CISA's exploited list, and the fixes run from PHP 8.2.35 through 8.5.12.

By NYJ NewsroomOctober 27, 20265 min read
How the PHP2Shell Flaws Reached CISA’s Exploited List and What Patching Requires

PHP, the server-side language behind a large share of the world’s websites, shipped emergency updates on Oct. 21, 2026 for two remote code execution flaws, CVE-2026-109618 and CVE-2026-109619. Both are rated 9.2 on CVSS v4.0, and they are known together as PHP2Shell.

CISA’s Known Exploited Vulnerabilities catalog now lists both CVEs. The catalog shows a date added of Oct. 26 and a due date of Oct. 29. Reports on whether attacks have begun are not uniform, and the sections below set out what each source says.

Which Servers Are Exposed

The PHP project says any PHP installation that serves web requests is at risk. The Canadian Cyber Centre names PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP and LiteSpeed as affected setups, and says internet-facing servers and applications are at heightened risk.

The highest risk is Apache with mod_php. The PHP project says an unauthenticated request can trigger the flaw before any application code runs. Because the bugs sit in the runtime, The Hacker News reports that a site can be exposed even when its own code is sound.

Version exposure is wide. The Hacker News reports that nearly every PHP version back to PHP 5.4 is affected, and the Canadian Cyber Centre lists each release below the fixed version in its branch as affected. Bitsight’s internet-wide scans found that about a third of the PHP instances whose version it could identify run the 8.2 to 8.5 branches covered by the fix. PHP 7.4 was the most common branch, with more than 2 million observations. Bitsight also notes that many deployments are likely exposed but do not reveal their version.

Catalog Entry
CISA’s Known Exploited Vulnerabilities catalog lists CVE-2026-109618 and CVE-2026-109619 with a date added of Oct. 26 and a due date of Oct. 29. The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35.

Fixed Versions and the Deadlines That Apply

The fixed releases are PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. The Canadian Cyber Centre lists an upgrade to the matching release for each branch that sits below its fix. The PHP project’s advisory says updating is the only complete solution, and that other measures reduce exposure without making a server safe.

Guidance on timing differs by source. The KEV catalog gives a due date of Oct. 29 for both CVEs. The FBI’s IC3 alert says to apply PHP’s updates immediately and, if that is not possible, to take the system offline until it can be fully mitigated. The Canadian alert suggests isolating internet-facing applications from public networks while a fix is pending.

Older branches need a different route. PHP 8.1 and older no longer receive updates from the PHP project. The project provides minimal backports for 7.4, 8.0 and 8.1 for source builds and for users without an LTS vendor, and the Canadian alert notes that some distributions and LTS vendors ship their own backports. The PHP advisory states that PHP 8.2 reaches end of life on Dec. 31, 2026.

Interim Settings for Systems That Cannot Be Updated Yet

The PHP advisory lists settings that narrow the window. For the out-of-memory flaw, CVE-2026-109618, it advises setting memory_limit to -1, preferably in a form applications cannot override, such as php_admin_value. It advises setting post_max_size to 8M on sites that accept no uploads or 32M on sites that do, with upload_max_filesize kept below that value. It also suggests enforcing request limits at the web server or proxy, and says not to use RLIMIT_AS or RLIMIT_DATA as a substitute.

For the stale-state flaw, CVE-2026-109619, the advisory says to set session.upload_progress.enabled to 0 in php.ini, an FPM pool or server configuration, and then restart every worker. It warns not to rely on ini_set() or.user.ini files for this change. On PHP 8.5 it also advises setting fatal_error_backtraces to 0, and it asks administrators to remove per-request settings that produce diagnostics before initialization.

Where Reports of Exploitation Diverge

The sources do not agree on whether attacks are under way. The Canadian Cyber Centre’s alert, updated Oct. 23, says no active exploitation had been identified, while noting that a proof of concept is reportedly available and that the picture could change quickly. The FBI’s IC3 alert describes the flaws as enabling remote code execution and does not state that attacks have been observed.

The Hacker News reports a different picture. It says Cloudflare saw early attacks, and that attackers changed their payloads to evade firewall rules Cloudflare had enabled by default before the patch. It also says watchTowr first reported no exploitation, then later reported active attempts against both CVEs. None of the reports it covers confirms a successful break-in on a specific server.

The timing was tight. The Hacker News reports that details leaked ahead of a planned Oct. 22 disclosure, and PHP released the fixes on Oct. 21. A leaked claim of a 10.0 score did not come from PHP, which rates the flaws 9.2. The FBI alert lists two signs to monitor: PHP processes launching command shells, and PHP processes downloading files. Its advice on a suspected compromise is to isolate the system, preserve web server and PHP logs, and report to an FBI field office or ic3.gov.

Any PHP installation that serves web requests is in scope, and the application code does not have to be flawed for a server to be exposed.

A Third Flaw Still Waiting for a Fix

The Canadian Cyber Centre’s alert also covers CVE-2026-115560, which the Oct. 21 updates do not address. The alert says the PHP Security Team recommends setting session.upload_progress.enabled to 0 until a security update is available, and it names no fixed version for this CVE.

The alert says exploitation requires an uncommon mix of PHP configuration and application behaviour. It states that applications which do not change the serialization handler at runtime are not exposed. Administrators who already applied the session setting for CVE-2026-109619 and kept it in place do not need to take additional action specifically for CVE-2026-115560.

What Site Owners Should Check First

The FBI alert asks organisations to inventory where PHP runs, starting with internet-facing systems and vendor products that bundle PHP. The Canadian Cyber Centre advises identifying third-party products, appliances and containers that include vulnerable PHP components.

The Hacker News notes that distribution packages can carry the fixes under version numbers that look older than the patched releases. A version string alone may therefore mislead, so administrators should check the package changelog for each CVE. For any PHP branch outside the support window, Bitsight advises asking the OS vendor or host whether they will backport the correction, or scheduling a migration.