PHP2Shell: Asset Discovery und Patching

Die kritischen PHP-Schwachstellen CVE-2026-109618 und CVE-2026-109619 verdeutlichen ein wiederkehrendes Problem im Vulnerability Management: Die technische Korrektur ist zwar verfügbar, doch die tatsächlich betroffenen Laufzeiten sind oft nicht vollständig sichtbar. PHP veröffentlichte am 21. Oktober 2026 Sicherheitsupdates. Beide Schwachstellen wurden am 26. Oktober in den CISA-Katalog Known Exploited Vulnerabilities aufgenommen; die offiziellen CISA-ADP-Einträge führen den Exploitation-Status als „active“.

Damit ist PHP2Shell nicht allein ein Patch-Management-Fall. Organisationen müssen kurzfristig klären, wo PHP Webanfragen verarbeitet, welche Systeme aus dem Internet erreichbar sind, welche Komponenten in Containern oder Produkten eingebettet sind und ob Hinweise auf eine bereits erfolgte Kompromittierung bestehen.

Betroffenheit umfasst mehr als installierte PHP-Pakete

Nach Angaben des PHP-Projekts betreffen die Schwachstellen Installationen, die Webanfragen bedienen. Dazu zählen PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Bei mod_php besteht laut PHP ein besonders hohes Risiko, weil ein demonstrierter Exploit noch vor der Ausführung des Anwendungscodes ausgelöst werden kann.

Ein klassischer Host-Scan erfasst jedoch nicht zwingend alle relevanten Instanzen. PHP kann in Container-Images, Kubernetes-Workloads, Appliances, Standardsoftware, Build-Artefakten oder Managed-Angeboten enthalten sein. Auch ein Reverse Proxy kann die externe Erreichbarkeit einer dahinterliegenden PHP-Laufzeit verschleiern. Deshalb sollte die Betroffenheitsanalyse nicht bei der Frage enden, auf welchem Server ein PHP-Paket installiert ist.

Ein belastbares Lagebild entsteht durch die Zusammenführung mehrerer Datenquellen:

Inventare extern erreichbarer Webdienste sowie Routing-Daten von Reverse Proxies und Load Balancern,
Host-, VM- und Container-Inventare einschließlich laufender Images und Registries,
Build-Artefakte, Softwarestücklisten und Deployment-Metadaten,
CMDB- und Service-Owner-Informationen,
Hersteller-, Lieferanten- und Managed-Service-Listen für Produkte mit eingebetteten Komponenten.

Für Drittprodukte reicht eine unbestätigte Annahme der Nichtbetroffenheit nicht aus. Produktversion, eingebettete PHP-Laufzeit, Herstellerbewertung und geplanter Patch- oder Isolationsweg sollten nachvollziehbar dokumentiert werden. Das Canadian Centre for Cyber Security empfiehlt ausdrücklich, neben eigenen Installationen auch Drittprodukte, Appliances und Container mit eingebetteten PHP-Komponenten zu identifizieren.

Priorisierung nach Exposition und Schadenspotenzial

Die verfügbaren Updates beheben nicht authentisierte Remote-Code-Execution-Schwachstellen. CVE-2026-109618 betrifft laut PHP die Behandlung von Out-of-Memory-Situationen mit teilweise initialisierten internen Request-Daten. CVE-2026-109619 betrifft internen Zustand, der nach Freigabe des zugrunde liegenden Speichers weiterverwendet wird. Beide Fehlerbilder können zu Remote Code Execution führen.

Für die operative Reihenfolge ist daher eine risikobasierte Bewertung sinnvoll. Höchste Priorität haben typischerweise internetexponierte PHP-Dienste, insbesondere mod_php-Installationen. Weitere relevante Kriterien sind nicht vertrauenswürdige Uploads oder umfangreiche POST-Verarbeitung, hohe Schutzbedarfe, privilegierte Systemzugriffe und die technische oder organisatorische Reichweite eines kompromittierten Dienstes. Dies ist keine starre rechtliche Rangfolge, sondern eine fachliche Priorisierung zur schnellen Risikoreduktion.

CISA empfahl, PHP-Installationen organisationsweit zu inventarisieren und internetexponierte Systeme vorrangig zu aktualisieren. Sind Updates für nicht unterstützte Versionen oder aus anderen Gründen nicht kurzfristig möglich, sollen PHP-basierte Systeme bis zur Sanierung offline genommen werden. Wo ein vollständiges Offline-Nehmen nicht möglich ist, kann zumindest die Isolation von öffentlichen Netzen die Exposition reduzieren.

Sanierung ist Update, Neuaufbau und Neustart

PHP stellte die korrigierten Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 bereit. Die Sanierung muss jedoch den gesamten Auslieferungsweg erfassen. Bei containerisierten Anwendungen bedeutet dies regelmäßig: korrigiertes Basis-Image bereitstellen, abhängige Images neu bauen, Artefakte prüfen, Workloads neu ausrollen und alte Instanzen beenden. Ein aktualisiertes Image in einer Registry senkt das Risiko nicht, solange produktive Deployments weiter die alte Laufzeit verwenden.

Auch bei klassischen Serverinstallationen darf die Maßnahme nicht mit einem Paketupdate enden. Für CVE-2026-109619 weist PHP darauf hin, dass sämtliche Worker neu gestartet werden müssen. Der Nachweis der Behebung sollte daher die installierte oder eingebettete Version, den Deployment-Stand und den erfolgreichen Neustart der tatsächlich bedienenden Prozesse verbinden.

PHP 8.1 und ältere Versionen erhalten keine regulären Updates mehr. Das PHP-Projekt verweist auf mögliche Backports durch Distributionen oder LTS-Anbieter sowie auf das Upgrade auf eine unterstützte Version. Für PHP 7.4, 8.0 und 8.1 wurden wegen der Schwere minimale Source-Backports bereitgestellt. Ein verfügbarer Vendor- oder Minimal-Backport kann kurzfristig relevant sein, ersetzt aber nicht die Behandlung des grundsätzlichen Lebenszyklusrisikos. Die Migration auf eine unterstützte Laufzeit sollte als eigener, terminierter Risikobehandlungsplan geführt werden.

Übergangsmaßnahmen reduzieren Pfade, ersetzen aber kein Update

Das PHP-Projekt beschreibt technische Maßnahmen, die bekannte Angriffspfade begrenzen können. Für CVE-2026-109618 gehören dazu die Entfernung eines steuerbaren PHP-Speicherlimits, restriktive Größenlimits für POST- und Upload-Anfragen sowie Container- oder cgroup-Limits als Verfügbarkeitsgrenze. RLIMIT_AS und RLIMIT_DATA sollen hierfür ausdrücklich nicht als Ersatz verwendet werden.

Für CVE-2026-109619 kann session.upload_progress.enabled vor dem Request-Parsing deaktiviert werden. Bei PHP 8.5 kann zudem fatal_error_backtraces=0 einen bestätigten Angriffspfad blockieren. Diese Einstellungen decken laut PHP nicht alle Varianten ab. Sie sind deshalb nur als dokumentierte, zeitlich begrenzte Kompensationsmaßnahmen vertretbar, etwa bis ein Lieferantenpatch verfügbar ist oder ein sicherer Neuaufbau abgeschlossen wurde.

Eine Ausnahmeentscheidung sollte mindestens verantwortliche Eigentümer, Geschäfts- und Expositionsrisiko, technische Einschränkungen, konkrete Gegenmaßnahmen, Monitoring, ein Entscheidungsdatum, einen verbindlichen Sanierungstermin und einen Eskalationsweg enthalten. WAF-Regeln oder PHP-Konfigurationen dürfen nicht als Abschluss der Sanierung bewertet werden.

Kompromittierungsprüfung und Detection Engineering

Bei aktiv ausgenutzten Schwachstellen ist Patching allein kein ausreichender Abschluss. Betroffene oder potenziell betroffene Systeme sollten auf Anzeichen einer Kompromittierung untersucht werden. Das Canadian Centre for Cyber Security nennt dafür insbesondere Webserver-, Applikations-, Authentifizierungs- und Endpoint-Logs. Operativ sollten diese Daten mit PHP- und FPM-Fehlerlogs, Reverse-Proxy-Protokollen, Prozess-Telemetrie, Dateiänderungen, neuen Konten, Cron- oder Systemd-Änderungen sowie ausgehenden Netzwerkverbindungen korreliert werden.

Die von CISA veröffentlichte Sigma-Regel verknüpft potenzielle Exploit-Versuche mit HTTP-Request-Mustern, PHP-Fehlern, Prozessstarts aus Web- oder PHP-Diensten sowie Shell- und Download-Kommandos. CISA kennzeichnet die Regel als test und weist auf mittel bis hohe False-Positive-Raten einzelner Zweige hin. Sie eignet sich deshalb als Ausgangspunkt für validiertes Detection Engineering, nicht als alleiniger Beweis für oder gegen eine Kompromittierung.

Governance und Lieferantensteuerung

Für Einrichtungen im jeweiligen Anwendungsbereich der nationalen NIS2-Umsetzung ist der Fall ein praktisches Beispiel für Risikomanagement. Artikel 21 der NIS2-Richtlinie nennt unter anderem Incident Handling, Lieferkettensicherheit sowie Sicherheit bei Beschaffung, Entwicklung und Wartung einschließlich Vulnerability Handling. Welche konkrete Pflicht eine Organisation trifft, hängt jedoch von der anwendbaren nationalen Umsetzung und dem sachlichen Anwendungsbereich ab.

Für Hersteller von Produkten mit digitalen Elementen ist außerdem der Cyber Resilience Act relevant. Seit dem 11. September 2026 gelten nach Artikel 14 Meldepflichten für aktiv ausgenutzte Schwachstellen. Die zentralen allgemeinen Anforderungen an Vulnerability Handling, Komponenteninventarisierung und Softwarestücklisten gelten grundsätzlich ab dem 11. Dezember 2027. Der CRA ist keine allgemeine Betreiberpflicht für jede PHP-Installation, macht für Hersteller und Integratoren aber transparente Komponenteninformationen und belastbare Reaktionsprozesse besonders wichtig.

PHP2Shell zeigt damit vor allem eine operative Konsequenz: Schnelles Patchen funktioniert nur, wenn die Organisation ihre Laufzeiten, Abhängigkeiten, Produktlieferanten und Deployments bereits ausreichend kennt. Wo diese Transparenz fehlt, müssen Discovery, Expositionsanalyse, temporäre Isolation und Kompromittierungsprüfung parallel zum Patch-Rollout erfolgen.