Die Schwachstellen CVE-2026-109618 und CVE-2026-109619, häufig als PHP2Shell zusammengefasst, sind ein akutes Beispiel dafür, warum Notfall-Patching nicht bei einer Liste klassischer Webserver enden darf. Unter bestimmten Bedingungen können sie unauthentifizierte Remote-Code-Ausführung ermöglichen. Die vom PHP-Projekt veröffentlichten Fixstände sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Entscheidend ist jedoch nicht allein, welche Version auf bekannten Webhosts läuft. Organisationen müssen feststellen, wo PHP tatsächlich Web-Requests verarbeitet – auch innerhalb von Container-Images, Appliances, Management-Oberflächen und Herstellerprodukten.
Der operative Schwerpunkt sollte daher auf einem kurzen, nachvollziehbaren Runbook liegen: Runtime-Fundstellen technisch erfassen, Exposition und Auswirkungen priorisieren, Spuren möglicher Ausnutzung sichern, dann patchen oder befristet mitigieren. Das unterscheidet eine belastbare Remediation von einer bloßen Versionsabfrage.
Warum PHP2Shell kein reines Webserver-Patchproblem ist
Der relevante Scope sind PHP-Installationen, die Web-Requests bedienen. Dazu zählen unter anderem PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das PHP-Projekt hebt mod_php als besonders risikoreich hervor, weil ein demonstrierter Angriff vor der Ausführung des Anwendungscodes ausgelöst werden kann. Eine Anwendung muss also nicht zwingend selbst fehlerhaft programmiert sein, damit ihr bereitgestellter Runtime-Pfad relevant wird.
Diese Einordnung verschiebt die Fragestellung im Notfall: Nicht nur „Welche Webanwendungen betreiben wir?“, sondern „Welche Produkte und Plattformen enthalten eine Request-verarbeitende PHP-Runtime?“. Nationale Cyber-Sicherheitsstellen empfehlen ausdrücklich, neben klassischen Webservern auch Drittprodukte, Appliances, Services und Container mit eingebetteten PHP-Komponenten zu identifizieren. Zuerst zu behandeln sind internetexponierte Systeme.
Das Notfallinventar technisch aufbauen
Eine Suche nach installierten PHP-Paketen ist ein sinnvoller Anfang, aber kein ausreichender Nachweis. Ein Notfallinventar sollte jede Fundstelle mit dem tatsächlich betroffenen Service verknüpfen. Für jede Zeile sind mindestens Asset oder Service, fachlicher und technischer Eigentümer, Runtime- und Paketquelle, exakte Build- oder Backport-Information, Web-SAPI, Exposition, Berechtigungen des Worker-Prozesses, verarbeitete Daten sowie Supportstatus festzuhalten.
Bei Container- und Kubernetes-Workloads kommen das verwendete Basisimage, Image-Digest und die Deployment-Artefakte hinzu. Entscheidend ist nicht, ob ein Image-Tag aktualisiert wurde, sondern ob ein verifiziertes Image neu gebaut, ausgerollt und als tatsächlich laufender Digest geprüft wurde. Kundenseitig betriebene PHP-Custom-Runtimes und Container-Images, etwa in AWS Lambda, liegen nach den AWS-Hinweisen in der Verantwortung des Kunden und müssen aktualisiert sowie erneut bereitgestellt werden.
Bei Appliances und Drittsoftware ist eine reine Produktnamenliste ebenfalls nicht belastbar. Die Übersicht des NCSC-NL ist ausdrücklich nur ein Ermittlungsansatz; Einträge müssen produkt-, release- und runtimebezogen gegen Hersteller- oder Upstream-Angaben validiert werden. Eigene Anwendungen werden dort zudem nicht vollständig abgebildet.
Priorisierung nach Exposition und Prozessrechten
Die Reihenfolge der Abhilfe sollte nicht allein aus der Schwachstellenkennung oder einem Scan-Befund folgen. Vorrang haben extern erreichbare Runtimes, die Requests verarbeiten. Danach sind insbesondere Systeme mit weitreichenden Worker-Rechten, Zugriff auf Secrets, produktive Daten oder administrative Funktionen zu behandeln. Management- und Administrationsoberflächen verdienen besondere Aufmerksamkeit, weil ihr Kompromittierungspotenzial über den einzelnen Dienst hinausgehen kann.
„Intern“ bedeutet dabei nicht automatisch geringes Risiko. Reverse Proxies, VPN-Zugänge, Partneranbindungen oder laterale Wege können die tatsächliche Erreichbarkeit wesentlich verändern. Für jede Fundstelle sollte deshalb dokumentiert werden, ob und über welche Pfade sie erreichbar ist, welche Schutzschichten vorgeschaltet sind und welche geschäftlichen Folgen ein Ausfall oder Datenzugriff hätte. Diese Einordnung schafft eine nachvollziehbare Patch-Reihenfolge und macht offene Restrisiken sichtbar.
EOL, Backports und Herstellerstatus getrennt bewerten
Bei PHP 8.1 und älteren Zweigen veröffentlicht das PHP-Projekt keine regulären Updates mehr. Die sichtbare Upstream-Versionsnummer genügt dennoch nicht als alleiniger Beleg für Verwundbarkeit oder Behebung: Distributions- oder LTS-Anbieter können Fixes zurückportieren. Umgekehrt ist ein Scanner-Befund ohne Prüfung von Paketstand, Build und Herstellerinformation keine ausreichende Grundlage für die Entscheidung, ein System sei bereits abgesichert.
Für EOL-Runtimes sind drei Fragen getrennt zu beantworten: Liegt ein belastbarer Vendor-Backport vor? Reduzieren temporäre Kontrollen die konkrete Exposition ausreichend und sind sie betrieblich vertretbar? Wenn beides nicht zutrifft, muss eine isolierte Weiterführung, Außerbetriebnahme oder beschleunigte Migration als dokumentierte Risikoentscheidung behandelt werden. AWS verweist für die EOL-Zweige 5.4 bis 8.1 auf fehlende Upstream-Behebung für CVE-2026-109618 und fordert die Migration auf einen unterstützten Zweig.
Bei Drittprodukten braucht der Notfallprozess ein verbindliches Statusfeld je Produkt und Release: betroffen, nicht betroffen, unter Untersuchung, Workaround verfügbar, Fix verfügbar oder kein Fix beziehungsweise Supportende. Cisco zeigt, dass diese Bewertung innerhalb eines Portfolios je Komponente, Betriebsmodus und Cloud-Service unterschiedlich ausfallen kann. Allgemeine Aussagen eines Herstellers dürfen daher nicht auf eine konkrete Appliance übertragen werden.
Forensik vor Upgrade, Neustart oder Abschaltung
Eine Remediation kann flüchtige Spuren zerstören. Für extern exponierte Systeme, deren Behebung verzögert war, ist deshalb eine risikobasierte Kompromittierungsprüfung vor oder während der Abhilfe angemessen. NCSC UK und das Canadian Centre nennen hierfür Webserver-, Anwendungs-, Authentifizierungs- und Endpoint-Logs sowie unerwartete Prozesse, Befehle, Dateien, Konten und ausgehende Verbindungen im Kontext von PHP- oder Webserver-Diensten.
Vor Upgrade, Worker-Neustart, Image-Rollout oder Abschaltung sollten – soweit ohne zusätzliche Gefährdung möglich – Zeitfenster und Request-Logs, WAF- und Proxy-Ereignisse, PHP- und Webserver-Logs, Prozessbaum, Netzwerkverbindungen sowie Container-, Cloud- und Orchestrierungs-Audit-Logs gesichert werden. Verdächtige Dateien und Konten sind in die Untersuchung einzubeziehen. Die Ergebnisse gehören mit Zeitbezug zum jeweiligen Asset in die Incident-Dokumentation.
Threat Hunting sollte mehrstufig erfolgen: zunächst auf Exploit-nahe Request- und PHP-Fehlerindikatoren, danach auf Prozessketten vom Web- oder PHP-Worker zu Shells, Download-Werkzeugen oder Persistenzmechanismen. Die von CISA veröffentlichte Sigma-Regel kann hierbei ein Ausgangspunkt sein. Sie trägt jedoch den Status „test“, weist je Zweig mittlere bis hohe False-Positive-Raten aus und muss an Logquellen und erwartetes Anwendungsverhalten angepasst werden. Sie ist kein automatischer Kompromittierungsnachweis.
Die Dringlichkeit einer solchen Prüfung wird durch unterschiedliche Lagebilder gestützt, ohne einen erfolgreichen Angriff auf ein konkretes Unternehmen zu belegen: Cloudflare berichtete zum Zeitpunkt der Offenlegung über Angriffsverkehr und variierende Payloads gegen Kunden, während CISA am selben Tag noch keine beobachtete Ausnutzung meldete. Für exponierte, erst verspätet behobene Systeme ist daraus eine vorsorgliche Prüfung ableitbar, nicht aber die pauschale Annahme eines Incidents.
Mitigieren, aber nicht mit einem Fix verwechseln
WAF-Regeln, Request-Größenbegrenzungen, die Deaktivierung einzelner Funktionen und Netzwerkisolation können Übergangsmaßnahmen sein. Das PHP-Projekt bezeichnet ein Update jedoch als einzige vollständige Lösung; auch AWS bewertet Konfigurationsänderungen nicht als vollständige Mitigation. Jede Zwischenmaßnahme sollte daher befristet sein, auf Wirksamkeit und Nebenwirkungen getestet werden und ein klares Patch- oder Migrationsziel erhalten.
Ein zentraler Lagebericht verbindet die technischen und organisatorischen Aufgaben: vollständige Asset-Liste, Priorisierungsentscheidung, Herstellerstatus, gesicherte Spuren, gewählte Mitigation, Patch- oder Migrationsnachweis und akzeptierte Restrisiken. Für Einrichtungen im Anwendungsbereich der jeweiligen nationalen NIS2-Umsetzung ist dies auch fachlich anschlussfähig: Artikel 21 der NIS2-Richtlinie nennt unter anderem Asset Management, Vulnerability Handling, Lieferkettensicherheit, Incident Handling sowie Business Continuity und Krisenmanagement als Maßnahmenfelder. Die Richtlinie selbst begründet jedoch keine unmittelbare, einzelfallbezogene PHP-Pflicht; maßgeblich bleiben nationale Umsetzung und Anwendungsbereich.
Das Ziel der nächsten 72 Stunden ist somit nicht nur eine hohe Patch-Quote. Erforderlich ist ein belastbarer Nachweis, welche Request-verarbeitenden PHP-Runtimes vorhanden waren, wie sie priorisiert wurden, ob Hinweise auf Kompromittierung geprüft wurden und warum verbliebene Ausnahmen vertretbar oder kurzfristig zu beenden sind.