PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab
Die kritischen PHP-Schwachstellen PHP2Shell (CVE-2026-109618 und CVE-2026-109619) sind öffentlich bekannt, Sicherheitsanbieter berichten von Ausnutzungsversuchen. Wer inzwischen aktualisiert hat, sollte noch eine Frage klären: Gibt es Hinweise darauf, dass vor dem Update bereits jemand versucht hat, die Lücken auszunutzen? Wir zeigen, welche Spuren sich prüfen lassen, welche Befehle helfen und wo die Grenzen liegen.
Jede Quelle hat Grenzen. Erst das Zusammenspiel liefert belastbare Hinweise.
LAGE
Was ist über tatsächliche Angriffsversuche bekannt?
Ein erfolgreiches Update behebt die bekannte Schwachstelle in der aktualisierten PHP-Laufzeit. Es kann aber nicht rückwirkend ausschließen, dass ein Angreifer vorher bereits Code ausgeführt, Dateien verändert oder weitere Zugänge eingerichtet hat. Die Hintergründe zu den Schwachstellen und den korrigierten Versionen findest du in unserem PHP2Shell-Hauptbeitrag.
PHP2Shell umfasst zwei kritische Schwachstellen im PHP-Kern. Unter bestimmten Voraussetzungen kann ein nicht authentifizierter Angreifer darüber Code auf einem verwundbaren System ausführen. Am 21. Oktober 2026 wurden die korrigierten PHP-Versionen veröffentlicht.
Amazon Threat Intelligence berichtet von einem Ausnutzungsversuch gegen die eigene Honeypot-Infrastruktur bereits am 17. Oktober sowie von weiteren Aktivitäten am 21. Oktober. Die ersten öffentlich kursierenden Proofs of Concept tauchten laut Amazon noch am 21. Oktober gegen 02:00 UTC auf, also vor der Veröffentlichung der Updates um 14:00 UTC. Das PHP-Projekt erklärte laut Tenable allerdings, in den ihm bekannten PoCs zum Zeitpunkt der Veröffentlichung keine funktionsfähigen Exploits gefunden zu haben. Die Funktionsfähigkeit einzelner Codes ist also nicht unabhängig bestätigt, und angeblicher Exploit-Code im Netz kann selbst Schadsoftware enthalten.
Es geht damit nicht mehr nur um eine theoretische Angriffsmöglichkeit, denn es gibt konkrete Berichte über Versuche. Allerdings müssen drei Dinge auseinandergehalten werden:
Ein Exploit ist verfügbar
Ein technischer Ansatz zur Ausnutzung ist beschrieben oder im Umlauf. Ob konkreter Code funktioniert, ist damit noch nicht gesagt.
Ein Angriff wurde beobachtet
Ein System hat eine Anfrage oder Aktivität erkannt, die mit dem Exploit zusammenhängt. Das beweist keine erfolgreiche Kompromittierung.
Ein Angriff war erfolgreich
Es gibt belastbare Hinweise, dass tatsächlich Code ausgeführt oder das System kompromittiert wurde.
Diese Aussagen sind nicht gleichbedeutend. Umgekehrt lässt sich eine frühere Kompromittierung nicht allein deshalb ausschließen, weil keine offensichtlichen Fehlermeldungen gefunden werden.
SCHRITT 1
Zuerst feststellen, welche Systeme betroffen waren
Bevor Logs ausgewertet werden, sollte klar sein, welche PHP-Installationen überhaupt exponiert waren. Dabei reicht es nicht, nur den Hauptwebserver zu betrachten. PHP kann auf einem System in mehreren Versionen und Betriebsarten installiert sein, und Anwendungen können ihre eigene Runtime mitbringen. Relevant sind insbesondere:
- PHP-FPM hinter Nginx oder Apache
- Apache mit
mod_php php-cgi- PHP innerhalb von Docker-Containern
- PHP-basierte Verwaltungsoberflächen
- Drittanbieterprodukte mit integrierter PHP-Laufzeit
- ältere Anwendungen auf nicht mehr unterstützten PHP-Versionen
Die PHP-Sicherheitsmeldung nennt diese Betriebsarten ausdrücklich. Besonders kritisch ist laut PHP die Konfiguration mit Apache mod_php, weil ein präparierter Request die Schwachstelle auslösen kann, bevor der eigentliche Anwendungscode ausgeführt wird.
Installierte Versionen und Prozesse
Auf Debian und Ubuntu liefern diese Befehle eine erste Übersicht:
Wichtig: php -v zeigt die Version der PHP-CLI. Diese muss nicht der Version entsprechen, die eine Website tatsächlich verwendet. Auch Paketlisten reichen nicht, um PHP in Containern oder Drittanbieterprodukten zu erfassen.
Docker
Zeigt zunächst nur laufende Container und deren Images:
Ob und welche PHP-Version enthalten ist, muss anschließend innerhalb der jeweiligen Runtime oder anhand des Images geprüft werden, etwa mit docker exec <CONTAINER> php -v.
SCHRITT 2
Webserver-Logs auf auffällige Requests untersuchen
Ein wichtiger Ansatzpunkt sind die HTTP-Zugriffe. Bei PHP2Shell sind insbesondere POST-Anfragen mit multipart/form-data relevant, das Format, das etwa bei Datei-Uploads verwendet wird. Außerdem ist das Feld PHP_SESSION_UPLOAD_PROGRESS von Interesse: Amazon Threat Intelligence empfiehlt ausdrücklich, nach POST-Anfragen zu suchen, die dieses Feld enthalten, und Webserver-Logs auf verdächtige Aktivitäten zu prüfen.
Das bedeutet nicht, dass jede solche Anfrage bösartig ist. Uploads gehören bei vielen Anwendungen zum normalen Betrieb. Entscheidend sind Kontext, Häufigkeit, Aufbau der Anfrage und mögliche Folgeaktivitäten.
Die Grenze klassischer Access-Logs
Klassische Access-Logs enthalten die HTTP-Methode, den Pfad, den Statuscode und die Antwortgröße, aber weder den Content-Type noch den Inhalt des Request-Bodys. Ein einfacher Textfilter nach multipart/form-data findet dort deshalb nichts, und ein Filter nach POST liefert auf aktiven Websites Tausende Treffer. Wenn der Inhalt einer Anfrage nicht protokolliert wurde, kann ein einfacher Textfilter den Angriff nicht erkennen.
Systeme mit zentraler Protokollierung, vorgeschaltetem Reverse Proxy, CDN oder Web Application Firewall müssen gegebenenfalls an mehreren Stellen untersucht werden.
POST-Anfragen mit Serverfehler
Als grobe Orientierung lassen sich POST-Anfragen herausfiltern, die mit HTTP 500 endeten. Das Beispiel geht vom üblichen Combined-Log-Format aus, bei dem der Statuscode das neunte Feld ist:
Ein Treffer ist kein Beweis, Treffer häufen sich aber auch bei fehlerhaften Anwendungen. Abweichende Log-Formate müssen angepasst werden.
Nach PHP_SESSION_UPLOAD_PROGRESS suchen
Das funktioniert nur dort, wo Request-Bodys oder WAF-Ereignisse protokolliert werden, etwa in ModSecurity-Audit-Logs (Pfad je nach Setup) oder in einer vorgeschalteten WAF:
Ein Treffer ist ein Anlass zur näheren Untersuchung, kein Beweis. Ein fehlender Treffer ist keine Entwarnung, denn bei nicht geloggtem Body kann der Begriff schlicht nicht vorkommen.
SCHRITT 3
PHP- und Webserver- Fehlerlogs prüfen
Beide Schwachstellen betreffen interne Abläufe in PHP. Deshalb können Fehler rund um die Verarbeitung einer Anfrage Hinweise liefern, zum Beispiel:
- Auffällige Häufungen von Speicherfehlern und Meldungen über Speichererschöpfung
- Ungewöhnliche Abstürze oder Segmentation Faults
- Neustarts von PHP-FPM-Workern
- Wiederholte HTTP-500-Antworten
- Ungewöhnlich große oder fehlerhafte
PHPSESSID-Cookies (Hinweis von Wiz) - Zeitlich auffällige Kombinationen aus HTTP-Anfragen und PHP-Fehlern
Solche Ereignisse sind nicht automatisch ein Angriff. Speicherfehler können auch durch reguläre Last, fehlerhafte Anwendungen oder zu knapp konfigurierte Ressourcen entstehen. Umgekehrt weist Datadog darauf hin, dass erfolgreiche Ausnutzung den Worker nicht zwingend zum Absturz bringt. Fehlende Fehlermeldungen sind deshalb keine Entwarnung.
Systemmeldungen durchsuchen
Auf Systemen mit systemd lassen sich die vergangenen Tage so untersuchen. Den Zeitraum bitte an den tatsächlichen Untersuchungszeitraum anpassen:
Eigene Logdateien nicht vergessen
PHP kann Fehler auch in eigene Dateien schreiben. Auf Debian und Ubuntu liegen die Logs von PHP-FPM meist unter /var/log/php<Version>-fpm.log (zum Beispiel /var/log/php8.4-fpm.log), bei Apache mit mod_php landen PHP-Fehler im Apache-Error-Log, etwa /var/log/apache2/error.log.
Der genaue Speicherort hängt von der Konfiguration (error_log) ab und sollte pro System geprüft werden.
Worauf kommt es bei der Auswertung an?
Ein einzelner PHP-Fehler ist noch kein Nachweis einer Kompromittierung. Verdächtiger wäre eine zeitliche Abfolge aus (1) einer ungewöhnlichen POST-Anfrage, (2) einem auffälligen PHP-Fehler, (3) dem Start eines bislang nicht beobachteten Prozesses und (4) einer unerwarteten Dateiänderung oder ausgehenden Netzwerkverbindung. Eine solche Kette ist ein Ansatzpunkt für eine Incident-Response-Untersuchung und sollte anhand der vorhandenen Daten verifiziert werden.
SCHRITT 4
Prüfen, ob PHP ungewöhnliche Prozesse gestartet hat
Eine erfolgreiche Remote-Code-Ausführung kann dazu führen, dass ein PHP-Prozess weitere Programme startet. Deshalb lohnt sich ein Blick auf die Prozesshierarchie. Auch die Erkennungsansätze etwa von Elastic setzen genau hier an: Auffällig sind Shells, Skript-Interpreter oder Download-Werkzeuge (curl, wget), die von PHP-FPM oder einem Webserver-Prozess gestartet werden, sowie Programme, die aus /tmp, /dev/shm oder dem Webroot laufen. Aufklärungsbefehle wie id, whoami oder uname -a unter dem Webserver-Benutzer sind ebenfalls ein Warnsignal. Sie können in legitimen Anwendungen vorkommen und müssen im Kontext des Dienstes bewertet werden.
Achte auf unerwartete Kindprozesse von PHP-FPM oder Apache, Prozesse unter dem Webserver-Benutzer, die nicht zum Betrieb gehören, unbekannte Skripte oder ausführbare Dateien, ungewöhnliche Prozessketten und Prozesse, deren Startzeit zu verdächtigen HTTP-Anfragen passt.
Der Befehl zeigt nur eine Momentaufnahme: Bereits beendete Prozesse erscheinen nicht mehr. Wer vor dem Angriff keine Prozessaktivitäten protokolliert hat, kann einen beendeten Prozess normalerweise nicht allein durch eine nachträgliche Abfrage rekonstruieren. Hilfreicher sind historische Daten aus Prozessüberwachung, Audit-Protokollierung oder einem Endpoint-Detection-System, sofern sie schon vor dem Vorfall aktiv waren.
SCHRITT 5
Webverzeichnisse auf unerwartete Änderungen prüfen
Wenn ein Angreifer Code ausführen konnte, könnte er Dateien verändert oder zusätzliche Skripte abgelegt haben. Untersucht werden sollten insbesondere Webroots und Upload-Verzeichnisse, Verzeichnisse mit PHP-Skripten, temporäre Verzeichnisse, vom Webserver beschreibbare Verzeichnisse sowie Konfigurationsdateien und geplante Aufgaben. Dabei sind reguläre Änderungen durch Deployments, CMS-Updates, Uploads und Wartung von unbekannten Änderungen zu unterscheiden.
Kürzlich veränderte Dateien
Für ein Webverzeichnis unter /var/www lassen sich Skripte suchen, die seit dem 17. Oktober geändert wurden. Das ist genauer als ein relativer Zeitraum wie -mtime -7, der mit jedem Tag verrutscht:
Geplante Aufgaben
Neue Cron-Einträge können auf Persistenz hinweisen:
Besonders prüfenswert sind unbekannte PHP-Dateien, unerwartete Änderungen an vorhandenen Skripten sowie neue Dateien in Verzeichnissen, in denen normalerweise keine ausführbaren Skripte liegen. Eine große Trefferliste ist bei aktiv betriebenen Websites normal, vergleiche sie deshalb mit bekannten Deployments, Paketupdates und Backups.
Was dieser Dateicheck nicht leisten kann
Ein Angreifer kann Dateien verändern, Zeitstempel beeinflussen oder Code an vorhandene Dateien anhängen. Umgekehrt erzeugen normale Updates viele legitime Änderungen. Der Befehl ist deshalb nur eine erste Bestandsaufnahme. Belastbarer sind bekannte Sollzustände, Versionskontrolle, vertrauenswürdige Backups oder Integritätsprüfungen.
SCHRITT 6
Ausgehende Netzwerkverbindungen untersuchen
Ein kompromittierter Webserver könnte versuchen, weitere Systeme zu erreichen, Daten zu übertragen oder zusätzliche Dateien abzurufen. Deshalb sollte geprüft werden, ob PHP-Prozesse oder andere Prozesse unter dem Webserver-Benutzer ungewöhnliche ausgehende Verbindungen aufbauen.
Der Befehl zeigt aktuelle TCP-Verbindungen und, soweit verfügbar, die zugehörigen Prozesse. Auch hier gilt: Es ist nur der aktuelle Zustand, eine bereits beendete Verbindung lässt sich damit nicht nachweisen. Für eine rückwirkende Untersuchung sind vorhandene Firewall-, DNS-, Proxy-, NetFlow- oder EDR-Protokolle wesentlich wertvoller. Ein Webserver kann außerdem durch reguläre API-Aufrufe, Updates oder externe Dienste legitime Verbindungen aufbauen, auffällige Verbindungen müssen deshalb im Zusammenhang mit Prozessen und dem jeweiligen Dienst bewertet werden.
ZEITRAUM
Den Zeitraum vor dem Patch nicht vergessen
Wer am 21. Oktober oder später aktualisiert hat, sollte bei einer rückwirkenden Untersuchung nicht nur die Zeit nach dem Update betrachten. Amazon Threat Intelligence hat einen Ausnutzungsversuch bereits am 17. Oktober 2026 beobachtet und empfiehlt, Untersuchungen ab diesem Datum zu beginnen. Je nach Systemhistorie kann ein sinnvoller erster Prüfzeitraum deshalb bis zum 17. Oktober zurückreichen, bei konkreten Hinweisen auch weiter. Angreifer könnten eine Schwachstelle außerdem schon vor der öffentlichen Bekanntgabe gekannt haben.
Eine sinnvolle Zeitleiste umfasst:
- den Zeitraum vor der öffentlichen Veröffentlichung,
- den Tag der Veröffentlichung und der Verfügbarkeit von Exploits,
- den Zeitpunkt der eigenen Aktualisierung,
- die Zeit nach dem Update, falls weiterhin verdächtige Aktivitäten auftreten.
Die Grenzen sind klar: Wenn Logs bereits rotiert wurden, Request-Bodys nicht protokolliert wurden oder keine Prozessüberwachung existierte, kann die rückwirkende Prüfung unvollständig bleiben.
VERDACHT
Was tun bei einem konkreten Verdacht?
Wenn mehrere Indikatoren zusammenpassen, sollte die Untersuchung nicht bei einzelnen Shell-Befehlen enden.
Beweise sichern
Webserver-, PHP-, System-, Firewall- und Sicherheitslogs sichern. Zeitstempel, betroffene Systeme und auffällige Ereignisse dokumentieren. Vorschnelle Bereinigungen vermeiden, sie können Beweise zerstören.
System bewerten und isolieren
Ist eine erfolgreiche Kompromittierung wahrscheinlich, das System nach einem geeigneten Incident-Response-Verfahren isolieren und dabei die Auswirkungen auf produktive Dienste berücksichtigen.
Nicht nur nach Schadsoftware suchen
Ein Angreifer muss keine dauerhafte Datei hinterlassen. Auch Prozesse, Benutzerkonten, SSH-Zugänge, geplante Aufgaben, Dienste, Konfigurationsänderungen und ausgehende Verbindungen gehören in die Untersuchung.
Zugangsdaten und Geheimnisse bewerten
Bei bestätigter oder stark vermuteter Kompromittierung prüfen, welche Zugangsdaten, Tokens oder API-Schlüssel das System erreichen konnte. Je nach Befund ist eine Rotation nötig.
Wiederherstellung nicht mit Patchen verwechseln
Ein Sicherheitsupdate behebt die bekannte Schwachstelle. Bei bestätigter Kompromittierung müssen zusätzlich unerwünschte Änderungen und Persistenzmechanismen beseitigt werden. In schwerwiegenden Fällen kann ein Neuaufbau aus einem vertrauenswürdigen Zustand sicherer sein, als nur verdächtige Dateien zu löschen.
GRENZEN
Warum es keine einfache Entwarnung gibt
Die beschriebenen Prüfungen liefern Hinweise, aber keine universelle Garantie. Angriffsspuren können in Webserver-Logs fehlen, weil der Request-Body nicht protokolliert wurde. Laut Wiz laufen die Schwachstellen unterhalb der Anwendungsebene, Anwendungslogs zeigen deshalb oft wenig. Prozessinformationen gehen verloren, wenn keine historischen Daten aufgezeichnet wurden, und Dateien können verändert oder entfernt worden sein, bevor die Untersuchung beginnt.
Umgekehrt können legitime Uploads, PHP-Fehler und reguläre Deployments einzelne Indikatoren auslösen, ohne dass ein Angriff stattgefunden hat. Die beste Bewertung entsteht aus mehreren unabhängigen Datenquellen: HTTP-Zugriffen, PHP-Fehlern, Prozessaktivitäten, Dateiänderungen, Netzwerkdaten und bekannten Änderungen am System.
Liegen konkrete Hinweise auf eine Kompromittierung vor, ist eine strukturierte Incident-Response-Untersuchung sinnvoller als der Versuch, mit einem einzelnen Befehl Sicherheit zu beweisen.
BEI RDDZ
Was wir bei RDDZ empfehlen
Wir haben unsere Systeme am 21. Oktober 2026 um 18:00 Uhr gepatcht. Das war der entscheidende Schritt, um die bekannten Schwachstellen in den aktualisierten Umgebungen zu beheben. Eine rückwirkende Prüfung auf frühere Ausnutzung ist davon getrennt zu betrachten.
Wir empfehlen Betreibern deshalb, nicht nur die installierten PHP-Versionen zu kontrollieren, sondern auch die vor dem Update verfügbaren Protokolle und Systeminformationen zu prüfen. Bei öffentlich erreichbaren Systemen sollten insbesondere ungewöhnliche HTTP-Anfragen, auffällige PHP-Fehler, unerwartete Prozesse und unbekannte Dateiänderungen untersucht werden.
Ein erfolgreiches Update ist notwendig. Eine belastbare Aussage über eine mögliche frühere Kompromittierung erfordert jedoch eine separate Untersuchung.
FAZIT
Patchen ist der Anfang, nicht die gesamte Untersuchung
PHP2Shell zeigt, wie schnell eine kritische Schwachstelle in einer weit verbreiteten Laufzeitumgebung zu einem praktischen Sicherheitsproblem werden kann. Die verfügbaren Updates sollten unverzüglich installiert werden. Zusätzlich lohnt sich eine rückwirkende Prüfung, insbesondere wenn Systeme vor dem Patch öffentlich erreichbar waren und relevante Logs noch vorhanden sind.
Webserver- und PHP-Logs, Prozessaktivitäten, Dateisystemänderungen und ausgehende Netzwerkverbindungen liefern zusammen mögliche Hinweise auf einen Angriff. Keine dieser Quellen reicht für sich allein aus, um eine Kompromittierung sicher nachzuweisen oder auszuschließen. Wer verdächtige Aktivitäten findet, sollte die Hinweise sichern, zeitlich korrelieren und bei konkretem Verdacht eine strukturierte Incident-Response-Untersuchung durchführen.
QUELLEN
Weiterführende Quellen
- PHP-Projekt: Sicherheitsmeldungen und korrigierte Versionen
- Amazon Threat Intelligence: PHP2Shell-Ausnutzungsversuche vor der öffentlichen Bekanntgabe
- Tenable: PHP2Shell FAQ
- Wiz Research: PHP2Shell
- CERT-EU: Critical Vulnerabilities in PHP – Advisory 2026-018
- RUS-CERT der Universität Stuttgart: Kritische PHP-Schwachstellen
- Datadog Security Labs: PHP2Shell – Detection, Analysis and Remediation
- Elastic Security Labs: Erkennung von PHP2Shell
- NCSC-NL: PHP2Shell – Empfehlungen und technische Informationen
Verdacht auf einen Angriff oder Hilfe bei der Prüfung?
Logs, Prozesse und Dateien sauber auswerten ist Aufwand. Sprechen Sie uns an, wir unterstützen bei Prüfung, Absicherung und Betrieb.
