Critical Severity CVE-2026-109619
Published: Oct 25, 2026

[GitHub] php2shell-CVE-2026-109618-109619

Rce
Type
N/A
CVSS Score
6
Views
Anonymous
Author

Description

Full 1:1 reproduction of php2shell (CVE-2026-109618 / CVE-2026-109619): pre-auth PHP RCE via session.upload_progress OOM corruption and stale cross-request state. Pinned mod_php 8.4.26 / Apache 2.4.69 aarch64 lab, pure HTTP, heap-layout ASLR bypass, no brute force.

# php2shell — CVE-2026-109618 / CVE-2026-109619: full 1:1 reproduction

A pure-HTTP, pre-auth RCE against the pinned PHP 8.4.26 + Apache mod_php image: a `session.upload_progress` OOM leaves a stale session pointer across requests, a calibrated heap layout turns it into a 4 KiB ASLR leak, and a second leak of `libphp` lands `zif_system()` — no credentials, no brute force.

Fresh Compose target, 3/3 consecutive runs:

```
uid=33(www-data) gid=33(www-data) groups=33(www-data)
```

![php2shell demo](docs/demo.gif)

## Quickstart

One command after cloning:

```bash
git clone https://github.com/Pattingbabies/php2shell-CVE-2026-109618-109619.git \
&& cd php2shell-CVE-2026-109618-109619 \
&& make demo
```

`make demo` starts the pinned image on `127.0.0.1:8080`, runs the full three-stage chain, and prints the worker's `uid`. Requirements: Docker with Compose, Python 3.10+, and an arm64 host for the release row; the amd64 compatibility row needs an amd64-capable runtime or emulation. The target is bound to loopback.

To stop and remove the lab:

```bash
make down
```

## Why this is a 1:1 reproduction

The shipped lab is the vulnerable configuration the chain was calibrated against, not a mock:

| Layer | Shipped value |
|---|---|
| Image | `php:8.4.26-apache@sha256:60111400ff77bdc44fa79b4f072afe49a42abba71e0846ad496be4761dc9c11a` |
| SAPI | mod_php, Apache 2.4.69, prefork |
| Memory | `memory_limit=8M`, `post_max_size=64M` |
| Errors | `display_errors=On`, `error_reporting=E_ALL` |
| Input | `max_input_vars=1000` (default), upload progress enabled |
| Worker | one Apache child, `KeepAlive Off` |
| Verification page | the 22-byte `web/index.php`; application page content is not a hard constraint on this build (see compatibility) |

The exploit is three real stages against that image. Stage 1 leaks the Zend MM chunk base from a `Set-Cookie` response. Stage 2 leaks the `libphp` base through a 56-byte HashTable page. Stage 3 plants a fake `HashTable`/`execute_data` pair a

Community Rating
0

Login to rate this exploit

Quick Actions