PHP2Shell Explained: PHP2Shell Was in the Training Data

Emergency PHP releases fixed two critical engine defects (CVE-2026-109618 and CVE-2026-109619, collectively PHP2Shell) that let unauthenticated attackers leak live server memory and execute shell commands on default PHP deployments. The root cause is reuse of persistent C worker processes with per-request heaps and PHP’s use of longjmp() to abort on fatal errors. Attackers can force out-of-memory bailouts during multipart/form-data parsing by exploiting missing length checks, header amplification, and nested empty file fields to blow past post_max_size while staying under limits. That yields two exploitable behaviors: one where a hash table counter is incremented before allocation, leaving an uninitialized slot whose contents are later treated as a live object and invoked during cleanup (remote code execution), and another where early upload-progress code runs before module initialization so a crash leaves dangling global pointers that the next request reads, leaking memory (Heartbleed-style) and enabling forged C structures to hijack execution. Working exploits hit stock WordPress, Drupal, Laravel, MediaWiki, Nextcloud, Roundcube and more.

The discovery narrative that frontier models “found” this decade-old bug is misleading: the vulnerable source, prior primitives and bug reports were public and present in training data, and a human researcher weaponized the pattern. Short-term mitigations like disabling upload progress are insufficient, so core architectural changes were shipped: remove longjmp()-based OOM handling in favor of a soft-OOM flag and hard exits, and unconditionally reset request-owned globals before pre-initialization parsing. Many internet hosts still run EOL PHP releases, leaving a large exposed population despite patches.