devploit/php2shell

What it is

devploit/php2shell is a research toolkit for CVE-2026-109618 and CVE-2026-109619, a pre-auth RCE in PHP's session.upload_progress handling. It wraps the public exploit by 9bie with a version-aware dispatcher, per-build profiles and disposable labs. The README says it is for authorized testing only. It also warns that running the chain is disruptive: it sends large bodies, triggers out-of-memory conditions before request startup and kills Apache children. The repo credits Wiz Research with the discovery and does not claim the CVE as its own.

How it works

The upload-progress callback runs before request startup (pre-RINIT), so before any application script.

• Apache mod_php: a multipart request forces an out-of-memory bailout after the session state is built. The next request reuses the stale PS(id) and returns a Set-Cookie containing heap pointers (stage 1). The same primitive then leaks a libphp pointer (stage 2). Stage 3 lands a forged HashTable and reference on the stale state, so the zval_ptr_dtor path calls zif_system.
• PHP-FPM behind nginx: an OOM kills the worker, so the Apache carrier does not apply. The chain instead leaves BG(unserialize) dangling. The next request reclaims the 8216-byte struct with a 4 MB body, and a forged session variable makes session shutdown call zif_system.

Preconditions / Affected

Fixed releases are 8.4.27 and 8.5.12 for those branches, per the repo's catalog/vulnerable.json. Fixes for other branches are listed there but not in the page text, and the repo says to check them against current PHP advisories.

The shipped Apache calibration needs all of the following:

• prefork with mod_php and one worker (multiple workers need --pin-workers)
• display_errors=On and memory_limit=8M
• session.upload_progress.enabled=On, session.use_cookies=1, session.use_strict_mode=0
• post_max_size at least memory_limit plus 12M. The stock 8M default blocks the chain, because PHP rejects the oversized body before parsing.

The FPM chain in its stock shape needs:

• nginx with client_max_body_size of at least 5m (stock is 1m)
• memory_limit=128M, pm=dynamic, post_max_size=8M
• an application that calls session_start(), stores a reference, reflects a session value, and either decodes attacker data with session_decode() or accumulates session data

Verified exploitation, as reported by the repo:

• 56 profiles (48 Apache, 8 FPM), 30 with verified RCE.
• Apache RCE is confirmed on selected PHP 8.4.x and 8.5.x builds.
• FPM RCE is confirmed over HTTP on 7.4.33, 8.0.30, 8.1.33, 8.2.34, 8.3.35, 8.4.0, 8.4.25 and 8.4.26.
• 8.2, 8.1, 7.4 and 8.0 Apache images were tested and showed no working leak. The repo says "no" means not verified, not necessarily safe.
• On 2026-10-30 the maintainer independently reproduced the command proof for the stage-3 PR profiles (8.4.10, 8.4.11, 8.4.19, 8.4.20, 8.4.25 amd64, 8.5.0 to 8.5.10 amd64, 8.5.11 aarch64). The FPM and deb13/apxs2 profiles are contributor-reported only.

What to do

The repo's defensive guidance, in order of strength:

1. Patch to a fixed release (8.4.27, 8.5.12, or the fixed release for the branch in use).
2. Turn off the callback this chain needs, unless a specific endpoint requires it:

session.upload_progress.enabled=Off

1. Detect: multipart requests with about 1000 fields, very large bodies, repeated OOM or 500 responses, Apache child crashes, and zend_mm_heap corrupted log lines. Rate-limit large multipart bodies at the edge.
2. Run PHP as an unprivileged user with a read-only document root and no shell access.
3. Avoid sharing session storage across trust boundaries.

display_errors=Off, a larger memory_limit and a read-only webroot only raise the cost. The repo says they are not fixes.

Caveats

• display_errors=Off blocks the shipped stage-1 leak, but the repo says an OOM-in-cookie primitive is reproducible in research. The README lists that configuration as an open item, so it should not be treated as safe.
• Profiles are tied to a specific libphp build. Distribution, architecture and compile-time prefix all shift the heap, so the lab results do not transfer directly to production hosts.
• A remote command is limited to 14 bytes, and remote proof depends on a writable, served webroot.
• HTTPS transport is unverified. Stage 1 did not reproduce over TLS in the repo's tests.
• The Apache labs use one worker and 8M memory. The page gives no results against hardened multi-worker production setups.
• The upstream exploit has no license, so the repo does not vendor it. A bootstrap script fetches it at a pinned commit (4586f5c).