php2shell/uaf-rce/README.md

CVE-2026-109618 / CVE-2026-109619: UAF via OOM Bailout

Use-after-free in PHP's session upload progress handler, exploitable over HTTP against Apache mod_php with default PHP configuration. No LFI, no framework dependency, no non-default settings.

Affected versions

PHP 5.4.0 through 8.3.35, 8.4.0 through 8.4.26, 8.5.0 through 8.5.11, running under Apache mod_php with prefork MPM.

Patched in PHP 8.3.36, 8.4.27, 8.5.12.

PHP-FPM is not vulnerable: FPM workers exit on bailout (code 70), so stale state never persists across requests.

Prerequisites

• Apache mod_php with prefork MPM (default on Debian/Ubuntu)
• session.upload_progress.enabled = 1 (default)
• memory_limit reachable via session data decode (~4MB for 33000 entries)
• Any PHP-handled URL (even a 404 page)
• A method to write a session file with many entries

No LFI. No specific framework or library. No non-default PHP settings.

How it works

CVE-2026-109618: OOM triggers longjmp past cleanup

When memory_limit is exceeded during session_decode() inside the RFC1867 progress callback, PHP calls zend_bailout() which executes a longjmp back to php_request_startup(). This skips php_var_unserialize_destroy(), leaving BG(unserialize).level = 1 and BG(unserialize).data pointing at a freed php_unserialize_data struct (8216 bytes, 3 ZendMM pages).

Apache prefork workers survive zend_bailout() and accept new connections with the stale state intact.

CVE-2026-109619: Stale state reused on next request

On the next request, sapi_activate() runs the RFC1867 callback BEFORE PHP_RINIT_FUNCTION(basic) has a chance to zero BG state. The callback calls php_session_decode(), which calls php_var_unserialize_init(). That function sees BG(unserialize).level > 0 and returns the stale .data pointer without allocating a new struct.

This is a use-after-free: the pointer was freed when the previous request's heap was destroyed during zend_deactivate().

Phase 1: Plant session file

A session file with 33000 entries (~682KB) is planted. When decoded, this forces nTableSize = 65536, requiring an arData allocation of 65536 * 36 = 2,359,296 bytes (~2.25MB). With memory_limit = 4MB, this exceeds the limit during HashTable resize.

Phase 2: OOM trigger

A multipart POST with PHP_SESSION_UPLOAD_PROGRESS and a file field triggers the RFC1867 progress callback. The callback reads the planted session file and calls php_session_decode(). The decode triggers OOM during HashTable resize. zend_bailout() longjmps past php_var_unserialize_destroy().

After bailout:

• BG(unserialize).level = 1 (should be 0)
• BG(unserialize).data = freed heap pointer
• php_session_cancel_decode() deletes the session file
• Worker survives, serves new connections

Phase 3: UAF crash

Another multipart POST (no intermediate GET requests, which would zero BG state via PHP_RINIT_FUNCTION) includes 100 filler form fields of 8200 bytes each. Each field becomes a 3-page zend_string allocation. The allocations consume ZendMM pages sequentially through the chunk, eventually reclaiming the 3 pages where the stale struct resided (typically page ~288 of 512).

The zend_string GC header (8 bytes: refcount + type_info) at offset 0 of the allocation overwrites the struct's last pointer (a var_entries*). When the session decode calls var_push(), it reads last and dereferences the GC header value as a pointer:

var_entries *var_hash = (*var_hashx)->last;  // GC header, not a valid address
var_hash->data[var_hash->used_slots++] = rval;  // SIGSEGV

The worker segfaults, confirming the use-after-free.

Exploitation status

Confirmed primitives:

Primitive	Status
OOM during RFC1867 session decode	Confirmed
Apache prefork worker survival after OOM	Confirmed
Stale BG(unserialize) state across requests	Confirmed (level=1, data=freed ptr)
Page reclamation via filler field spray	Confirmed (100 x 8200B = 300 pages)
UAF crash (SIGSEGV in var_push)	Confirmed (first attempt, reproducible)

Not achieved: full RCE.

The struct's critical pointer fields (offsets 0-23) overlap with the zend_string GC header and cannot be controlled by the attacker:

Struct field	Offset	Overlaps with	Value
last	0	gc_refcount + gc_type_info	~0x00000306_00000001 (invalid pointer)
first_dtor	8	hash	0 (lazily computed, safe)
last_dtor	16	len	8200 (low address, crash)

Controlled bytes start at offset 24 (allowed_classes, ref_props, max_depth, entries.used_slots, entries.next, entries.data[]), but var_push crashes at offset 0 before reaching them.

Full RCE would require either an info leak to construct a valid pointer in the GC header position, or a different allocation type that provides control over the first 24 bytes of an 8216-byte ZendMM allocation.

Usage

python3 exploit.py --target http://host:port/index.php
python3 exploit.py --target http://host:port/index.php --oom-only

Options

Flag	Default	Description
--target	(required)	Target URL (any PHP endpoint)
--session-path	/var/www/uaf-test/sessions	session.save_path on the target
--entries	33000	Entries in OOM session file
--spray-fields	100	Filler fields for crash trigger
--oom-only	off	Stop after Phase 2

The patch

The fix (PHP 8.3.36, 8.4.27, 8.5.12) adds three independent defense layers. Any one of them blocks the attack:

1. php_basic_early_rinit(): Called from php_request_startup() AFTER zend_activate() but BEFORE sapi_activate(). Zeros BG(serialize_lock), BG(serialize), and BG(unserialize) with memset. Eliminates the stale state window entirely.

2. Delayed OOM: zend_bailout() on OOM is removed. The allocator either returns NULL (fallible mode) or succeeds beyond the soft limit (non-fallible mode) and queues a delayed error. No longjmp, so all cleanup code runs normally. A hard limit calls _exit(137).

3. Session handler hardening: RFC1867 session decode runs in incomplete_classes_only mode (no __wakeup/__unserialize). php_rinit_session_globals() at MULTIPART_EVENT_START. $_SESSION cleanup at MULTIPART_EVENT_END.

Test environment

Tested on PHP 8.3.35 (built from source as Apache module), Apache 2.4.58 (prefork MPM, MaxRequestWorkers=1), Ubuntu 24.04, x86_64.

php_admin_value memory_limit 4M
php_admin_value session.upload_progress.enabled 1
php_admin_value session.upload_progress.cleanup 0

References

• CVE-2026-109618: OOM during multipart parsing triggers longjmp
• CVE-2026-109619: Session globals survive across requests
• CVSS: 9.2 (both CVEs, per Rapid7)