Learn how HPE Networking SRX Firewalls help defend applications against PHP2Shell vulnerabilities with updated IDP protection.
HPE Networking SRX Firewalls is addressing PHP2Shell on two fronts. First, we published product-specific guidance identifying affected HPE Networking Junos Operating System deployments and the available mitigations. Second, we have updated the SRX intrusion detection and prevention system (IDP) signature set to detect and block PHP2Shell exploit attempts targeting PHP applications, based on available attack samples.
What is PHP2Shell?
PHP2Shell is the name given to two critical vulnerabilities in PHP:
-
CVE-2026-109618: An out-of-memory condition can interrupt PHP while internal request data is only partially initialized. During clean-up, PHP may treat this invalid data as legitimate.
-
CVE-2026-109619: Request-related internal state can remain after its backing memory has been freed. A later request handled by the same worker may use that stale state.
Both vulnerabilities can lead to remote code execution potentially allowing an unauthenticated attacker to run code in the context of the affected PHP process.
Technical Details
CVE-2026-109618—RCE via OOM corruption
Official advisory: GHSA-w8hw-w9fx-j79w
Root cause:
When an allocation fails while PHP is constructing request data, zend_bailout() performs a nonlocal jump via longjmp(). This can interrupt initialization or state restoration, leaving partially initialized structures reachable during subsequent cleanup. A documented example occurs during HashTable insertion: counters are incremented before the new entry is fully initialized. If allocation fails, teardown can treat the unfinished bucket as valid. Nested POST registration and multipart parsing can reach this insertion path. On Apache mod_php, request shutdown still runs after startup failure, allowing cleanup to consume the inconsistent state. Under demonstrated exploitation conditions, this can lead to remote code execution.
Triggering the condition:
An attacker does not need a specially crafted application. They need to force an allocation failure at the right moment. Common techniques observed in research and public PoCs include:
-
Deeply nested form fields that force creation of nested HashTables and string keys.
-
Large numbers of form fields (or empty file controls) that inflate in-memory metadata far beyond the wire size.
-
Multipart headers that are unusually long.
-
Transfer-Encoding: chunked (or HTTP/2 lengthless streams) so that post_max_size does not reject the request early.
By tuning field count, nesting depth, and size, an attacker can control which allocation crosses memory_limit. The exact parameters are sensitive to the PHP version, loaded extensions, and prior allocations in the worker.
Attack Flow:
-
Attacker sends the oversized/specially shaped multipart request to any PHP endpoint.
-
During request startup, an allocation fails and zend_bailout() (longjmp) is called.
-
Normal cleanup is skipped; internal structures (HashTables, buckets, etc.) are left half initialized.
-
Apache still calls request shutdown.
-
Shutdown walks the unfinished data and treats it as valid.
-
With heap shaping, this leads to controlled function pointers and remote code execution as the web user.
Impact:
Successful exploitation yields remote code execution in the context of the PHP process. No authentication and no application flaw are required for the highest-risk mod_php chains. The issue was independently reproduced on PHP 8.5.11, and it was confirmed that the malicious request never reaches application code; the command runs during cleanup of the failed request.
CVE-2026-109619—RCE via stale global state
Official advisory: GHSA-6wmf-4rv5-p3rp
Root cause:
Persistent engine or extension globals can retain references to request-owned memory after that memory has been freed. In the documented cross-request cases, a later request handled by the same surviving worker consumes those stale references before normal initialization resets them, causing a use after free. Relevant state includes session globals such as PS(id) and PS(http_session_vars), decoder state such as BG(unserialize), and error-related fields, depending on the execution path and PHP version. Session upload progress is important because it runs during multipart parsing, before application execution and some normal module initialization. An interrupted lifecycle can leave stale state while early processing in a subsequent request can consume it. OOM is one possible cause; other fatal conditions or late shutdown diagnostics can also leave or recreate stale state.
Triggering the condition:
Exploitation of CVE-2026-109619 typically requires two requests that land on the same worker:
-
Producer: Leaves stale state (via OOM during session decoding, a fatal error that skips reset, or upload-progress publication).
-
Consumer: Uses the stale pointer (often through the upload-progress path or session destruction) before the engine reinitializes the globals.
Worker persistence is not guaranteed by HTTP keep-alive, but it can be improved by crashing other workers, using a single-worker pool, or simply retrying.
Attack Flow:
-
Producer request: Force an OOM or fatal at the right moment so globals such as PS(id), PS(http_session_vars), or BG(unserialize) survive after their memory is freed.
-
Worker continues (memory is released, but the pointers remain).
-
Consumer request (same worker): Send a multipart request that hits the upload-progress handler (or other code that uses the stale globals).
-
The handler operates on the dangling pointers, causing a use after free.
-
This can leak process memory or, with further heap control, lead to remote code execution.
Impact:
The use after free can be turned into:
-
Process memory disclosure (including secrets from other requests or the process itself)
-
Remote code execution
Both vulnerabilities can lead to remote code execution, potentially allowing an unauthenticated attacker to run code in the context of the affected PHP process.
Why is PHP2Shell critical?
PHP is widely used in web applications and embedded product interfaces. Because these flaws exist in the PHP runtime rather than in one particular application, the risk is not limited to a specific website, framework or plug-in.
Both vulnerabilities are rated critical. PHP assigns them a CVSS v4.0 score of 9.2 while CVSS v3.1 scoring is 9.8. The potential consequences include loss of confidentiality, integrity, and availability on an affected system.
Patching or upgrading the affected software remains the primary remediation.
SRX for defending PHP applications
On 10/22/26, HPE Threat Labs has released updated IDP signature for SRX firewalls to detect exploit attempts matching known PHP2Shell attack patterns and, when configured for inline enforcement, block matching traffic. The coverage includes the signature HTTP:PHP:PHP2SHELL-OOB, associated with CVE-2026-109618 and CVE-2026-109619. We are continuously updating the signature as more data is made available on the vulnerability.
When an SRX firewall with the relevant IDP coverage is deployed in the traffic path, it can inspect traffic headed towards a PHP application and take the configured action when matching exploit activity is detected.
This provides an important additional layer of defense, particularly while organizations identify and remediate vulnerable systems. However, IDP coverage should complement, not replace, vendor-recommended patches and upgrades.
Figure 1. IDP signature from HPE Threat Labs on SRX for defending against PHP2Shell vulnerabilities
Is your SRX impacted with PHP2Shell?
SRX does not use PHP starting with 25.2 release. For earlier versions, we recommend upgrading to 25.2.
We are publishing the latest acknowledgment and recommendation as more data is available, please keep a tab on our support portal. Customers should review the advisory and validate the appropriate remediation for their deployed release.
Stay protected against PHP2Shell
PHP2Shell reinforces the need for layered defense. Keep affected software patched or upgraded and use updated SRX IDP coverage as an additional layer to detect and block matching exploit activity. For SRX deployments, review the latest product advisory and apply the recommended remediation for your release.
CTA: Learn more about HPE Networking SRX Firewalls
By Team:
SASE and Security product team
