Generalizing the exploitation of memory vulnerabilities is a tricky business… but large language models can help.
Wiz notes as much in its overview of PHP2Shell.
The Google subsidiary didn’t single-handedly uncover this family of critical flaws that strike at the heart of PHP. It did, however, take a lead in the narrative, going so far as to create the website php2shell.com — and touting, in passing, the “invaluable” contribution of the Gemini 4 Argon model.
The PHP project offers a more neutral viewpoint in its security bulletin. It does not downplay the urgency of the situation: all installations serving web requests are exposed to unauthenticated remote code execution. Wiz cites 70% of websites. The Unit42 team at Palo Alto Networks puts the potentially vulnerable footprint at 22.6 million instances.
The PHP security team has patched all supported minor versions (8.5, 8.4, 8.3 and 8.2). Given the severity, it provides minimal source-code backports for PHP 8.1, 8.0 and 7.4.
Two vulnerabilities, many attack paths
1. Memory exhaustion (CVE-2026-109618)
When a memory exhaustion event occurs, a longjmp() jump interrupts processing. However, if this saturation happens during the request initialization phase, PHP does not handle the premature exit properly: it leaves the memory in a corrupted state. The request shutdown procedure can then read these invalid data, opening the door to arbitrary code execution.
Several strategies can trigger this condition, including manipulating headers, content length or metadata. Apache mod_php and FrankenPHP are particularly vulnerable, as they unconditionally execute the shutdown procedure before any application code runs.
The reliability of the exploit depends on how PHP was built, which extensions are enabled, how the front-end server behaves and how the memory allocator is arranged.
The fix removes the use of longjmp() in the case of memory exhaustion. It replaces it with a deferred shutdown, triggered at the next safe VM checkpoint. Alternatively, if memory usage crosses a higher threshold, an immediate emergency shutdown is performed using _exit().
Main bypass methods
When a patched version cannot be installed, the primary mitigation is to set memory_limit=1. This neutralizes several attack paths. In return, memory management is delegated to the operating system. It is also common to rely on the memory.max directive of cgroups (or an equivalent mechanism) to contain resource consumption and limit the impact on availability to only PHP processes. In any case, ensure that no pool, directory or application setting reestablishes a finite memory limit.
This measure does not solve everything. If mmap() or another underlying allocation fails, PHP can still use longjmp() while the partial request memory remains accessible.
Another mitigation: keep a prudent value for post_max_size. For applications that don’t need file uploads, set it to 8M. Otherwise, 32M. At the same time, consider reducing the nesting level (max_input_nesting_level). And cap the number of input variables, multipart sections, headers per part and uploaded files.
2. Redirecting global states (CVE-2026-109619)
In PHP, a persistent worker keeps global state structures (sessions, objects, extensions…), but they point to memory areas allocated for the current request.
That memory is freed without the global state being properly reset first. When the same worker handles a new request, early operations (input processing, applying configurations, raising errors…) run and access these residual pointers.
By controlling the layout of the heap, one can manipulate the data reallocated to that spot. And thus divert the instruction flow to execute arbitrary code.
Two confirmed RCEs
There are several triggering strategies. At least two RCEs have been confirmed. One relies on the fatal_error_backtraces directive. When enabled, fatal error reporting stores a request-scoped call-stack state. Resetting this global state is systematically omitted during shutdown. This scenario, the PHP project deems the strongest, forms the basis of the confirmed exploitation on mod_php.
The other RCE path, validated on mod_php and on FPM, goes through the upload progress tracking. Processing can initialize the session state early and publish a session identifier in PS(id). If a fatal error occurs later, PHP can destroy the request heap while PS(id) continues to reference it.
Main bypass methods
Primary mitigation, which CERT-FR also highlights: set session.upload_progress.enabled to 0. This can be done via the .ini file, a pool’s FPM configuration or a server setting applied before request analysis. The setting disables upload progress tracking.
Specifically for PHP 8.5, you can disable fatal_error_backtraces. Another option, applicable to all versions: set display_errors=0 to prevent exposure of PHP error messages to remote users.
Downstream, fixes implemented with varying degrees of thoroughness
The Dutch CERT (NCSC-NL) maintains a list of potentially affected third-party software.
Platform-as-a-Service providers proved particularly proactive. Scalingo is among them. In addition to announcing patched versions, they revisit their remediation approach, starting with disabling the tracking of uploads and then blocking multipart requests for all applications.
Heroku also took the necessary steps, applying backported fixes… but only for PHP 8.1. Upsun (formerly Platform.sh) has pushed the fix up to PHP 7.4. Unlike Scalingo and Heroku, it has automatically redeployed the affected environments.
At Netgate, the fix is available for pfSense security gateways. It requires command-line installation. The company notes that by default the GUI is accessible only on the LAN, while the captive portal (intended for external users) is disabled.
Palo Alto Networks classifies PHP2Shell as a moderate-urgency issue for its products. The vulnerabilities affect all currently supported versions of PAN-OS and Panorama. In line with Netgate, the organization notes that the risk is higher if external IPs can reach the management interface. It also recommends deploying a jump box.
While awaiting corrected versions of PAN-OS and Panorama, Palo Alto Networks recommends mitigations… including virtual patching restricted to its ATP Plus customers.
CMSs, the guinea pigs of PHP2Shell
Among the software confirmed vulnerable are many CMS platforms. Beginning with Drupal, Joomla and WordPress. Wiz focused its exploit demonstration on these three.
The CVE-2026-109618 flaw affects all three CMSs. The CVE-2026-109619 affects Drupal via backtraces and WordPress through a shared PHP state corruption (type confusion on OPcache).
The Google subsidiary says it was the first to discover PHP2Shell, on August 19, and reported it to the PHP project on August 24. Among a handful of external researchers it credits for contributions, one offers a different timeline. Not necessarily in conflict, but indicative of a convergence of work.
The researcher in question works at Calif, a company specialized in offensive security. He frames his discoveries within OpenAI’s Daybreak program. And specifically the Patch the Planet initiative, which had invited him to join in late July. PHP was then among the targets of interest. He reported an initial bug to the project on August 11, and on August 14 forwarded a confirmed functional PoC the following day.
