On October 26, 2026, CISA added two critical PHP vulnerabilities — CVE-2026-109618 and CVE-2026-109619, collectively known as PHP2Shell — to the Known Exploited Vulnerabilities (KEV) catalog. Both vulnerabilities allow unauthenticated arbitrary code execution on the server and are rated 9.2 under CVSS v4.0 (9.8 under CVSS v3.1, according to the Arista advisory). Given that PHP is used by roughly 69% of websites with a known server-side language (according to W3Techs), the potential impact is enormous. Patches have been available since October 21 — updating PHP is a priority action for all affected organizations. We have already provided a detailed analysis of these vulnerabilities earlier; this article focuses on the confirmation of active exploitation and new details.
Technical details of the vulnerabilities
Both vulnerabilities fall under CWE-416 (Use After Free) and affect the PHP core, but they exploit different mechanisms:
- CVE-2026-109618 — related to improper handling of out-of-memory (OOM) conditions. When OOM occurs, PHP uses
longjmp()to exit the current context, but internal request data may remain in a partially initialized state. The subsequent request cleanup procedure accesses this uninitialized memory, opening a path to code execution. - CVE-2026-109619 — exploits stale global state that continues to reference already freed request memory. Subsequent requests handled by the same worker process can read this stale state before it is fully reinitialized.
According to the official PHP security advisory, all PHP versions below 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are affected. Branches 8.1 and older no longer receive official updates from the PHP project, although Linux distributions may provide backported fixes.
Risk depending on server configuration
An important nuance that is often missed in overviews: the degree of exposure depends significantly on the server API (SAPI) in use. Based on information from PHP’s GitHub advisories, configurations differ in their risk level:
- Apache mod_php — the most vulnerable configuration. Exploitation is possible before application code is executed, because mod_php unconditionally calls the request shutdown procedure even if initialization fails.
- PHP-FPM — when initialization fails, the child process exits, but a separate exploitation path via stale session state has been confirmed, provided the attacker’s requests are routed to the same worker process.
- php-cgi, FrankenPHP, LiteSpeed — also listed by the PHP project as affected configurations.
This dependence on SAPI means that risk assessment must take into account the specific deployment architecture, not just the PHP version.
Scale of the threat
According to the Censys tracker, a significant number of PHP services on the internet continue to run vulnerable versions (the original source mentions an estimate of more than 32.51 million services, but this figure is not directly confirmed in the publicly available Censys tracker text).
The industry response has been unprecedented in scale: dozens of major vendors have issued security advisories, including Broadcom, Citrix, Dell, F5, Ivanti, Okta, QNAP, Synology, Veeam, WordPress, as well as industrial equipment manufacturers — Schneider Electric, Siemens, Rockwell Automation, Moxa and Hitachi Energy. This indicates that the vulnerabilities affect not only web applications, but also embedded control systems, NAS devices and enterprise software.
Additional threat: CVE-2026-111497 in the Brotli library
In parallel with PHP2Shell, on October 26 the PHP Foundation released updated Windows builds (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1) that fix CVE-2026-111497 — an out-of-bounds write vulnerability in the Brotli decompression library. According to the Brotli v1.2.1 release notes, this vulnerability also allows remote code execution. In PHP on Windows, the vulnerable decoder is accessible via the cURL extension when automatic decompression of HTTP responses is enabled (disabled by default, but can be turned on by applications and HTTP client libraries), as the PHP Foundation notes.
CVE-2026-111497 has also been added to the CISA KEV catalog with a remediation deadline of November 10, 2026. We have previously analyzed this vulnerability in detail, including its impact on Node.js, Bun, Python, Envoy Proxy and .NET.
Recommendations
According to the official position of the PHP project, updating is the only complete way to remediate the PHP2Shell vulnerabilities. Configuration changes (such as setting memory_limit=-1 or disabling session upload tracking) mitigate individual attack vectors but do not provide full protection.
- Immediately update PHP to versions 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (available on php.net).
- For Windows builds — install the versions with the “-1” suffix (8.5.12-1, 8.4.27-1, 8.3.36-1, 8.2.35-1), which additionally fix CVE-2026-111497.
- For PHP 8.1 and older — these branches do not receive official updates. Check whether your distribution provides backported fixes; otherwise, you need to migrate to a supported branch.
- Prioritize servers with mod_php — this configuration is the most vulnerable and allows exploitation before application code execution.
- Review vendor advisories for all products that use PHP as an embedded component (NAS devices, control systems, enterprise platforms).
The remediation deadline for U.S. federal agencies for PHP2Shell is October 29, 2026, and for CVE-2026-111497 it is November 10, 2026. Commercial organizations should treat these dates as priority benchmarks: inclusion in the KEV catalog means active exploitation has been confirmed, and every day of delay increases the attack surface. Update PHP first on all internet-facing servers, and then on internal systems, taking into account the SAPI in use and any embedded PHP components in third-party software.
