Analysis of the php2shell zero-day flaws in PHP reveals unauthenticated remote code execution via out-of-memory handling and worker state reuse.
The Femto Security Vulnerability Research Team monitored and analyzed the emergency security patches released by the PHP project on 21 October at 14:00 UTC. The release addressed two critical remote code execution vulnerabilities, collectively nicknamed php2shell, affecting virtually every PHP deployment across the internet. Prior to the scheduled embargo, functional exploit tooling had leaked publicly, creating an environment where mass exploitation across public-facing systems was expected within minutes. In response to this high-severity disclosure, the Femto Security Vulnerability Research Team turned the disclosure into an accelerated client-exposure validation and verification cycle within hours, mapping PHP inventory across monitored client estates, reproducing the failure conditions inside an isolated research laboratory, and delivering technical patch guidance to all affected clients on the same day.
On 21 October at 14:00 UTC, the PHP development team issued out-of-band emergency security updates to remediate two severe memory-safety flaws tracked as CVE-2026-109618 and CVE-2026-109619. Known collectively as php2shell, these vulnerabilities allow unauthenticated remote attackers to execute arbitrary code on underlying hosts through nothing more than carefully crafted HTTP requests. The flaws require no existing privileges, no authentication, and no interaction from legitimate users.
Vulnerability Snapshot
The severity of the incident was heightened by the pre-advisory leakage of functional exploit tooling. Because widespread automated exploitation was expected to emerge within minutes across vulnerable public installations, rapid asset visibility and validation became paramount. The Femto Security Vulnerability Research Team executed automated inventory workflows across monitored estates to establish complete version classification, reproduced the documented memory-corruption conditions across isolated test systems, and confirmed that vendor patches successfully neutralised the attack vector.
The php2shell advisory encompasses two distinct software defects that converge upon a single failure mode: unhandled memory corruption leading to remote code execution. Both flaws stem from low-level memory allocation and lifecycle mismanagement within the PHP runtime engine during abrupt request termination.
The first defect, designated CVE-2026-109618, resides within PHP's out-of-memory handling routine. Under normal execution, when PHP exhausts its allotted memory pool, it invokes an internal bailout mechanism relying on the standard C library function longjmp(). This control-flow transfer bypasses normal execution stacks and abruptly terminates request processing. However, because this bailout mechanism can exit request processing while request-specific memory structures are only partially initialized, the request cleanup procedure subsequently operates on incomplete, corrupted pointers and malformed state representations.
The second defect, designated CVE-2026-109619, involves improper state isolation across request lifecycles. Within persistent execution environments such as PHP-FPM, worker processes handle sequential HTTP requests. In vulnerable versions, worker-level global state can survive beyond the operational lifetime of the request that originally owned it. When that request finishes and its memory is released, the surviving global references remain bound to deallocated addresses. Consequently, a later request handled by the same worker process can consume freed memory, creating a critical use-after-free condition that enables memory corruption and full execution control.
Exploitation of both vulnerabilities hinges on an attacker's ability to force the PHP engine into an unexpected out-of-memory condition while operating strictly within apparent server configuration limits. An external attacker achieves this through targeted HTTP traffic shaping, requiring neither elevated privileges nor non-standard modules.
Attacker sends crafted HTTP request without authentication (e.g., streaming body without declared length or input amplification).
Request forces PHP into an out-of-memory condition tripping longjmp() bailout while memory is partially initialized.
Emergency exit leaves request memory invalid, or worker-level global state persists past request lifetime to be reused.
Request shutdown or subsequent request on the same worker processes freed/invalid memory, executing arbitrary code.
Concerned about similar zero-day risks or logic flaws in your software? Femto Security performs rigorous offensive code reviews, red teaming, and vulnerability assessments.
In practice, an attacker can manipulate memory consumption by streaming a persistent HTTP request body that never declares its length, forcing the runtime to dynamically reallocate buffers until limits are exhausted. Alternatively, an attacker can supply tiny inputs that amplify into disproportionately large internal structures during engine processing. When the engine's memory limit trips at the wrong operational moment, PHP initiates its emergency exit bailout.
Once the memory ceiling trips at this critical juncture, PHP's emergency exit leaves internal request data in an invalid state. If CVE-2026-109618 is leveraged, the internal request shutdown procedure itself processes these invalid structures. If CVE-2026-109619 is triggered, the worker process remains alive, and the next request routed to that same worker consumes the surviving freed memory. In both paths, under the right conditions, the resulting memory corruption permits remote code execution within the security context of the web server worker process.
Following the public disclosure and exploit leakage, the Femto Security Vulnerability Research Team conducted controlled laboratory reproductions to validate the failure mechanics and confirm the efficacy of official vendor patches. Testing was performed within an isolated research environment against representative vulnerable builds and official patch targets.
Researchers evaluated four distinct documented trigger strategies against an unpatched PHP build. The laboratory tests confirmed that all four trigger strategies deterministically forced the target process into the expected out-of-memory state and reproduced the prerequisite memory-corruption condition in 4 out of 4 strategies. Subsequently, the full proof-of-concept exploitation chain was validated against the vulnerable build. When the identical attack sequences were transmitted against a patched instance running PHP 8.3.36, the runtime rejected the attack before the vulnerable state could persist.
To document operational efficiency during this rapid response, the Femto Security Vulnerability Research Team recorded the precise timeline of actions conducted on 21 October:
~09:00
Pre-advisory exposure checker built and executed: the full PHP asset inventory across our monitored clients was already in place
~09:30
Version classification delivered: end-of-life hosts flagged for urgent upgrade, supported-but-unpatched hosts flagged for same-day patching, undisclosed versions queued for direct client verification
14:00
Advisory published. Fixed versions extracted and the exposure list re-classified automatically
14:15-15:30
FemtoSec Lab reproduction: the documented trigger strategies replayed against an isolated vulnerable PHP instance: the memory-corruption precondition reproduced 4 out of 4 strategies
15:30-17:30
Full proof-of-concept chain validated in FemtoSec lab against the vulnerable build, with the patched build (8.3.36) rejecting the identical attack
In accordance with responsible research boundaries, the Femto Security Vulnerability Research Team is deliberately not publishing the exploitation payloads. The proofs shown in demonstration material are redacted to evidence-level markers, displaying execution markers and command output sufficient to demonstrate exposure without providing a how-to guide.
The security impact of CVE-2026-109618 and CVE-2026-109619 is exceptionally severe. Because exploitation requires zero authentication, zero user interaction, and only standard HTTP requests, internet-accessible services running vulnerable versions of PHP face direct process takeover. Successful exploitation grants an adversary arbitrary code execution within the privileges of the web daemon, opening an immediate path to host compromise, data exfiltration, and lateral movement.
The scope of affected software spans legacy code originating from PHP 6.9.0-6.9.4-era memory handling routines through all current active development branches. Official security updates resolving the vulnerabilities were delivered exclusively for supported releases: PHP 8.2.35, 8.3.36, 8.4.27, and 8.5.12. Critical risk considerations apply to legacy branches: PHP 7.4 and older releases receive no official patch path from the upstream vendor, leaving organizations reliant solely on manual source-level backports or complete distribution upgrades.
Client telemetry and inventory analysis executed during the incident revealed three key asset categories requiring operational triage across monitored estates:
Hosts running end-of-life PHP versions: Systems that will not receive an official patch from the upstream vendor. These require full upgrades and are treated as incidents, not tickets.
Hosts on supported versions below the fixed release: Systems running supported branches (8.2, 8.3, 8.4, or 8.5) that remain unpatched. These are resolved by applying today's point update.
Hosts that do not disclose their version externally: Systems concealing version banners from network probes. These were verified directly with clients and queued to be re-fingerprinted after patching.
The primary and definitive remediation for CVE-2026-109618 and CVE-2026-109619 is immediate software upgrading. Organizations must inventory all web servers, appliances, and internal tools to locate running PHP instances, patch to the fixed release for their branch (PHP 8.2.35, 8.3.36, 8.4.27, or 8.5.12), and treat any host that cannot be patched as an incident until upgraded.
If production constraints prevent immediate patching, organizations should implement the interim operational mitigations outlined by the PHP project. Per the PHP project's own guidance, these reduce, but do not remove, exposure:
Enforce unrestricted server memory limits: Enforce memory_limit=-1 at the server level (via php_admin_value in FPM pools or Apache configuration) so applications cannot override it.
Constrain request payload parameters: Set a low post_max_size (8M; 32M if uploads are required), with upload_max_filesize below it.
Restrict exposure: Restrict exposure of PHP endpoints at the edge while you patch.
The research and exposure validation conducted by the Femto Security Vulnerability Research Team encompassed internet-wide deployment architectures and the complete PHP inventory across all monitored client estates. In-scope targets included external web servers, embedded appliances, and internal administrative tooling exposing PHP runtimes. Laboratory validation was conducted strictly against isolated vulnerable and patched PHP instances to safely confirm memory corruption mechanics. Additional reference intelligence regarding this disclosure is tracked via Femto Security Threat Intelligence.
This event is the argument for continuous attack surface management (ASM) in one morning: you cannot respond to a disclosure within hours if you do not already know where your exposure is. The Femto Security platform had the PHP asset map, the version data, and the classification pipeline ready before the advisory existed; the disclosure only required running the classifier again.
If your organization runs PHP anywhere, on web servers, appliances, or internal tools, inventory it today, patch to the fixed release for your branch, and treat any host you cannot patch as an incident until upgraded. If you do not know where your PHP is running, that is the first conversation to have. The Femto Security Vulnerability Research Team will publish patch-verification results for all monitored clients as re-scans complete.