Simple Analogy First (for a non-technical person)

Imagine a busy restaurant kitchen (the PHP web server) that handles customer orders (HTTP requests).

Each order uses tables, cutting boards, and recipe cards (memory).

Normally, when an order finishes or fails, the kitchen carefully cleans everything and resets the stations before the next customer.

An attacker sends a specially crafted “poison order” that deliberately fills the kitchen with so much junk that it runs out of space (Out-Of-Memory error).

Instead of cleaning up properly, the head chef just yells “STOP!” and abandons the order mid-way (this is the zend_bailout() + longjmp() jump).

Dirty tables, half-written recipe cards, and leftover ingredients stay exactly where they are.

When the next real customer arrives, the kitchen starts cooking on the dirty, poisoned stations. This can:

• Reveal secret recipes left on the tables (memory disclosure)
• Let the attacker swap the recipe cards for their own instructions (code execution / remote shell)

That is the core of “PHP2Shell.”

PHP2Shell attack — turned into a chaotic cyber-kitchen war scene

High-Level Attack Flow (Easy Visual Steps)

1. Attacker sends a specially crafted HTTP multipart request
   (no Content-Length + nested file upload with empty filename)
          │
          ▼
2. PHP tries to process the request and allocate memory for file metadata
          │
          ▼
3. Memory runs out → Out-Of-Memory (OOM) error
          │
          ▼
4. PHP calls zend_bailout() → abrupt longjmp() jump
   (abandons the request WITHOUT proper cleanup)
          │
          ▼
5. Memory is left in a broken state
   • Array counters already increased, but data never written
   • Global states (session, backtraces, etc.) never reset
          │
          ├──────────────────────────────────────┐
          ▼                                      ▼
   CVE-2026-109618                          CVE-2026-109619
   (same request / array cleanup)           (across multiple requests)
          │                                      │
          ▼                                      ▼
6a. During cleanup of $_POST array:         6b. Next request arrives on same
    PHP treats garbage memory as valid           worker process
    → can redirect function pointers             → uses poisoned global state
    → Remote Code Execution                      (e.g. fatal_error_backtrace)
                                                 → Use-After-Free → control memory
          │
          ▼
7. Bonus: Session ID can point to freed memory
   → Attacker gets a second request that returns
     heap addresses inside the PHPSESSID cookie
     (helps defeat ASLR protections)

Why This Is Dangerous

• It works remotely (just by sending HTTP requests).
• It can lead to full remote code execution (the attacker gets a shell on the server).
• One of the paths also leaks memory addresses, making further exploitation easier.

The two CVEs simply fix different places where this “abandon without cleanup” problem was happening.

Summary:

By forcing PHP to run out of memory with a weird request, the attacker makes PHP abandon the work half-done. The leftover “dirty” memory can then be used to either steal secret addresses or force the server to run the attacker’s own code.