PHP2SHELL // CORE ENGINE ARTIFACT

Web security culture has spent thirty years teaching developers to validate input, sanitize parameters, and avoid dangerous functions like eval() or system(). PHP2Shell made every single application-level defense irrelevant overnight.

In October 2026, security researchers at Wiz Research, Calif, and AI-driven static analysis models (Gemini 4 Argon and GPT-5.6 Sol) identified two critical flaws in the C-core of PHP itself. Before the web server hands an HTTP request to application code (e.g. index.php), the Server Application Programming Interface (SAPI) must initialize the interpreter context (PHP_RINIT) and parse incoming request streams. If an unauthenticated attacker triggers memory exhaustion during this internal C-level parsing phase, the Zend Engine aborts execution via a non-local longjmp() jump, corrupting internal structures before the application even wakes up. The global panic prompted emergency shutdowns of governmental identity portals (Dutch DigiD and MijnOverheid), emergency NCSC-NL advisories, and an urgent race to patch ~70% of the public web.

In standard Unix programming, when an allocation fails, malloc() returns NULL, or an out-of-memory handler terminates the thread cleanly. The Zend Engine implemented an optimization that turned out to be fatal.

When an HTTP client sends an enc-type of multipart/form-data, PHP's SAPI layer parses headers, boundaries, and field names in native C. Attackers discovered that by sending thousands of empty file parts (bypassing max_file_uploads because empty files are not counted as uploaded files), deeply nested field array names, or repeated headers per boundary part, the SAPI parser consumes memory up to the configured memory_limit. Crucially, this happens without exceeding post_max_size! In environments like Apache mod_php and FrankenPHP, where request parsing runs directly in the persistent web server process, hitting an Out-Of-Memory (OOM) error at this precise moment triggers zend_bailout(), which bypasses graceful shutdown and throws the engine into an unrecoverable half-initialized state.

The C standard library function longjmp() restores the environment saved by the most recent setjmp() invocation. It is non-local: it cuts across function boundaries without unwinding call frames.

When Zend's memory manager (zend_mm) exhausts its allocation ceiling during pre-app parsing in rfc1867_post_handler(), it calls zend_bailout(). Instead of returning an error code up the call stack, zend_bailout() executes longjmp() directly into the outer zend_try checkpoint, which subsequently enters the request shutdown routine (PHP_RSHUTDOWN). Because the jump happens mid-execution without invoking intermediate stack frame destructors, complex internal C structures (such as hash tables, file descriptor tracking lists, and object descriptors) are left in a partially initialized ("half-baked") state. Crucially, PHP_RSHUTDOWN assumes that every structure registered during request initialization is valid and unconditionally dereferences their pointers to free them! By carefully arranging the heap before the OOM bailout occurs, an attacker causes PHP_RSHUTDOWN to treat arbitrary attacker-controlled memory as valid pointers, turning a memory exhaustion error into type confusion and arbitrary code execution.

Modern high-performance web architectures avoid process creation overhead by using persistent worker pools (PHP-FPM, mod_php, FrankenPHP). Each worker process serves hundreds or thousands of sequential HTTP requests.

CVE-2026-109619 exposed a catastrophic flaw in how PHP handles global worker state across sequential requests. When Request #1 terminates abnormally (e.g. via an OOM bailout or fatal error), the Zend memory manager frees all request-scoped heap memory. However, several internal engine components—most notoriously session.upload_progress (which is enabled by default in standard PHP configurations even if the application never uses sessions!) and fatal_error_backtraces in PHP 8.5—store pointers in global worker variables. Because the abnormal bailout aborted the code before it could zero out these global pointers, they remain pointing to memory addresses that were just freed (classic dangling pointers). When Request #2 arrives from a completely different user and lands on that same worker, the engine references this stale global pointer prior to standard initialization, triggering an unauthenticated Use-After-Free (UAF).

Because CVE-2026-109618 and CVE-2026-109619 exist inside the C binary of the interpreter itself, no amount of PHP code refactoring, input sanitization, or framework middleware can protect an unpatched server.

True immunity requires structural guarantees at the runtime engine, web server SAPI, and operating system layers. The PHP development team solved CVE-2026-109618 by replacing the dangerous non-local longjmp() bailout with graceful OOM handling at safe VM checkpoints, coupled with an unconditional _exit() termination if memory exceeds a hard panic threshold. For CVE-2026-109619, the engine now strictly zeroes and invalidates all global worker pointers during shutdown. Organizations unable to update binaries immediately must apply emergency temporary mitigations: disabling session.upload_progress.enabled in php.ini, disabling fatal_error_backtraces, tuning memory_limit comfortably above post_max_size, migrating from mod_php to isolated PHP-FPM pools with aggressive worker recycling (pm.max_requests = 500), and filtering anomalous multipart headers at the Cloudflare / WAF edge.