Attackers attempted to exploit PHP2Shell four days before public disclosure and patch availability, according to an October 24 report by Security Affairs’ Pierluigi Paganini, citing AWS researchers’ honeypot observations. The detected attempts do not establish that servers were successfully compromised.
PHP’s two official advisories, published October 21, 2026, describe critical memory-handling vulnerabilities that can enable remote code execution. Both list fixes in PHP 8.2.35, 8.3.36, 8.4.27 and 8.5.12, with earlier versions in the respective release branches affected. The precise exploitation conditions vary by vulnerability, server interface, application and configuration.
Successful exploitation could let an attacker run commands with the web worker account’s permissions. Paganini described possible consequences including data theft, malware installation, website changes and service disruption. These are potential impacts, rather than confirmed outcomes of the reported attempts.
Memory exhaustion can expose invalid request state
The first vulnerability, CVE-2026-109618, concerns PHP’s use of longjmp() to abandon request processing after an out-of-memory error. If that exit occurs while request memory is only partly initialized, shutdown processing can encounter invalid state and lead to remote code execution.
The advisory describes several ways multipart requests can exhaust memory despite apparent input limits. These include requests without a usable declared content length, unrestricted headers within individual parts, and empty file controls that create metadata without counting toward max_file_uploads. Application-specific processing of attacker-controlled input can also exhaust memory.
PHP’s advisory says unauthenticated remote code execution was validated over HTTP against Apache mod_php using default PHP input and memory limits and normal prefork configurations with multiple workers. Automatic request-body parsing can trigger the problem before application code runs. Additional workers and unrelated traffic can increase the attempts required, while reliability depends on the PHP build, extensions, frontend behavior and allocator layout.
The evidence differs for other deployment types. FPM terminates a child when request startup fails, preventing that startup path from consuming invalid state. Source analysis nevertheless indicates susceptibility after normal startup, although no complete FPM exploit was demonstrated. The advisory considers FrankenPHP likely susceptible to application-independent attacks, while application-specific exploitation through LSAPI is considered likely but remains unvalidated.
Stale state can cross request boundaries
The second vulnerability, CVE-2026-109619, involves worker-level state retaining references to memory belonging to a completed request.
Exploitation requires an operation that leaves request-owned state accessible after that memory is released, followed by another operation that uses the stale state before normal initialization clears it. In the demonstrated case, those operations occur in different HTTP requests handled by the same worker.
Fatal errors, including memory exhaustion, can interrupt cleanup. Nonfatal diagnostics can also repopulate error state after it has been cleared. A carefully arranged heap can turn the resulting use-after-free into remote code execution. Reachability depends on the particular state, application, extensions and configuration.
Updates provide the complete remedy
Both advisories direct operators to the patched releases in their respective PHP branches:
- PHP 8.2: 8.2.35
- PHP 8.3: 8.3.36
- PHP 8.4: 8.4.27
- PHP 8.5: 8.5.12
The issuer says updating is the only complete mitigation for the memory-exhaustion flaw and the only reliable mitigation for the stale-state flaw.
For installations unable to update, administratively enforcing memory_limit=-1 removes the predictable per-request limit used by the confirmed memory-exhaustion exploit. Every PHP worker must be restarted, and operators must ensure that pool, directory or application settings do not restore a finite limit. This remains incomplete protection: underlying allocation failures can still trigger the vulnerable path.
PHP explicitly warns against using RLIMIT_AS or RLIMIT_DATA, because they can cause mmap() failures that trigger that path. Container or cgroup memory limits are also incomplete mitigation and may terminate multiple workers or the master process.
For PHP 8.5, setting fatal_error_backtraces=0 administratively and restarting every worker removes the producer used in the confirmed stale-state RCE case. It does not cover other global or extension state; the advisory says no generic configuration change provides complete protection.
The issuer also recommends conservative post_max_size settings, independently enforced decoded request-size limits at the frontend, and bounds on input nesting, variables, multipart parts, per-part headers and uploads. Applications that do not use multipart form data can block it at the frontend. These controls reduce risk but do not replace updates.
In his October 24 report, Paganini urged operators to review suspicious activity dating back to October 17. He also discussed how AI could accelerate exploit development, while cautioning that attacks should not automatically be assumed to be AI-driven.
