Public PoC reports repeatable lab RCE

What was published

A public repository named StealMyBitcoin-PoC contains a single-file Python script that reproduces the request sequence used to solve a public PHP2Shell challenge. The author, KillaBoi, says the script sends at most 20 HTTP requests: an initial health check, two memory-leak stages and a final callback.

The target in the README is specific: Alpine PHP 8.4.26 running the built-in CLI server with four workers. That is the build the memory offsets were calibrated against. The author states that a Debian php:8.4.26-fpm image reports the same PHP version but has a different binary layout, so the code-leak stage fails there.

What the PoC shows

The chain has four steps. A small multipart upload drives PHP past its memory limit during session upload-progress parsing. The poisoned worker is reused and leaks bytes through session cookies: first a Zend heap address, then a PHP code address. Those two addresses bypass ASLR. A final request places a forged HashTable where cleanup will find it, and cleanup calls zif_system, PHP’s handler for system.

In the author’s lab, 7 of 10 consecutive runs produced a verified execution proof. Two runs reached the final callback without the expected markers, and one failed to obtain a heap address. The live challenge run finished on 25 October 2026 at 15:47:38 UTC.

This matters because earlier public “PoCs” did not achieve RCE when independent researchers tested them. A working, published chain changes the tooling picture: the barrier to reproducing the bug in a favourable lab is lower than it was on 22 October.

What it does not show

The README is explicit about its limits. The offsets are build-specific, the lab uses a CLI server with four workers rather than a typical FPM pool, and the author tested only locally. A 7/10 result in that lab is not a production success rate.

The live run also has evidence gaps. The original outgoing request and the response headers were not captured; the request was reconstructed afterwards. The recovered WIF did not derive the prize address shown by the challenge, which the organiser acknowledged as a key-placement error.

None of this establishes a confirmed production compromise or a victim count. It is lab exploitation plus one challenge run, not evidence that every exposed host is exploitable. CISA KEV already records known exploitation of both CVEs, and that listing still carries no victim count.

What to do

The fix is unchanged: PHP 8.2.35, 8.3.36, 8.4.27 or 8.5.12, followed by a restart of every PHP worker. Treat the KEV due date of 29 October as urgent, but verify the runtime that actually serves requests rather than the version string in a control panel.

A public PoC does not make an unpatched host more exploitable than it already was. It does make the exploit easier to study, adapt and re-target, so the practical advice is the same: patch, restart, and check embedded or appliance PHP that may sit outside the normal update path. The verification guide covers the runtime check.