Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 verdeutlichen erneut, dass kritische Runtime-Risiken nicht mit einer Suche nach offensichtlichen, selbst betriebenen PHP-Webanwendungen beherrscht werden können. Beide Schwachstellen können unter bestimmten Bedingungen nicht authentisierte Remote-Code-Ausführung ermöglichen. CISA hat sie am 26. Oktober 2026 in den Katalog der Known Exploited Vulnerabilities aufgenommen. Das bestätigt bekannte aktive Ausnutzung, ist aber kein Beleg dafür, dass jede ungepatchte Instanz bereits kompromittiert wurde.
Redaktionell sollte diese Faktenlage zur Aktualisierung und Vertiefung des bereits vorhandenen Beitrags genutzt werden, nicht für einen parallelen Beitrag mit demselben Kernansatz. Der Mehrwert liegt in den inzwischen verifizierten Fixständen, der bestätigten aktiven Ausnutzung sowie der präziseren Abgrenzung von Betreiber-, Lieferanten- und Herstellerrollen.
Fixstände und aktive Ausnutzung richtig einordnen
Die beiden Schwachstellen betreffen die PHP-Request-Verarbeitung. CVE-2026-109618 steht im Zusammenhang mit fehlerhaften Zuständen nach Out-of-Memory-Fehlern. CVE-2026-109619 betrifft die weitere Nutzung eines internen Request-Zustands, nachdem der zugrunde liegende Speicher freigegeben wurde. Das PHP-Projekt veröffentlichte am 21. Oktober 2026 Sicherheitsreleases für PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Nach Angaben des Projekts ist ein Update die einzige sichere vollständige Reaktion.
Betroffen sind nach dem AWS-Sicherheitsbulletin die Versionen 8.2.0 bis 8.2.34, 8.3.0 bis 8.3.35, 8.4.0 bis 8.4.26 sowie 8.5.0 bis 8.5.11. Für die nicht mehr unterstützten Zweige PHP 5.4 bis 8.1 wurde kein Upstream-Fix veröffentlicht. Wo solche Versionen eingesetzt werden, ist daher nicht eine Ausnahmegenehmigung für dauerhaftes Weiterbetreiben, sondern die Migration auf einen unterstützten Zweig die erforderliche dauerhafte Perspektive.
Temporäre Minderungsmaßnahmen können erforderlich sein, wenn ein Update nicht unmittelbar möglich ist. Sie ersetzen jedoch keinen unterstützten Fix. Ihre Wirksamkeit, funktionalen Nebenwirkungen und zeitliche Begrenzung müssen für das konkrete Produkt und Bereitstellungsmodell geprüft und dokumentiert werden.
Das Inventar muss eingebettete Runtimes erfassen
ENISA und das britische NCSC weisen ausdrücklich darauf hin, dass zahlreiche kommerzielle und Open-Source-Produkte PHP als Hintergrundkomponente einsetzen können. Eine Abfrage im Quellcode eigener Anwendungen oder eine Liste bekannter PHP-Server reicht deshalb nicht aus. Betroffen sein können Standardsoftware, Appliances, Container-Basisimages, Verwaltungsoberflächen, Hosting-Angebote und Managed Services.
Für eine belastbare Sofortinventur sollten Organisationen mehrere Datenquellen zusammenführen:
- CMDB, Asset-Management sowie Endpoint- und Server-Telemetrie,
- Paket-, Image- und Containerinventare einschließlich verwendeter Basisimages,
- Software-Composition-Analysis und Deployment-Artefakte,
- Webserver- und PHP-FPM-Konfigurationen,
- Ergebnisse externer Angriffsflächenanalysen,
- Listen eingesetzter Appliances sowie SaaS-, Hosting- und Managed-Service-Angebote.
Diese Erhebung ist keine rein technische Bestandsaufnahme. Jedes gefundene Asset oder Produkt benötigt einen verantwortlichen Owner, Angaben zum Deployment-Modell und eine nachvollziehbare Bewertung der Exponierung. Bei containerbasierten Produkten kann ein aktualisiertes Basisimage allein unzureichend sein: Kundencontainer müssen gegebenenfalls neu gebaut und bereitgestellt werden. Red Hat weist zudem darauf hin, dass technische Betroffenheit und Ausnutzbarkeit etwa zwischen PHP-FPM- und mod_php-Deployments variieren können.
Priorisierung nach Exponierung und Schadenspotenzial
Die Reihenfolge der Behandlung sollte nicht allein von der installierten Version oder einem abstrakten Schweregrad abhängen. Vorrang haben internetexponierte Anwendungen und Systeme, die nicht vertrauenswürdige HTTP-Requests verarbeiten. Dies umfasst auch administrative Oberflächen und Hosting-Umgebungen, sofern sie öffentlich erreichbar sind oder über vorgeschaltete Dienste erreichbar gemacht werden können.
In die Priorisierung gehören außerdem die Berechtigungen des PHP-Workers, der Zugriff auf produktive Daten und Secrets, mögliche Wege für laterale Bewegung, die Verfügbarkeit einer getesteten Herstellerkorrektur sowie das jeweilige Betriebsmodell. Wenn exponierte Anwendungen kurzfristig weder aktualisiert noch wirksam abgesichert werden können, empfehlen ENISA und die beteiligten europäischen Stellen, sie von öffentlichen Netzen zu isolieren. Das ist eine Risikoreduktion, keine Behebung der Ursache.
Cloud- und Managed-Modelle benötigen dabei eine getrennte Betrachtung von Plattformverantwortung und Kundenaktion. AWS nennt beispielsweise kundenseitig zu aktualisierende Custom-Runtimes und Container in Lambda, aktualisierte Plattformversionen für Elastic Beanstalk sowie Workloads, bei denen Kunden neue Instanzen bereitstellen oder selbst aktualisieren müssen. Eine pauschale Annahme, der Cloud-Anbieter habe die Schwachstelle vollständig erledigt, ist daher nicht belastbar.
Lieferantenkommunikation als Nachweisprozess organisieren
Indirekte Abhängigkeiten lassen sich häufig nur durch strukturierte Lieferantenabfragen auflösen. Einkauf, Third-Party-Risk-Management und technische Service Owner sollten solche Abfragen koordinieren und die Antworten dem jeweiligen Produkt, Service und Asset zuordnen. Zielführend sind insbesondere folgende Fragen:
- Ist das Produkt oder der Dienst in der konkret eingesetzten Version betroffen?
- Wird PHP oder eine eingebettete PHP-Komponente verwendet?
- Welcher Fix, welches Wartungsfenster und welche Kundenaktion sind vorgesehen?
- Welche Übergangsmaßnahmen empfiehlt oder betreibt der Lieferant?
- Welche Log-, Forensik- und Incident-Unterstützung steht zur Verfügung?
- Gibt es Hinweise auf eine bestätigte oder ausgeschlossene Kompromittierung des Dienstes?
Die Rückmeldung eines Lieferanten sollte nicht als bloße E-Mail im Vorgang verbleiben. Sie ist ein Nachweisbaustein für die Risikobewertung und muss mit dem technischen Geltungsbereich, dem Patchstatus und der Entscheidung über verbleibende Risiken verknüpft werden. Ebenso sollten Organisationen dokumentieren, wenn eine Antwort aussteht, unpräzise bleibt oder nur Aussagen zu Teilen des Betriebsmodells enthält.
Patchen beseitigt keine mögliche Kompromittierung
Bei Systemen, die über längere Zeit exponiert waren oder verdächtige Aktivitäten zeigen, genügt ein Update nicht als alleinige Reaktion. Das NCSC empfiehlt vor einem Update oder einer Minderungsmaßnahme ausdrücklich die Prüfung auf Kompromittierung und Backdoors. Ein Patch schließt die Schwachstelle, entfernt aber keine Webshells, Persistenzmechanismen oder missbräuchlich erlangten Zugangsdaten, die bereits durch eine Ausnutzung entstanden sein könnten.
Die konkrete Reaktion sollte dem Incident-Response-Prozess folgen. Je nach Risikolage gehören dazu die Sicherung relevanter Logs und flüchtiger Daten, die Suche nach Webshells und unerwarteten Änderungen, die Prüfung von Service-Accounts und Secrets sowie gegebenenfalls der Neuaufbau aus vertrauenswürdigen Artefakten. Patch-Entscheidungen und Ausnahmen sollten mindestens Asset, Owner, Version, Deployment-Modell, Exponierung, Risikobewertung, gewählte Maßnahme, Test- und Rollback-Nachweis, Kompensationsmaßnahmen, Ablaufdatum und Lieferantenrückmeldung enthalten.
CRA und NIS2: Rollen sauber trennen
Seit dem 11. September 2026 gelten für Hersteller im Anwendungsbereich des Cyber Resilience Act vorgezogene Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle. Für aktiv ausgenutzte Schwachstellen sieht der CRA grundsätzlich eine Frühwarnung binnen 24 Stunden, eine Meldung binnen 72 Stunden sowie einen Abschlussbericht spätestens 14 Tage nach Verfügbarkeit einer Korrektur- oder Minderungsmaßnahme vor. Diese Pflichten treffen Hersteller; sie ersetzen nicht die Betreiberverantwortung für Bewertung, Absicherung und Incident Response.
Die weitergehenden CRA-Hauptanforderungen, einschließlich Cybersecurity-by-Design und Schwachstellenbehandlung über den Produktlebenszyklus, gelten grundsätzlich erst ab dem 11. Dezember 2027. Davon getrennt erfasst Artikel 21 NIS2 unter anderem Schwachstellenbehandlung und Lieferkettenrisiken. Für Einrichtungen im jeweiligen Anwendungsbereich ist die konkrete Verpflichtung zusätzlich anhand der einschlägigen nationalen Umsetzung zu bestimmen. Operativ bleibt der Kern gleich: Direkte Lieferanten und Dienstleister müssen in das Cyberrisikomanagement einbezogen werden.
PHP2Shell ist damit vor allem ein Test für die Qualität vorhandener Inventar-, Exposure- und Lieferantenprozesse. Organisationen, die Runtime-Komponenten, Produktabhängigkeiten und Verantwortlichkeiten kurzfristig zusammenführen können, schaffen die Grundlage für eine angemessene technische Reaktion und belastbare Nachweise.