--- title: "PHP2Shell: CVE-2026-109618 and CVE-2026-109619 - Critical Unauthenticated RCE in PHP" description: "PHP2Shell: two critical PHP flaws (CVE-2026-109618, CVE-2026-109619) allow unauthenticated RCE. Affected versions, patches, mitigations and detection." url: "https://www.gowrishankar.me/blog/php2shell-cve-2026-109618-cve-2026-109619-php-rce" author: "Gowri Shankar Balasubramaniam" published: 2026-10-21T21:37:56.919Z category: "Vulnerability Analysis" tags: ["Apache mod_php","CVE-2026-109618","CVE-2026-109619","Incident Response","Memory Corruption","PCI DSS","PHP-FPM","PHP2Shell","Patch Management","Remote Code Execution","SOC 2","Use-After-Free","php"] --- # PHP2Shell: CVE-2026-109618 and CVE-2026-109619 - Critical Unauthenticated RCE in PHP > PHP2Shell is a pair of critical vulnerabilities in the PHP runtime, rated CVSS v4.0 9.2, that let unauthenticated attackers execute code on web servers. Apache mod_php can be exploited before any application code runs. This advisory covers affected versions, how each attack chain works, patching, interim php.ini mitigations, detection and compliance impact. ## Key takeaways - Two critical runtime flaws, no authentication needed. CVE-2026-109618 and CVE-2026-109619 are both rated CVSS v4.0 9.2 and give code execution as the web worker, regardless of application code quality. - Patch is the only full fix. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, then restart every worker and rebuild container images. - mod_php is most exposed; FPM is not safe. Apache mod_php can be exploited before application code runs, while PHP-FPM has a confirmed RCE path through session upload progress. - Workarounds only narrow the attack surface. Enforced memory_limit = -1, session.upload_progress.enabled = 0 and, on 8.5, fatal_error_backtraces = 0 block confirmed paths but introduce resource-exhaustion trade-offs. - Act as if exploitation is imminent. Working exploits exist privately, reproduction is under way, and fake PoCs are circulating. End-of-life PHP 7.4, 8.0 and 8.1 need a vendor fix, the source backports or an upgrade. PHP2Shell is a pair of critical vulnerabilities in the PHP engine, tracked as CVE-2026-109618 and CVE-2026-109619. The PHP project released emergency fixes on 21 October 2026, and both flaws carry a CVSS v4.0 score of 9.2 (Critical). In practice, an unauthenticated attacker can use either flaw to run code with the privileges of the web worker. Therefore, update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 now, outside your normal patch cycle. Importantly, PHP2Shell is not an application bug. Because the flaws sit in the PHP runtime, every PHP application is exposed, however well its own code is written. On Apache mod\_php, exploitation can even begin before any application code runs. As a result, secure coding practices and application-specific WAF rules offer little protection. Moreover, the threat is no longer theoretical. The PHP security team and its research partners demonstrated working RCE during disclosure, and independent researchers report reproducing it. A public exploit is widely expected within days. Configuration workarounds can narrow specific PHP2Shell attack paths; however, only a build containing both complete fixes fully remediates the risk. | CVE | PHP advisory | Title | CVSS v4.0 | Authentication | Impact | | --- | --- | --- | --- | --- | --- | | [CVE-2026-109618]() | [GHSA-w8hw-w9fx-j79w]() | RCE via out-of-memory (OOM) corruption | 9.2 Critical | None | Code execution as the web worker | | [CVE-2026-109619]() | [GHSA-6wmf-4rv5-p3rp]() | RCE via stale global state (use-after-free across requests) | 9.2 Critical | None | Code execution as the web worker; worker memory disclosure | Vector for both: `CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N`. The "high complexity" and "attack requirements present" metrics reflect dependence on memory layout and worker reuse, not a meaningful barrier for a determined attacker. | Branch | Affected | Fixed in | Upstream status | | --- | --- | --- | --- | | PHP 8.5 | 8.5.11 and earlier | 8.5.12 | Supported | | PHP 8.4 | 8.4.26 and earlier | 8.4.27 | Supported | | PHP 8.3 | 8.3.35 and earlier | 8.3.36 | Security fixes only | | PHP 8.2 | 8.2.34 and earlier | 8.2.35 | Security fixes only; end of life 31 December 2026 | | PHP 7.4, 8.0, 8.1 | All releases | No official release; limited source backports only | End of life | | PHP 5.4 to 7.3 | Reported affected | None | End of life | ## How the PHP2Shell attacks work ![Two critical flaws in the PHP engine, CVE-2026-109618 and CVE-2026-109619, allow unauthenticated remote code execution. Update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35 immediately.]() CVE-2026-109618 corrupts memory within a single request, while CVE-2026-109619 needs two requests on the same worker; both end in code execution with the web worker's privileges. ## CVE-2026-109618: memory corruption during out-of-memory handling The first PHP2Shell flaw stems from an unsafe control-flow exit. When an allocation fails, PHP raises a fatal error and unwinds using longjmp(). If this happens while internal request structures are only partly initialised, request shutdown later treats that half-built state as valid and operates on it, giving the attacker a corruption primitive. The attacker does not need the application to do anything unusual: - Crafted multipart/form-data requests can exhaust PHP's memory limit during input parsing, even when their declared size appears to respect `post_max_size` and `upload_max_filesize`. - Any application operation that allocates memory in proportion to attacker input (large JSON decoding, array building, string expansion) can also trigger the OOM condition. Apache mod\_php is the most exposed SAPI here. It runs request cleanup even when request startup fails, so the demonstrated chain completes before a single line of application code executes. The PHP advisory reports full RCE over HTTP with default `memory_limit` and input limits, including multi-worker prefork deployments. PHP-FPM behaves differently: it terminates the worker when startup fails, which breaks that particular sequence. Source analysis still indicates FPM is susceptible after a successful startup, although the advisory reports no complete FPM exploit for this CVE. Treat FPM as vulnerable, not safe. Exploit reliability varies with the build, loaded extensions, front-end behaviour and memory layout. ## CVE-2026-109619: use-after-free across requests The second PHP2Shell flaw exploits worker reuse. A PHP worker serves many requests in sequence, and some global variables are expected to be reset between them. When a fatal error (memory exhaustion, an execution timeout) interrupts cleanup, a global can be left pointing at memory that was freed at the end of the previous request. The next request on the same worker can read or branch on that stale pointer before normal initialisation clears it. The advisory confirms three exploitation routes: - **PHP 8.5 fatal error backtraces (mod\_php).** With `fatal_error_backtraces` enabled, which is the default, a later initialisation diagnostic touches stale saved backtrace state. - **Session lifecycle (mod\_php and PHP-FPM).** Session upload progress is enabled by default and consumes session or decoder state early, before the application runs. The application does not need to call `session_start()` for this path to be reachable. - **Shutdown diagnostics.** Some non-fatal warnings emitted during shutdown can repopulate error state after it was reset, recreating the stale reference. The validated FPM path needs two requests on the same worker: one that leaves state behind and ends in a fatal error, and a second that consumes it through upload progress. Multiple workers and recycling lower the per-request success rate but do not remove the condition; an attacker simply sends more requests. JFrog's analysis adds that the same pattern affects OPcache shared-memory state across workers, which widens the blast radius on shared hosts. This flaw also enables Heartbleed-style disclosure of worker memory, which may expose session tokens, credentials or cardholder data in transit through the process. ## Who is affected by PHP2Shell, and is it being exploited? Every PHP installation that serves web requests is affected by PHP2Shell, and working exploits already exist, although confirmed in-the-wild exploitation has not yet been consistently reported. The SAPI in use determines how early and how reliably an attacker can strike. | SAPI | CVE-2026-109618 | CVE-2026-109619 | Relative risk | | --- | --- | --- | --- | | Apache mod\_php | Full RCE demonstrated, pre-application | Full RCE demonstrated (backtrace and session paths) | Highest | | PHP-FPM | Susceptible after startup; no complete public exploit | Full RCE demonstrated via session path | High | | php-cgi, FrankenPHP, LiteSpeed | In scope per vendor | In scope per vendor | Treat as high until proven otherwise | Downstream products are also affected. Plesk has shipped rebuilt PHP packages dated 21 October 2026, and Palo Alto Networks lists Panorama as affected with a fix date still to be confirmed. Expect further advisories from appliance and hosting vendors that embed PHP. Exploitation status as of 21 October 2026: - The PHP advisories state that working RCE exploits were built during research. - watchTowr reports that it has reproduced CVE-2026-109618, and Rapid7 notes multiple signs of independent reproduction, with a public exploit expected soon. - Reporting on in-the-wild exploitation is not yet consistent across sources. Assume active exploitation is imminent and patch on that basis. - JFrog has flagged fake proof-of-concept repositories circulating around the disclosure. Do not run unverified PoC code on corporate systems; some may be malware lures aimed at defenders. ## How do you fix PHP2Shell? You fix PHP2Shell by installing PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a vendor build with both complete fixes, and then restarting every PHP worker. Work through the following in order. 1. **Inventory every PHP runtime.** Include web servers, container base images, CI runners, appliances and hosting panels. Check both the CLI and the web SAPI, as they are often different builds. 2. **Patch supported branches.** Move to 8.5.12, 8.4.27, 8.3.36 or 8.2.35. Linux distributions and long-term support vendors received the patches in advance, so prefer distribution packages and confirm the changelog references both CVE IDs. 3. **Restart every worker.** Restart PHP-FPM pools and Apache, not just reload configuration. Old workers keep running vulnerable code. 4. **Rebuild containers.** Pull patched base images, rebuild, redeploy and retire old image tags so that autoscaling cannot resurrect a vulnerable version. 5. **Handle end-of-life branches.** PHP 7.4, 8.0 and 8.1 receive no official release. PHP has published limited source backports for this incident only. Use a commercial LTS vendor fix, build from those backports, or upgrade. Plan the move off PHP 8.2 now, as it reaches end of life on 31 December 2026. 6. **Watch third-party repositories.** PHP warned that rpms.remirepo.net would not have updates on 21 October 2026; users of that repository should switch to distribution packages or build from source. Verify the running version on each host, not only the installed package: ```bash # CLI build php -v # FPM build (binary name varies by distribution) php-fpm8.3 -v 2>/dev/null || php-fpm -v # Debian / Ubuntu package changelog apt changelog php8.3-fpm | grep -E 'CVE-2026-10961[89]' # RHEL family rpm -q --changelog php-fpm | grep -E 'CVE-2026-10961[89]' ``` For the web SAPI, check the version through an authenticated internal health endpoint or your vulnerability scanner rather than leaving a `phpinfo()` page exposed. ## Interim PHP2Shell mitigations (only where patching must wait) These measures narrow the confirmed attack paths; they do not fix either vulnerability. Apply them administratively so applications cannot override them, then restart every worker. Application-level `ini_set()` calls and FPM `.user.ini` files take effect too late to help. | Control | Addresses | Trade-off | | --- | --- | --- | | `memory_limit = -1` (enforced) | Predictable OOM trigger in CVE-2026-109618 | Removes the per-request memory cap; real allocation failures can still reach the bug | | `session.upload_progress.enabled = 0` | Confirmed session paths in CVE-2026-109619 | Breaks upload progress bars, if used | | `fatal_error_backtraces = 0` (PHP 8.5) | Confirmed backtrace path in CVE-2026-109619 | Less diagnostic detail; other stale state remains | | Tight `post_max_size` and front-end request limits | Reduces multipart-driven exhaustion | Must be tuned per application | PHP-FPM pool configuration (for example `/etc/php/8.3/fpm/pool.d/www.conf`): ```ini ; Interim PHP2Shell mitigations - remove once patched builds are deployed php_admin_value[memory_limit] = -1 php_admin_flag[session.upload_progress.enabled] = off ; PHP 8.5 only php_admin_value[fatal_error_backtraces] = 0 ; Compensating resource controls, because the PHP memory cap is now disabled php_admin_value[post_max_size] = 8M php_admin_value[upload_max_filesize] = 6M request_terminate_timeout = 60s pm.max_requests = 500 ``` Apache with mod\_php (virtual host or global configuration): ```apache php_admin_value memory_limit -1 php_admin_flag session.upload_progress.enabled off php_admin_value post_max_size 8M php_admin_value upload_max_filesize 6M ``` Use 32M for `post_max_size` where uploads are genuinely required, keeping `upload_max_filesize` below it. Then verify that no other pool, directory or `.htaccess` setting restores a finite memory limit. Front-end controls in nginx, for applications that accept no file uploads: ```nginx client_max_body_size 8m; large_client_header_buffers 4 8k; location ~ \.php$ { if ($content_type ~* "^multipart/") { return 415; } # existing fastcgi_pass configuration } ``` Risk considerations: - Disabling the PHP memory cap shifts denial-of-service protection elsewhere. Size `pm.max_children` against available RAM and monitor host memory closely. - Container or cgroup memory limits are not a substitute. Allocation failures can still occur, and OOM enforcement may kill the master process and all workers together. - Do not use `RLIMIT_AS` or `RLIMIT_DATA` as a workaround; they can trigger the very allocation-failure path being exploited. - Suppressing errors with `display_errors`, `log_errors`, `error_reporting` or `@` does not prevent stale-state access. A clean error log is not evidence of safety. - Fix invalid or deprecated per-request settings and any attacker-reachable fatal errors or timeouts, as these feed CVE-2026-109619. ## PHP2Shell detection and incident response No reliable single indicator of compromise has been published yet, so detection should combine request anomalies, PHP error patterns and post-exploitation behaviour on the host. Signals worth hunting for: - Bursts of `Allowed memory size of ... bytes exhausted` fatal errors, especially during POST input parsing and from a small set of source IPs. - Unusual multipart requests: very high part counts, many headers per part, deep nesting, or chunked bodies without a usable `Content-Length`. - Repeated `Maximum execution time exceeded` errors followed closely by further POSTs from the same client. - PHP-FPM workers or Apache children crashing with segmentation faults (`SIGSEGV`) or restarting more often than baseline. - Web server user (`www-data`, `apache`, `nginx`) spawning shells, `curl`, `wget`, compilers or outbound connections, and new files appearing under the web root. A quick log triage on a Linux host: ```bash # OOM fatal errors per hour (adjust the log path to your environment) grep -h 'Allowed memory size' /var/log/php*-fpm.log /var/log/apache2/error.log 2>/dev/null \ | awk '{print $1, substr($2,1,2)}' | sort | uniq -c | sort -rn | head # Worker crashes grep -hE 'SIGSEGV|exited on signal 11|segfault' /var/log/php*-fpm.log /var/log/syslog 2>/dev/null | tail -n 50 # Recently modified PHP files in the web root (last 3 days) find /var/www -type f -name '*.php' -mtime -3 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort ``` Commercial coverage is arriving quickly: Rapid7 has released remote unauthenticated checks, JFrog Xray and Catalog include both CVEs, and Velociraptor offers a PHP inventory artifact for scoping. If you find signs of compromise, treat the host as untrusted. Isolate it, preserve memory and logs, and rotate every secret the PHP process could read, including database credentials, API keys, session signing keys and any payment gateway credentials. Because CVE-2026-109619 can leak worker memory, assume that data processed by the worker may have been exposed, even where no code execution is evident. ## Compliance and governance considerations For regulated environments, PHP2Shell is a compliance event as well as a technical one. - **PCI DSS v4.0.1.** Requirement 6.3.3 expects critical security patches to be installed within one month of release; given unauthenticated RCE, most risk rankings under Requirement 6.3.1 will justify a far shorter internal deadline. Any PHP host in or connected to the cardholder data environment should be patched first, and the memory-disclosure aspect of CVE-2026-109619 is directly relevant to Requirement 3 data protection. Re-run internal and external vulnerability scans (Requirements 11.3.1 and 11.3.2) after patching to evidence closure. - **SOC 2.** Document detection, assessment and remediation under CC7.1 (vulnerability identification) and CC7.2 (monitoring), and record emergency changes under CC8.1 with approvals and rollback plans. Auditors will look for evidence that out-of-cycle patching followed the defined emergency change process. - **Third-party risk.** Ask hosting providers, SaaS vendors and appliance suppliers that run PHP for written confirmation of patch status and timelines, and log the responses in the vendor risk register. The governance lesson is broader than this pair of CVEs. Runtime flaws bypass application-layer controls entirely, so security architecture should assume the platform beneath the code can fail. Three practices reduce that exposure: a maintained software bill of materials that includes language runtimes, a policy that retires end-of-life runtimes before vendor support ends, and least-privilege worker accounts with egress filtering so that code execution as the web user does not become full compromise. ## Latest updates | Date | Update | | --- | --- | | 21 Oct 2026 | Rapid7 releases remote unauthenticated checks; JFrog adds both CVEs to Xray and Catalog and warns of fake PoCs | | 21 Oct 2026 | Plesk ships rebuilt PHP packages for Linux and Windows; Palo Alto Networks lists Panorama as affected, fix date pending | | 21 Oct 2026 | watchTowr reports reproducing CVE-2026-109618; Rapid7 notes multiple independent reproduction efforts | | 21 Oct 2026 | PHP releases 8.5.12, 8.4.27, 8.3.36 and 8.2.35, plus limited source backports for 7.4, 8.0 and 8.1 | | 21 Oct 2026 | CVE IDs assigned; PHP and Wiz Research publish coordinated disclosure | PHP2Shell is a fast-moving situation. Check the PHP advisories for revised mitigation guidance and your distribution's security tracker for package availability. ## ## Questions and answers ### What is PHP2Shell? PHP2Shell is the public nickname for CVE-2026-109618 and CVE-2026-109619, two critical vulnerabilities in the PHP engine disclosed on 21 October 2026. Both allow unauthenticated remote code execution, and both are rated 9.2 under CVSS v4.0. ### Which PHP versions are affected? All PHP 8.2, 8.3, 8.4 and 8.5 releases before 8.2.35, 8.3.36, 8.4.27 and 8.5.12 are affected. End-of-life branches, including PHP 7.4, 8.0 and 8.1, are also affected, and researchers report the flaws reach back to PHP 5.4. ### Is my application vulnerable even if its code is secure? Yes. The flaws sit in the PHP runtime, not in application code. On Apache mod_php, exploitation can complete before any application code executes, so secure coding and application-specific WAF rules do not prevent it. ### Does an attacker need to log in or interact with a user? No. Both vulnerabilities are exploitable over the network without authentication or user interaction. A single crafted HTTP request can start the attack against any PHP endpoint. ### Is PHP-FPM safer than Apache mod_php? PHP-FPM is less exposed but not safe. mod_php carries the highest risk, while PHP-FPM has a confirmed RCE path for CVE-2026-109619 through session upload progress. Source analysis also indicates FPM is susceptible to CVE-2026-109618 after successful request startup. ### Are these vulnerabilities being exploited in the wild? Working exploits were built during research, and independent reproduction has been reported. Sources do not yet agree on confirmed in-the-wild exploitation, so treat exploitation as imminent and patch on an emergency basis. ### How do I fix it? Upgrade to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35, or a distribution package containing both fixes. Then restart every PHP-FPM pool and Apache process and rebuild container images, because running workers keep the vulnerable code in memory. ### What if I cannot patch immediately? Apply the interim mitigations administratively: enforce memory_limit = -1, set session.upload_progress.enabled = 0, and on PHP 8.5 set fatal_error_backtraces = 0, then restart all workers. These measures only block known attack paths and add resource-exhaustion risk, so pair them with strict request-size limits and patch as soon as possible. ### What about PHP 7.4, 8.0 and 8.1? The PHP project is not issuing official releases for these end-of-life branches. Limited source backports are available for this incident only. Obtain a fix from your distribution or LTS vendor, build from the backports, or upgrade to a supported branch. ### How can I tell whether a server has been compromised? Look for bursts of memory-exhaustion fatal errors, abnormal multipart requests, worker segmentation faults, and the web server account spawning shells or making outbound connections. If you find indicators, isolate the host, preserve evidence and rotate every secret the PHP process could access. A clean error log does not prove the server is safe. ## Sources - [PHP advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)]() - [PHP advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)]() - [PHP release announcement]() --- Source: https://www.gowrishankar.me/blog/php2shell-cve-2026-109618-cve-2026-109619-php-rce