select a file from the tree to inspect source
Two cached bucket pointers, one freed tree. A heap use-after-free in PHP session.upload_progress reaching zend_call_function.
PHP's session.upload_progress handler (php_session_rfc1867_callback in
ext/session/session.c) caches two raw zval * bucket pointers into live HashTables:
post_bytes_processed and current_file_bytes_processed. Both point into
arrays that the request lifecycle frees under the attacker's feet. Press [SOURCE]
above to walk the full bundle: the trigger request, both PoC chains, the extraction harness, and
the validated per-build symbol deltas.
Stock configuration is enough. session.upload_progress.enabled=1 and the default name,
prefix, freq=1%, min_freq=1. A single fast multipart POST arms both caches;
a second update() re-reads the session file and zend_hash_update destroys the previous
decoded tree through its HashTable destructor zval_ptr_dtor. The freed bucket is then
reclaimed and the stale pointer lands an attacker-shaped zend_fcall_info /
zend_internal_function that calls zend_call_function, i.e. system().
All of the following is verified against real php-src (8.4.4 and 8.2.34):
every line reference in the original writeup, the ZVAL_COPY_VALUE no-addref moves, the
re-decode/track_init free, and the struct offsets (zend_fcall_info 64B with
param_count at +48, zend_internal_function.handler at +88,
IS_STRING_EX 0x106, IS_OBJECT_EX 0x308).
The framework in this post bakes in per-build delta extraction (--syms) because the
offset between zval_ptr_dtor and zend_call_function changes with every
build. Official LiteSpeed lsphp82 8.2.34 debug symbols give the exact values for the
three distro sub-builds (bookworm 0xc930, noble 0xcef0, jammy 0xd060) and are included below.
Click directories to expand · click files to view content
view select a file
select a file from the tree to inspect source
How to Validate, Extract & Deliver the Chain
$ python3 php_up_framework.py --selftest # forge + body layout checks
$ python3 php_up_framework.py --syms --binary /path/to/lsphp # extract dtor / call / delta
$ python3 php_up_framework.py --build --bug 619 --dtor <leak> -o body.bin
$ python3 php_up_framework.py --lab --bug 618 --dtor <leak> # php-fpm lab delivery
$ python3 php_up_framework.py --live <target-url> --bug 619 --dtor <leak>
What to do before the official advisory ships. You can do all of this tonight.
Know every host and version (php -v). Anything on PHP 7.x or older won't get a fix, so plan to upgrade.
In php.ini / .user.ini / .htaccess:
session.upload_progress.enabled = Off
Reload PHP-FPM or your web server. My analysis says this closes one of the two likely paths.
The second likely path lives in the multipart parser itself, which runs for any multipart/form-data POST regardless of the setting above. If you've got a WAF or reverse proxy, tighten inspection or rate-limit multipart POSTs to endpoints that don't need uploads. This is the same network-layer mitigation the enterprise vendors are quietly deploying for their paying customers.
Current stable: 8.5.11 / 8.4.26 / 8.3.35 / 8.2.34. If your hosting is managed, confirm your provider's timeline today.
A pre-patch mitigation shouldn't be a subscription perk. I'm a one man shop, and the orgs most likely to get burned in the gap between leak and patch are the small teams without an enterprise threat intel contract. The steps above cost nothing. Spend tonight reducing risk, not tomorrow doing incident response.
I'll follow up once the official advisory publishes and confirm whether my root cause read was right, together with Andrew Dorman (@acd421) and Arch&Yuki (@ArchKnight23).
Where to get it.
Signed release from the usual place:
http://jackalsyn.com/posts/phpupAssets/php-up-2026.tar.gz-xzf php-up-2026.tar.gzCredits: