On October 21, 2026, the PHP team released emergency updates for two critical remote code execution (RCE) vulnerabilities collectively dubbed PHP2Shell. The vulnerabilities CVE-2026-109618 and CVE-2026-109619 are located in the PHP engine itself, not in any specific application, which means any server that handles web requests via PHP is vulnerable — including PHP-FPM, Apache mod_php, php-cgi, FrankenPHP, and LiteSpeed. Both vulnerabilities are rated 9.2 on the CVSS v4.0 scale and allow an unauthenticated attacker to execute arbitrary code. Fixes are available in PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35 — updating the runtime is the only complete solution.
Technical details of the vulnerabilities
Both vulnerabilities belong to the Use After Free class (CWE-416), but they exploit different mechanisms inside PHP.
CVE-2026-109618 — RCE via memory corruption when handling an out-of-memory (OOM) error. According to the official advisory, PHP uses longjmp() to handle OOM errors, and in certain contexts a request can be interrupted when internal data has not yet been fully initialized. In this case, the request shutdown procedure treats invalid data as if it were valid. In an Apache mod_php configuration this is particularly dangerous: the shutdown procedure is called unconditionally even if request startup fails, and automatic parsing of the request body can exhaust the memory limit before any application code starts running.
CVE-2026-109619 — RCE via stale global state. As stated in the advisory, internal state belonging to a request can persist after memory has been freed. A subsequent request processed by the same worker can use this stale state before normal initialization resets it. Code execution has been confirmed via the fatal backtrace path on mod_php and via the session lifecycle on both mod_php and PHP-FPM.
In addition to code execution, an attacker can read the memory of a PHP worker process, which can contain passwords, authentication tokens, API keys, and certificates from other requests — without first achieving RCE.
Affected versions and configurations
All PHP versions below 8.2.35, 8.3.36, 8.4.27, and 8.5.12 are vulnerable. The vulnerable code has been present in PHP for more than ten years, affecting versions all the way back to PHP 5.4. PHP highlights Apache mod_php as the configuration with the highest confirmed risk: for CVE-2026-109618 an exploit has been demonstrated that triggers before any application code is executed. PHP-FPM is also affected: for CVE-2026-109619 exploitation via the session lifecycle has been confirmed.
Industry response
Even before the patches were released, Cloudflare, according to CTO Dane Knecht, detected early exploitation attempts and deployed emergency WAF rules, calling them a temporary measure. At the same time, no source has confirmed a successful compromise. The company watchTowr, which reproduced CVE-2026-109618, had not observed exploitation in the wild as of 11:26 UTC on October 21. According to Huntress, public exploit code was also not available at the time their report was published.
A number of organizations proactively shut down services. BambooHR suspended operations in the US, Canada, and Ireland, warning of payroll processing disruptions. In the Netherlands, the government portals MijnOverheid and DigiD, the website of the lower house of parliament, the national cybersecurity center, and several educational systems were taken offline.
Why the session.upload_progress.enabled setting is not a protection
Before the patches were released, a widely circulated community recommendation was to set session.upload_progress.enabled=0 as a workaround. Tokyo-based company GMO Flatt Security initially proposed this measure but later withdrew the recommendation, stating that the setting by itself is not a complete fix and that bypass techniques are expected.
PHP core developer Gina Peter Banyard wrote bluntly: “The only thing I can say is that the only mitigation is updating PHP. Unfortunately, I know too much.”
The published advisories confirmed this: disabling session.upload_progress.enabled only blocks the confirmed CVE-2026-109619 exploitation paths via sessions, but does not cover other variants and has no effect on CVE-2026-109618. The company watchTowr assesses changes to INI files as ineffective for preventing exploitation.
Recommendations for updating and temporary measures
Updating the PHP runtime is the only complete solution. You must update the specific PHP component that serves web requests (PHP-FPM, mod_php, or CGI), and then restart Apache, PHP-FPM, and all long-lived workers. Updating applications (WordPress, Laravel, etc.) does not update the PHP runtime.
If an immediate update is impossible, then according to the official PHP advisory, the following measures reduce risk for specific attack paths but do not make the server safe:
- For CVE-2026-109618: set
memory_limit=-1so that applications cannot override the value; keeppost_max_sizelow; apply request size limits at the web server or proxy level. PHP warns: do not use RLIMIT_AS or RLIMIT_DATA as a substitute — they can trigger the same vulnerable path. - For CVE-2026-109619: set
session.upload_progress.enabled=0and restart all workers; on PHP 8.5 additionally setfatal_error_backtraces=0. - Isolation: CERT-EU recommends considering isolating internet-facing PHP applications from public networks until the patch is installed — via VPN, allowlists of client IPs, or perimeter authentication.
- Minimizing the impact of compromise: reduce the amount of data stored on the server, remove stored credentials and cloud roles, lower privileges, and ensure logs are written to a protected storage location.
Unsupported PHP versions
PHP 8.1 and older no longer receive updates from the PHP project. However, given the criticality of these vulnerabilities, the PHP security team has published minimal source-code backports for PHP 7.4, 8.0, and 8.1. Linux distributions and LTS vendors may provide their own fixes — as Debian recommends, check the package changelog for the CVE, not the version number.
Detection and monitoring
According to Huntress recommendations, exploitation of such vulnerabilities most often manifests as suspicious child processes spawned by PHP workers — shells, interpreters, download utilities, and reconnaissance commands. These indicators are general signs of PHP compromise, not specific to PHP2Shell.
The researchers who discovered the vulnerabilities recommend that, after updating, you review logs for: unusual multipart requests accompanied by memory limit errors or repeated HTTP 500 responses; abnormally large PHPSESSID cookies in responses; unexplained PHP worker restarts.
PHP2Shell is a rare case where a vulnerability affects not a specific application but the language runtime itself, making even a server with the simplest page vulnerable. Updating priority is maximal: first, servers running Apache mod_php, then PHP-FPM. For unsupported versions, apply backports or isolate servers from the internet. WAF rules and configuration changes reduce risk for certain paths but are no substitute for a patch.
