Fastly’s Proactive Protection for PHP2Shell, Critical React RCE CVE-2026-109618 and CVE-2026-109619

PHP – the runtime behind most of the web's content management systems, ecommerce platforms, and publishing infrastructure — is being haunted by the poltergeists of decades past: a design decision that led to a flaw in how its engine handles fatal errors. The vulnerabilities disclosed today, named php2shell, share their root in this design decision that we’ll discuss in the post.

The PHP Foundation assigned two CVEs (CVE-2026-109618, CVE-2026-109619) and are patched in PHP 8.2 and up (the patched versions are 8.5.12, 8.4.27, 8.3.36, and 8.2.35.). PHP also published patches for 7.4, 8.0, and 8.1 for integration by package distributors. Versions under 7.4 will not receive a patch from PHP and will be patched at the discretion of package distributors. Every maintained PHP version is affected. At this time, the oldest demonstrated exploit path has been present since 2012. 

There is evidence of active attacks in-the-wild pre-disclosure; these are not theoretical issues.

We strongly encourage customers to search for any application servers in their environment with mod_php or php-fpm and patch with urgency. If you cannot find any means to patch, then we recommend active mitigation. 

At this time, given the nature of these exploits (including pre-auth RCE), you should assume active mitigation will only serve as partial protection and may require blocking a substantial portion of legitimate traffic depending on approach.

We’re grateful for the close collaboration with OpenAI, as well as other software ecosystem partners who contributed to this urgent effort to keep as many organizations as protected as possible. 

In this post, we’ll explain more about the vulnerabilities, describe how these PHP exploits could impact your business, and offer guidance for mitigating exploitation attempts.

The tl;dr behind CVE-2026-109618 & CVE-2026-109619

When PHP hits a memory limit, an execution timeout, or a dropped connection, it does not unwind gracefully. It abandons whatever it was doing mid-operation and jumps to a recovery point, leaving behind partially modified internal state. That leftover state can point to memory that has already been freed or contain data structures that were never finished being built.

Researchers have demonstrated that an attacker can trigger these error conditions with a single unauthenticated HTTP request. The attacker can succeed with zero login, special endpoint, or cooperation from the application. The RCE allows the attacker to control what ends up in the leftover state precisely enough to make PHP execute arbitrary shell commands as the web server's purportedly legitimate operating system user. The worker process survives and keeps serving requests afterward, naive of its new commander.

The only log entry is a routine out-of-memory error. This will be a wild ride, to say the least.

The potential impact cannot be overstated:

• Breadth: Any organization with PHP applications

• Depth: The attacker can do what they want in the application

Because you may run a PHP configuration and inadvertently have mod_php or php-fpm, we strongly encourage customers to consider any PHP application potentially vulnerable and scan your environment accordingly.

One saving grace: the existing PoCs require knowledge of the specific, running PHP binary and address space layout on the server for an attack to yield code execution on x86_64, so most deployments may be “safe” from RCE. Do not assume this holds true for you. If you operate a 32-bit PHP application, you should likely assume compromise. 

Digging Deeper: The Engine-Level Design Problem

PHP's engine handles fatal errors in a creative way. If something goes terribly wrong, every function that was in the middle of something gets no notification and no chance to clean up their mess. Their half-finished work stays exactly as they left it. More specifically, the engine employs a mechanism called longjmp(), which teleports execution directly to a catch point (like grabbing the app by the scruff of its neck, so to speak) rather than logging an error and immediately exiting stage left.

PHP's engine invokes this mechanism — called zend_bailout — from every code path that enforces a resource limit or handles a fatal condition (which is many of them). When the application experiences memory exhaustion, execution timeouts, aborted client connections, and uncaught fatal errors, they all get the zend_bailout treatment.

This creative approach would be manageable if it happened rarely or in controlled circumstances. As anyone old enough to have experienced the joys of PHP development knows well, these fatal errors happen routinely in production PHP deployments, and more importantly, these conditions appeal to attackers who would love full control over the world wide web (i.e. all application servers running PHP today).

What leads to exploitation?

When zend_bailout fires, any internal PHP operation partway through modifying a data structure will leave that data structure in an inconsistent state, which violates the operation’s expectations. PHP's subsequent cleanup code that runs after every request to tear down the request's state then encounters that inconsistent data and acts on it as though it were valid.

The published POCs should be treated as illustrative examples and far from enumerating the full menagerie of bailout and early-exit paths that may trigger similar conditions that attackers can exploit. To reinforce why this is problematic for the internet: the PHP source tree calls the zend_bailout mechanism many places; each can interrupt a different set of in-progress operations; and each features its own invariants when interrupted.

The combinatorial space is, to put it mildly, explosive. Patching the specific paths that researchers demonstrated does not make the mechanism safe. Given the ROI of this vulnerability, attackers will be highly motivated to find the next undiscovered path to continue their exploit spree.

Assume cybercriminal organizations and nation states alike will jump on this; the primitive is powerful when combined with an infoleak… and it doesn’t even have to be a particularly elite infoleak. The infoleak bug can crash the process and still count as valid thanks to mod_php’s prefork design. “How to panic safely” is a topic for another time.

Why is the impact so high?

Here’s what an attacker could get from achieving remote code execution on a PHP server:

• Take down PHP-based websites and applications with a single, unauthenticated request; at scale, this manifests as a sustained outage (assuming the content is not cached)

• Run any command on the server without any visible disruption; the server gladly accepts the attackers’ input

• Steal every credential the application uses: database passwords, API keys, cloud provider keys, encryption keys

• Access the databases, cache systems, message queues, and internal systems those credentials protect: customer records, transactions, PII, whatever the application talks; this can trigger breach-notification and other regulatory obligations

• Move deeper into the network: traverse cloud infrastructure, Kubernetes service account tokens, Envoy, SSH keys on disk, and internal services given the web server is already inside your trusted environment

• Establish persistent access that survives server restarts and redeployments (the equivalent of the comfy beach chair for the attacker in the form of backdoors into php files or sneaky cron jobs)

• No obvious clues: the only log entry is a routine memory error that operations teams see regularly and rarely investigate (barring exceptionally curious SREs)

The impact chain can be severe for a variety of use cases. Consider a typical storefront: one HTTP request → server compromise → persistent skimmer installed → ongoing mass card theft across the entire customer base → PCI DSS breach → potential loss of ability to process cards at all.

How to determine exposure

We encourage customers to consider any PHP application potentially vulnerable and audit your production environment accordingly. This is not the time to cut corners on vulnerability investigation; start the inventory now. As a more specific list of criteria to determine exposure, check for the following:

• PHP behind Apache mod_php in prefork mode

• A memory_limit / post_max_size ratio that allows an attacker to trigger OOM from a POST body

• The denial-of-service (DoS) variants (crashes without code execution) affect a broader set of configurations including php-fpm

Industries we believe may be especially vulnerable to these attacks include:

• Ecommerce (online commerce platforms) | post_max_size is often higher than default to accommodate file uploads

• Media & Publishing (content management systems) | massive surface of vanilla Apache mod_php instances with default (or near-default) configs

• Education (learning platforms, custom student portals, faculty tools) | PHP’s footprint in higher education is formidable, often managed by lean teams

• Hospitality & Travel (booking engines, loyalty platforms, property management systems) | Custom PHP on LAMP stacks often feature generous upload limits for photos and documents

• Financial Services (payment integrations, loan application portals, insurance claims) | elevated post_max_size given ample document-heavy workflows; PHP is the COBOL of customer-facing apps

• SaaS (internal admin tools, customer support dashboards, web frameworks) | often less monitored and operated by lean SMB teams

• Managed hosting and shared hosting providers (web hosting control panels, multi-tenant Apache environments) | multiplicative impact if a vulnerable PHP config hits a shared server

• Healthcare (patient portals, scheduling systems, health data integrations) | sensitive uploads like lab results, referral forms, insurance cards require a larger post_max_size

How to gain active protection now

To mitigate risk for your applications protected by NGWAF, we recommend that you immediately apply the Virtual Patch for CVE-2026-109618 & CVE-2026-109619 to all Edge and On-prem services that may be vulnerable. The detection content within this CVE-specific Templated Rule looks for the structural hallmarks of these exploitation attempts — bodies and parameters shaped in ways that differ from legitimate traffic — that may indicate potential exploitation attempts of php2shell CVEs.

Fastly’s Security Research team developed and tested this content in close collaboration with OpenAI and community partners; we’re grateful for this partnership. Our Security Research team will update the Virtual Patch as needed; anyone who has opted-in will receive subsequent updates automatically. 

Fastly will continue to investigate additional layers of defense we can offer for our customers to detect and block attack traffic related to php2shell. We will continue to develop and refine relevant NGWAF content as we observe exploitation attempts.

Recommended signals and clues to investigate

To mitigate the simpler upload progress bug, ensure session.upload_progress.enabled = Off in php.ini. 

For the more severe zend_bailout vulnerability, key patterns from the exploit and proof-of-concept traffic discovered to date include:

Reduce the attack surface through PHP configuration

• post_max_size = 8M — keeps POST bodies below the threshold needed to trigger an out-of-memory condition from a single request. Test against any workflow that accepts file uploads or large form submissions; 8M is PHP's default but many production deployments have raised it.

• max_input_nesting_level = 4 — limits deeply nested variable names, which are used in the hash-table exploit payload. Raise to 6 if the application uses complex nested form structures. Test form submissions that use array-style field names.

• session.upload_progress.enabled = 0 — disables the upload-progress tracking feature that triggers the session-related exploit paths. Only affects applications that show real-time upload progress bars using PHP's built-in session mechanism. Most applications that show upload progress use JavaScript-based approaches instead.

In HTTP traffic (WAF, proxy, or network inspection)

• Oversized form submissions. POST bodies using application/x-www-form-urlencoded above 1–2 MB. Legitimate form submissions are almost always under 100 KB. Multi-megabyte URL-encoded forms are rare enough to warrant investigation on any PHP-serving endpoint.

• Empty field names with deep nesting. POST bodies that begin with = (a field with no name) followed by a field name containing repeated [ bracket characters. This is the specific shape of the hash-table exploit payload.

• Upload-progress field names. Multipart file uploads containing a field named PHP_SESSION_UPLOAD_PROGRESS. This is a legitimate PHP feature, but it is also the trigger for the session-related exploit paths. Flag it for review on endpoints that don't use upload-progress tracking.

In application and web-server error logs

• OOM errors from PHP internals, not application code. Look for Allowed memory size ... exhausted with the location in Unknown on line 0. The Unknown file and line 0 mean the error fired during PHP's own request parsing, before any application script ran. An OOM from application code would name an actual file and line number.

• Segfault bursts. Clusters of Apache AH00052 ... exit signal Segmentation fault (11) entries in a short window. A handful of isolated segfaults are not unusual; dozens within minutes, followed by a single slow HTTP 200 response, match the address-recovery brute-force phase of the exploit.

In process monitoring (host-level)

• Apache/PHP workers spawning shell processes. Any mod_php worker executing /bin/sh -c ... as a child process. Under normal operation, mod_php workers never spawn child processes unless the PHP application explicitly calls a command-execution function (exec, system, shell_exec, etc.). If no application code ran (with currently-known exploits, no app code runs), treat a shell spawned from a PHP worker as the code-execution payload firing.

For PHP-FPM deployments

• pm.max_requests = 50 — forces worker processes to restart after 50 requests, which limits the window during which cross-request corruption (the session and data-conversion bugs) can be exploited. Does not prevent the hash-table bug, which exploits corruption within a single request. A value of 1 would prevent cross-request attacks entirely but at severe performance cost.

What’s next?

We know our customers entrust us with the resilience of their business-critical services, and core to our company's mission is to have your back when surprises like CVE-2026-109618 and CVE-2026-109619 erupt. Our teams are here for you as you navigate ongoing mitigation of php2shell – whether you’re a longstanding Fastly platform customer or new and in need of immediate protection. Let us know how we can help.

To recap:

• The weaponized mechanism — zend_bailout calling longjmp() to abandon in-progress operations — is present throughout the codebase and reachable from ordinary HTTP traffic. 

• Apply the patches quickly, and be aware that the patches reflect only the bugs found and exploited to date. 

• Expect in-the-wild attacks and novel variants to emerge this week and next at minimum. 

• The architectural condition that made them possible is a fundamental property of the engine's error-handling design, not a localized code “defect,” and it will remain after these patches ship.

We’re grateful to play our part in this community effort to protect the internet writ large. We are committed to continued collaboration as attacks unfold; we want our customers and the broader software ecosystem to move fast and stay safe. 

In the spirit of sustaining internet-wide resilience and ecosystem collaboration, Fastly will proactively monitor our global network for exploitation attempts of php2shell and offer subsequent updates of activity we see, similar to the insights we published during the React2Shell and Log4Shell incidents. Stay tuned.