PHP-System nach Sicherheitslücke prüfen: Logs, Webshells, Konten und Daten kontrollieren

Der Patch ist eingespielt, die PHP-Version aktualisiert, die Dienste neu gestartet. Eigentlich könnte der Betrieb weitergehen. Doch wer jetzt aufhört zu prüfen, übersieht die entscheidende Frage: War ein Angreifer vor dem Update bereits auf dem System?

Genau das ist das Problem nach den am 21. Oktober 2026 veröffentlichten kritischen PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619. Beide ermöglichen nicht authentifizierte Remote-Code-Ausführung mit den Rechten des Web-Worker-Kontos (CVSS v4.0: 9.2). Laut watchTowr – einem auf Bedrohungsforschung spezialisierten Anbieter – wurden in dessen Honeypot-Netz bereits seit dem 21. Oktober Ausnutzungsversuche beobachtet. In Fachmedien kursiert der Name „PHP2Shell" für entsprechende Angriffswerkzeuge.

Das Zeitfenster zwischen Bekanntwerden und Patch-Einspielung beträgt in vielen KMU nicht Stunden, sondern Tage. Wer PHP-System nach Sicherheitslücke prüfen möchte, braucht einen strukturierten Ablauf – keine Pauschalaussage, dass ein fehlender Logeintrag die Kompromittierung ausschließt. Das tut er nicht.

Was diese CVEs konkret bedeuten – und warum das Zeitfenster zählt

CVE-2026-109618 nutzt einen Fehler beim Speichermangel-Handling: Bricht PHP einen Request per longjmp() ab, kann ungültiger Zustand aus der Startphase beim Request-Ende weiterverwendet werden. Auslöser ist laut Advisory unter anderem das Parsen von Multipart-Anfragen. Für Apache mod_php ist RCE über HTTP mit Standardlimits bestätigt. Für PHP-FPM, FrankenPHP und LSAPI gilt die Ausnutzbarkeit laut Quellcodeanalyse als wahrscheinlich; ein vollständiger Exploit ist dort zum Zeitpunkt der Veröffentlichung nicht demonstriert worden.

CVE-2026-109619 betrifft globalen Worker-Zustand, der nach Request-Ende auf bereits freigegebenen Speicher zeigt (Use-after-free). Eine Ausnutzung braucht zwei Requests an denselben Worker. Für Apache mod_php ist RCE bestätigt; für PHP-FPM gibt es einen validierten Pfad über „session upload progress".

Betroffen sind alle PHP-Versionen unter 8.2.35, 8.3.36, 8.4.27 und 8.5.12. PHP 8.1 und älter erhalten vom PHP-Projekt keine Patches mehr; das PHP-Security-Team hat minimale Quell-Backports für 7.4, 8.0 und 8.1 veröffentlicht, auf die sich Distributionen und Hoster stützen können.

Das relevante Zeitfenster für die Nachuntersuchung beginnt frühestens ab dem 21. Oktober 2026 – dem Tag, an dem die ersten Ausnutzungsversuche beobachtet wurden – und endet mit dem Neustart aller PHP-Worker nach dem Patch-Einspielen. Betreiber von Systemen, die vor dem Patch über das Netz erreichbar waren, sollten genau diesen Zeitraum untersuchen.

Warum ein kompromittiertes System nach dem Patch noch immer ein Risiko ist

Ein Update schließt die Lücke. Es entfernt aber keine Backdoor, die ein Angreifer zuvor hinterlegt hat. Typische Persistenzmechanismen nach einer RCE-Ausnutzung sind Webshells (PHP-Dateien, die auf HTTP-Anfragen mit Shell-Zugang antworten), neue Systemnutzer oder SSH-Keys sowie geplante Tasks (Cronjobs), die periodisch nach Hause telefonieren.

Hinzu kommt: Ein Angreifer mit Zugriff auf das Web-Worker-Konto kann Umgebungsvariablen und Konfigurationsdateien lesen. Datenbankpasswörter, API-Keys und Cloud-Credentials, die in .env-Dateien oder PHP-Konfigurationen hinterlegt sind, gelten nach einer bestätigten oder wahrscheinlichen Kompromittierung als kompromittiert – unabhängig davon, ob der Angreifer sie tatsächlich exfiltriert hat.

Ein wirtschaftliches Beispiel, um den Schaden greifbar zu machen: Ein Onlineshop-Betreiber, dessen Datenbankpasswort abgegriffen wurde, hat nicht nur ein internes Problem. Er trägt unter Umständen eine Meldepflicht nach Art. 33 DSGVO gegenüber der Aufsichtsbehörde und ggf. nach Art. 34 gegenüber betroffenen Kunden. Wer die Prüfung unterlässt, kann diesen Nachweis nicht erbringen.

Schritt 1: Zeitfenster und Angriffsfläche eingrenzen

Bevor Logs durchsucht werden, braucht man eine klare Grundlage:

• Welche PHP-Version lief vor dem Patch? Nur Versionen unter 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 sind betroffen.
• Welches SAPI? Apache mod_php und PHP-FPM mit session upload progress sind für konkrete Angriffsvektoren bestätigt. Andere Umgebungen sind nach aktuellem Stand nicht ausgeschlossen.
• War der Server zwischen dem 21. Oktober 2026 und dem Patch-Zeitpunkt über HTTP(S) erreichbar? Systeme hinter VPN oder mit Netzwerk-ACLs, die keine externen Multipart-Anfragen zuließen, haben ein deutlich geringeres Risiko – aber kein Null-Risiko, da interne Angreifer oder fehlerhaft konfigurierte Zugänge möglich sind.
• Wann wurde der Patch eingespielt und wann wurden alle PHP-Worker tatsächlich neu gestartet? Allein das Update der Binaries ohne Dienstneustart behebt die Schwachstelle nicht.

Diese vier Antworten bestimmen, wie tief die Nachuntersuchung gehen muss.

Schritt 2: Web- und Systemlogs auswerten

Was in den Weblogs zu suchen ist

Suche in den Zugriffslogs (Apache access_log, nginx access.log) nach Mustern, die auf Ausnutzungsversuche hindeuten:

• POST-Requests an PHP-Endpunkte mit ungewöhnlich großen Bodies oder auf Pfade, die normalerweise keine Multipart-Daten empfangen
• Requests, die HTTP 500-Antworten mit auffällig kurzer Antwortzeit produzierten – das kann auf einen Speicherfehler hinweisen, muss es aber nicht
• Unbekannte User-Agent-Strings, die nicht zum Normalprofil des eigenen Traffics passen
• Requests auf PHP-Dateien, die nicht zur eigenen Anwendung gehören (potenzielle Webshell-Zugriffe nach einer ersten Kompromittierung)

Wichtige Einschränkung: Fehlerhafte Anfragen können auch in Fehler-Logdateien landen, während der Zugriff im Access-Log unscheinbar wirkt. Umgekehrt kann eine erfolgreiche Ausnutzung genau dann unsichtbar bleiben, wenn das Logging zu grob konfiguriert ist. Fehlende Einträge schließen eine Kompromittierung nicht aus.

PHP-Fehlerlog prüfen

Das PHP-Fehlerlog (error_log, Pfad aus php.ini oder SAPI-Konfiguration) enthält Hinweise auf OOM-Fehler, longjmp-Abbrüche und fatale Fehler, die im fraglichen Zeitraum aufgetreten sind. Häufen sich solche Einträge um bestimmte Endpunkte oder Uhrzeiten, lohnt eine detailliertere Untersuchung der korrespondierenden Zugriffslog-Zeilen.

Systemlogs

/var/log/auth.log und /var/log/secure zeigen SSH-Logins, sudo-Nutzung und fehlgeschlagene Authentifizierungen. Suche nach Login-Ereignissen aus IP-Adressen, die nicht zum normalen Administrationsverkehr gehören, sowie nach sudo-Ausführungen durch den Web-Worker-Nutzer (typisch www-data oder nginx).

Schritt 3: Veränderte und neue Dateien erkennen

Webshells aufspüren

Eine Webshell ist eine Datei – in diesem Kontext typischerweise eine .php-Datei – die eingehende HTTP-Parameter als Systembefehle ausführt. Sie kann vollständig neu angelegt oder in eine bestehende Datei eingefügt worden sein.

Praktische Suche auf Linux-Systemen:

# Neu angelegte oder veränderte PHP-Dateien im Dokumentenstamm seit einem bestimmten Datum
find /var/www -name "*.php" -newer /var/www/html/index.php -ls

# Dateien mit typischen Webshell-Indikatoren
grep -rn "eval(base64_decode" /var/www/
grep -rn "system($_" /var/www/
grep -rn "passthru(" /var/www/
grep -rn "shell_exec(" /var/www/

Das Datum für -newer sollte dem Zeitpunkt des letzten regulären Deployments entsprechen, nicht dem heutigen Tag. So werden Dateien sichtbar, die nach dem letzten Deployment und vor dem Patch angelegt wurden.

Datei-Integrität prüfen

Wer ein Deployment-System mit reproduzierbaren Builds nutzt, kann einen frischen Build des gleichen Commits erzeugen und Checksummen vergleichen. Ohne Deployment-System ist der manuelle Vergleich aufwendig, aber machbar: PHP-Kern- und Framework-Dateien lassen sich gegen die offiziellen Archiv-Checksummen prüfen.

Upload-Verzeichnisse (/uploads, /tmp, /cache) verdienen besondere Aufmerksamkeit: Sie sind meist schreibbar und werden gelegentlich für Webshells genutzt, die als Bilddatei getarnt sind, aber PHP-Code enthalten.

Schritt 4: Benutzerkonten und Zugänge prüfen

Nach einer RCE-Ausnutzung mit Web-Worker-Rechten kann ein Angreifer – abhängig von lokalen Privilegieneskalationsmöglichkeiten – Systemnutzer anlegen oder SSH-Keys hinterlegen.

# Kürzlich geänderte /etc/passwd und /etc/shadow prüfen
ls -la /etc/passwd /etc/shadow
stat /etc/passwd

# Benutzer mit Shell-Zugang auflisten
grep -v nologin /etc/passwd | grep -v false

# Autorisierte SSH-Keys auf dem Server prüfen
find /home /root -name "authorized_keys" -exec ls -la {} \; -exec cat {} \;

Erstelle eine Liste aller Nutzer mit Shell-Zugang und vergleiche sie mit dem erwarteten Soll-Zustand. Jeder unbekannte Eintrag ist ein Alarm. Gleiches gilt für authorized_keys-Einträge, die keinem bekannten Administrator-Key entsprechen.

Schritt 5: Geplante Tasks und Persistenz

Cronjobs und Systemd-Timer sind klassische Persistenzmechanismen. Angreifer nutzen sie, um Backdoors regelmäßig wiederherzustellen oder periodisch Daten zu exfiltrieren.

# Crontabs aller Benutzer prüfen
for user in $(cut -f1 -d: /etc/passwd); do crontab -u "$user" -l 2>/dev/null && echo "--- $user ---"; done

# System-weite Cron-Verzeichnisse
ls -la /etc/cron* /var/spool/cron/

# Systemd-Timer
systemctl list-timers --all

Prüfe außerdem /etc/rc.local, Skripte in /etc/init.d/ und falls vorhanden PAM-Module und LD_PRELOAD-Konfigurationen. Letztere werden seltener genutzt, sind aber bei gezielten Angriffen bekannt.

Schritt 6: Ausgehende Verbindungen kontrollieren

Aktive Command-and-Control-Verbindungen oder laufende Exfiltration sind an aktiven Netzwerkverbindungen zu erkennen:

# Aktuelle Verbindungen des Web-Worker-Prozesses
ss -tlnp
netstat -tulnp

# Laufende PHP-Prozesse mit Netzwerkverbindungen
lsof -i -n -P | grep php

Falls Netzwerküberwachung (Monitoring & Logging) am System aktiv ist, können historische Verbindungsdaten aus dem fraglichen Zeitraum rückwirkend ausgewertet werden. Verbindungen zu unbekannten externen IPs auf ungewöhnlichen Ports aus dem Web-Worker-Prozess sind ein starkes Indiz für aktive Ausnutzung.

Schritt 7: Secrets und Konfigurationen als kompromittiert behandeln

Dieser Schritt wird häufig übersprungen, weil er organisatorisch aufwendig ist. Er ist aber unabhängig davon erforderlich, ob eine Kompromittierung nachgewiesen wurde oder nur möglich war.

Alle Secrets rotieren, die im fraglichen Zeitraum auf dem Server gespeichert waren:

• Datenbankpasswörter
• API-Keys und Tokens (Payment-Provider, Mail-Dienste, Cloud-APIs)
• Privater SSH-Key des Servers
• S3- oder Object-Storage-Credentials
• Signaturkeys für Sessions und JWTs

Wer Secrets-Management-Werkzeuge wie Vault oder Infisical einsetzt, kann die Rotation zentral und nachvollziehbar durchführen. Wer Secrets in .env-Dateien direkt auf dem Server speichert, muss jeden Dienst, der diese Credentials kennt, nach der Rotation auf die neuen Werte umstellen.

Wichtig: Die Rotation ist nicht optional, sobald RCE im fraglichen Zeitraum auch nur möglich war. Der Angreifer muss die Credentials nicht nachweislich exfiltriert haben – die Möglichkeit reicht.

Schritt 8: Wiederanlauf und Härtung

Erst wenn die vorigen Schritte dokumentiert und abgeschlossen sind, ist der Wiederanlauf sinnvoll – sofern der Dienst zwischenzeitlich offline gestellt wurde. Für Systeme, die während der Untersuchung weitergelaufen sind, gelten die folgenden Punkte trotzdem:

Patch und Worker-Neustart bestätigen

php -v
# Ausgabe muss 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 zeigen

Der Neustart aller PHP-Worker ist zwingend. Bei Apache mod_php bedeutet das einen vollständigen Apache-Neustart (systemctl restart apache2). Bei PHP-FPM muss der FPM-Dienst neu gestartet werden – ein Reload reicht nicht.

Teilmaßnahmen als dauerhafte Ergänzung

Das PHP-Advisory nennt mehrere Maßnahmen, die keine vollständige Abhilfe bieten, aber das Angriffsfenster zusätzlich verkleinern. Empfehlenswert als dauerhafte Konfiguration:

memory_limit=-1 administrativ zu setzen schützt laut PHP-Projekt nicht ausreichend, wenn keine RLIMIT_AS/RLIMIT_DATA-Grenzen gesetzt sind.

Praxisbeispiel: Wie eine strukturierte Prüfung aussehen kann

Hypothetisches Szenario: Ein Onlineshop-Betreiber mit Apache mod_php und PHP 8.3.34 erfährt am 22. Oktober 2026 von den CVEs. Der Shop war seit dem 21. Oktober ohne Einschränkungen erreichbar. Der Betreiber beginnt die Prüfung mit der Zeitfenster-Eingrenzung (21.–22. Oktober), wertet die Apache-Zugriffslogs auf ungewöhnliche POST-Requests mit großen Bodies aus und findet drei Anfragen auf einen Checkout-Endpunkt mit einem unbekannten User-Agent.

Die korrespondierenden PHP-Fehlerlog-Einträge zeigen OOM-Abbrüche aus php_ini_parser.c. Eine Dateisuche im Dokumentenstamm ergibt eine .php-Datei im Upload-Verzeichnis, die nicht zum Deployment gehört und typische Webshell-Konstrukte enthält (eval(base64_decode(...)) ). Der Betreiber stellt den Shop offline, rotiert alle Datenbankpasswörter und API-Keys, entfernt die Webshell, prüft die Benutzerliste auf neue Einträge und kontaktiert anschließend seinen IT-Dienstleister für eine vollständige forensische Einschätzung.

Das ist kein Worst Case – es ist ein Beispiel dafür, warum die Prüfung lohnt. Wer nicht sucht, findet auch nichts. Findet aber auch nichts aus einem anderen Grund: weil er nicht gesucht hat.

Grenzen der Selbstprüfung

Die beschriebenen Schritte sind für technisch versierte Administratoren umsetzbar. Sie ersetzen keine forensische Analyse. Wer auf konkrete Kompromittierungs-Indikatoren stößt – eine Webshell, einen unbekannten Systemnutzer, ausgehende Verbindungen aus dem Web-Worker-Prozess – sollte die Untersuchung nicht allein weiterführen.

Gründe:

• Laufende forensische Analysen können Spuren durch Schreibzugriffe verändern.
• Rootkits und kompromittierte Systembinaries können reguläre Prüfwerkzeuge täuschen.
• Die Einschätzung, ob eine Meldepflicht nach Art. 33 DSGVO besteht, braucht eine rechtliche Bewertung auf Basis der Untersuchungsergebnisse.

Gleiches gilt für die Frage, ob eine vollständige Neuinstallation des Systems einer Bereinigung vorzuziehen ist – in vielen Fällen ist sie es, weil sie die Wiederherstellung eines sauberen Zustands sicherer und dokumentierbarer macht als das gezielte Entfernen einzelner Artefakte.

Für Betreiber von PHP-Systemen, die zwischen dem 21. Oktober und dem Patch-Zeitpunkt öffentlich erreichbar waren, lohnt sich die Beratung durch einen IT-Sicherheitsdienstleister – nicht als Pauschalmaßnahme, sondern als gezielte Analyse der eigenen Situation.

Nach der Prüfung: PHP-Version und Supportstatus langfristig beachten

Wer PHP 8.1 oder älter betreibt, hat für diese CVEs keinen offiziellen Patch vom PHP-Projekt erhalten. Distributionen und Hoster wie Plesk liefern teils eigene Backports – deren Vollständigkeit und Langzeitpflege ist aber nicht garantiert.

Die offiziellen Supportzeiträume laut php.net:

PHP 8.1 ist bereits außerhalb des offiziellen Supports. Wer jetzt noch auf 8.1 oder älter betreibt, sollte den Handlungsplan zur PHP-Sicherheitslücke 2026 lesen und eine Version-Migration priorisieren – nicht nur wegen dieser CVEs, sondern weil zukünftige kritische Schwachstellen ohne aktuellen Support keine offiziellen Patches erhalten.

Was SW Business Solutions dabei übernimmt

Die Analyse eines möglicherweise kompromittierten Systems ist kein Standardfall der laufenden IT-Betreuung. Sie erfordert eine strukturierte Vorgehensweise, die Befunde dokumentiert und nachvollziehbar macht – für die eigene IT-Abteilung, für externe Prüfer und im Zweifelsfall für die Datenschutzaufsicht.

SW Business Solutions unterstützt Unternehmen bei der technischen Eingrenzung, der Bewertung von Befunden, der sicheren Bereinigung und dem dokumentierten Wiederanlauf. Das schließt die Rotation kompromittierter Secrets, die Einschätzung zur Meldepflicht und die Empfehlung zur weiteren IT-Härtung ein.

Wenn Sie ein PHP-System nach der Sicherheitslücke prüfen lassen möchten oder unsicher sind, ob Ihr System im gefährdeten Zeitraum kompromittiert wurde, nehmen Sie Kontakt auf. Eine erste Einschätzung der eigenen Situation ist der sinnvolle nächste Schritt – bevor ein unentdeckter Angreiferzugang zum dauerhaften Problem wird.

→ Jetzt Erstgespräch vereinbaren und PHP-System auf Kompromittierung prüfen lassen