What the PHP2Shell rumors got wrong, from inside the PHP security team

CVE-2026-109618, dubbed PHP2Shell in early leaks, actually pins down an out-of-memory handling change whose severity was real but whose RCE narrative was wrong. The core issue is that memory_limit became a soft limit: crossing it records a pending error and returns from C allocation functions with internal structures intact, then PHP raises an UnwindExit only when the VM next checks for interrupts. That behavior lets multipart parsing stop cleanly between parts and free what was built instead of leaving corrupt state that an attacker could exploit to achieve arbitrary code execution. A new hard-limit mechanism, memory_hard_limit_percent (defaulting to 200% of memory_limit for totals below 1 GB, e.g., 256M when memory_limit is 128M), forces an immediate process exit with _exit(137) if allocations exceed that threshold.

Fixes required broad changes - about 390 files - because many C allocation sites assumed an OOM would not return. Patched releases are 8.2.35, 8.3.36, 8.4.27 and 8.5.12; timeline shows the advisory opened 2026-08-27, a fix PR in late September, and public leak on 2026-10-20-21. Practical takeaways: the vulnerability does not enable the dramatic RCE scenarios widely reported, but out-of-memory still kills workers without corruption, so services that accept multipart bodies should limit parts and headers at the frontend. The hard-limit behavior aligns PHP more with Go and Rust runtimes that abort on allocation failures, while C++-style bad_alloc risks remain relevant for extensions.