Alexandre Daubois, a member of PHP’s security team, follows the PHP2Shell rumors down into the allocator. His account explains how a memory limit became a corruption trigger, and why a widely repeated configuration fix addressed a different vulnerability.

  • An error path can break an invariant. Exceeding memory_limit called longjmp(), abandoning the C function that requested memory. Request shutdown could then traverse pointers to structures whose initialization had never finished.
  • Attackers could choose the interruption point. Multipart request parsing offered ways to consume memory before application code ran, including large numbers of part headers and metadata for empty file inputs.
  • The fix separates detection from unwinding. Crossing the soft limit records an error while allocation continues. PHP can finish building structures before stopping at a controlled checkpoint. A separate hard limit terminates the process outright.
  • Mitigations belong to specific code paths. Disabling session.upload_progress.enabled addressed the companion session vulnerability. Treating both CVEs as one bug obscured which protection actually applied.

Failure handling belongs in the design of shared state. Once a pointer becomes reachable, every exit path must leave its target safe for cleanup. A nonlocal jump from deep inside an allocator makes that promise difficult to keep across a runtime.

Daubois also supplies a practical incident-response habit: trace a proposed workaround to the exact mechanism it blocks. The counterintuitive memory-limit stopgap in this account is an explanation of the bug, not a substitute for installing the patched runtime.