PHP2Shell zeigt ein Problem, das weit über eine kritische Sicherheitslücke hinausgeht.
Mit PHP2Shell (CVE-2026-109618 und CVE-2026-109619) wurden zwei kritische Schwachstellen bekannt, die unter bestimmten Voraussetzungen eine Remote Code Execution ermöglichen. Mit einem CVSS-Score von jeweils 9,2 war klar: Hier ist schnelles Handeln gefragt.
Doch genau an dieser Stelle offenbart sich in vielen Unternehmen ein Problem, das mit PHP selbst erst einmal wenig zu tun hat.
Wie reagiert man schnell, wenn man nicht weiß, wo man betroffen ist?
Bevor überhaupt über Patches, Mitigationsmaßnahmen oder die Bewertung möglicher Angriffswege gesprochen werden kann, müssen zunächst ganz grundlegende Fragen beantwortet werden:
- Wo setzen wir selbst PHP ein? In welchen Anwendungen, internen Diensten, Webplattformen oder sogar selbst entwickelten Produkten? Und in welchen Versionen?
- Welche unserer Lieferanten setzen PHP ein? Sind deren Produkte oder Dienstleistungen betroffen? Welche Abhängigkeiten bestehen, und wie erhalten wir belastbare Informationen über deren Sicherheitsstatus?
- Welche unserer Kunden müssen wir informieren? Welche Produkte, Dienstleistungen oder betriebenen Systeme könnten betroffen sein? Wo bestehen vertragliche Informationspflichten oder konkrete Risiken für unsere Kunden?
Das sind keine Fragen, die ein Unternehmen erst im Rahmen einer akuten Sicherheitswarnung beantworten können sollte.
Und trotzdem beginnt genau dann häufig die Suche.
Excel-Listen werden zusammengetragen, Entwickler befragt, Dienstleister kontaktiert und Verantwortlichkeiten geklärt. Unterschiedliche Abteilungen versuchen unter erheblichem Zeitdruck, ein Bild der eigenen IT-Landschaft und ihrer Abhängigkeiten zu erstellen. Während die Zeit für eine wirksame Reaktion läuft, wird zunächst versucht, überhaupt die Informationsgrundlage dafür zu schaffen.
Das Problem ist nicht der Patchprozess, sondern die fehlende Transparenz
Das eigentliche Problem ist dabei nicht zwangsläufig ein fehlender Patchprozess. Es ist die fehlende Transparenz über die eigenen Assets, eingesetzten Technologien, Lieferantenabhängigkeiten und Kundenbeziehungen.
Ein funktionierendes Schwachstellenmanagement braucht mehr als einen Vulnerability-Scanner und definierte Reaktionszeiten. Es braucht eine belastbare Informationsbasis:
- Ein aktuelles Asset- und Softwareinventar, einschließlich relevanter Komponenten und Abhängigkeiten.
- Transparenz über eingesetzte Drittprodukte, Dienstleister und deren technologische Abhängigkeiten.
- Klare Zuordnungen zwischen betroffenen Systemen, Geschäftsprozessen, Produkten und Kunden.
- Definierte Verantwortlichkeiten und Kommunikationswege, die auch unter Zeitdruck funktionieren.
Dabei geht es nicht darum, jede Information in einem einzigen System abzulegen. Entscheidend ist, dass sie verlässlich vorhanden, miteinander verknüpft und im Bedarfsfall kurzfristig verfügbar ist.
Denn fehlende Informationen sind im Ernstfall nicht nur ein administratives Problem. Sie können ein Unternehmen faktisch handlungsunfähig machen.
Die nächste Schwachstelle trifft eine andere Technologie – die Fragen bleiben
PHP2Shell ist dafür ein aktuelles Beispiel. Die nächste kritische Schwachstelle wird eine andere Technologie betreffen. Die grundlegenden Fragen werden aber dieselben bleiben.
Und genau deshalb sind Asset Management, Softwareinventarisierung und Lieferantenmanagement keine lästigen Dokumentationspflichten, die man für ein ISO-27001-Audit erfüllt. Sie sind elementare Voraussetzungen für operative Informationssicherheit und wirksames Incident Response Management.
Die entscheidende Frage lautet deshalb nicht nur: Wie schnell können wir eine bekannte Schwachstelle schließen?
Sondern bereits einen Schritt davor: Wie schnell können wir überhaupt feststellen, ob, wo und in welchem Umfang wir betroffen sind?
Wer darauf keine belastbare Antwort hat, sollte genau dort ansetzen.
