eness/php2shell-CVE-2026-109618-CVE-2026-109619-PoC

The problem

Most PHP deployments ship with session.upload_progress.enabled on by default, and two leaked 2026 CVEs turn that latent upload-progress machinery into pre-authentication remote code execution against the web server. Security teams need to know whether their fleet is actually exploitable and whether the emergency releases fix it; a description of a heap use-after-free does not answer that. This repository packages a working exploit chain plus patch and detection guidance in one place.

What's different

Generic vulnerability scanners report version banners. This PoC instead performs a full four-stage HTTP attack: it forces prefork worker rotation, leaks heap and libphp.so base addresses through Set-Cookie side channels to defeat ASLR, then forges a fake HashTable inside a 167-byte zend_string and redirects pDestructor to zif_system. That is a level of concrete, end-to-end exploit engineering you normally only find in Metasploit modules or dedicated research write-ups, and it is paired with configuration mitigations, WAF rules, source patches and child-process detection advice. The trade-off is strict targeting: the default profile assumes mod_php under Apache prefork, one worker, memory_limit well below the OOM trigger, and commands capped at 14 bytes inline.

Who it's for

SOC analysts, incident responders and platform engineers who own internet-facing PHP estates and want proof of exploitability before declaring a patch window closed. It is also useful for pentesters validating customer exposure. Casual readers looking for a general PHP hardening guide should look elsewhere, and nobody should point this at systems they do not own, since there is no license and no explicit authorization framework.

Cost of adoption

You need Python 3 to run poc_109618.py, targets matching the stated Apache prefork mod_php profile, and distribution-specific symbol offsets for reliable ASLR bypass (Debian Bookworm, Ubuntu Noble, Ubuntu Jammy are mentioned). The README is unusually long but mixes operational guidance with exploit detail, and there is no declared license, which makes commercial or internal redistribution legally ambiguous. End-of-life PHP 5.x/7.x/8.0/8.1 get no upstream patch, so the project leans on config-level mitigations for them. Treat it as a short-lived tool tied to a specific CVE pair, not a maintained platform.

Verdict

The project is three days old with roughly 980 stars and about 287 per day, a sharp spike typical of a brand-new CVE PoC rather than an established security tool. Whether it stays useful depends on whether upstream offsets and the exploit survive the emergency releases for PHP 8.2 through 8.5. That velocity signals real defender interest now, but the absence of a license and its single-purpose nature mean you should read the README as advisory content and verify every claim against your own lab before trusting it in an incident. This is a timely artifact, not a long-term dependency.