PHP2Shell / CVE-2026-109618
Sicherheitsvorfall · 21. Oktober 2026

Wenn ein Dateiname
zum Shell-Zugriff wird.

php2shell ist eine kritische, nicht authentifizierte RCE in PHP. Die Demo zeigt die öffentlich dokumentierte Chain A: Dateiname → session.upload_progress → LFI → Codeausführung. Sie ist eine kontrollierte Lab-Simulation, kein Angriff auf fremde Systeme.

CVSS 4.0 · 9.2 Critical Pre-Auth RCE PHP ≤ 8.5.11 Fix: 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 CVE-2026-109618 / 109619
Nur für autorisierte Labore. Diese Präsentation enthält keine ASLR-Bypässe, keine Reverse Shells und keinen Endpunkt zum Ausführen beliebiger Befehle. Sie zeigt die Wirkung der dokumentierten Chain A mit einem harmlosen id-Payload.
Angriffskette

Vier Schritte, ein Shell-Zugriff

Klicke auf einen Schritt oder starte die Animation. Die Demo nutzt ein absichtlich verwundbares Lab mit LFI.

01 · Upload 1

Dateiname mit PHP-Code

Der Upload enthält einen Dateinamen wie <?php system($_GET['cmd']); ?>.

02 · Session 2

Upload-Progress schreibt ihn

session.upload_progress legt den Dateinamen ungefiltert in der Session-Datei ab.

03 · LFI 3

Anwendung included die Session

Ein LFI wie include($_GET['page']) lädt die Datei aus /tmp/sessions/.

04 · RCE 4

PHP führt den Code aus

Der Payload läuft als Web-User — im Lab als www-data, nicht als root.

Live-Simulation

Verwundbar vs. gepatcht

Die Simulation zeigt die Requests und das Ergebnis. Der Schalter wechselt zwischen PHP 8.3.35 und 8.3.36.

request-flow.log
1
Multipart-Upload sendenPHP_SESSION_UPLOAD_PROGRESS + Dateiname
2
Session-Datei prüfen/tmp/sessions/sess_<id>
3
LFI auslösenindex.php?page=/tmp/sessions/sess_…
4
Ergebnis auswertenid / whoami / uname
Bereit
lab@php2shellvulnerable

        
Unter der Haube

Die drei Zutaten

Ein LFI, die Upload-Progress-Konfiguration und ein Multipart-Request. Keine Zauberei — genau das macht es so gefährlich.

<?php
// Absichtlich verwundbares Lab — nur lokal!
if (isset($_GET['page'])) {
    include($_GET['page']);
} else {
    echo "php2shell lab";
}
Betroffenheit

Welche Versionen sind sicher?

Alle SAPIs sind betroffen; mod_php gilt laut Advisory als besonders exponiert, weil der Trigger vor Anwendungscode greift.

BranchVerwundbarFixStatus
PHP 8.5< 8.5.128.5.12Fix verfügbar
PHP 8.4< 8.4.278.4.27Fix verfügbar
PHP 8.3< 8.3.368.3.36Fix verfügbar
PHP 8.2< 8.2.358.2.35Fix verfügbar
PHP ≤ 8.1EOLUpgradeNicht mehr supported
Gegenmaßnahmen

Was wirklich hilft

Patch zuerst. Die anderen Maßnahmen sind Defense in Depth, kein Ersatz für das Update.

🛡️

PHP patchen

Auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12+ aktualisieren. Danach Apache/PHP-FPM neu starten.

🚫

Upload-Progress abschalten

session.upload_progress.enabled = Off reduziert die Chain-A-Angriffsfläche — ersetzt aber nicht den Patch.

🧱

LFI verhindern

Keine dynamischen Includes. Whitelist erlaubter Dateien, Pfade kanonisieren, .. und Stream-Wrapper blocken.

🔒

Session härten

session.use_strict_mode=1, use_only_cookies=1, HttpOnly/Secure/SameSite, kurze Lifetime.

👁️

Erkennen

Auf ungewöhnliche Multipart-Filenames, PHPSESSID im Body und Includes aus /tmp/ achten. WAF-Regeln ergänzen.

🧯

Least Privilege

PHP-User nur auf seine Verzeichnisse zugreifen lassen. Kein Root, keine unnötigen Schreibrechte, ausgehende Verbindungen einschränken.

✓
Sofort: Update + RestartPriorität für alle internet-facing PHP-Server; Container-Images neu ziehen und recreaten.
✓
Danach: LFI-InventurAlle include/require-Stellen mit Benutzereingaben prüfen.
✓
Monitoring: 24–72 hWebserver-, Auth- und Prozess-Logs auf ungewöhnliche Kindprozesse und Dateien prüfen.