Kritische Lücken im PHP-Kern legen Websites lahm: eco gibt Betreibern Sofortmaßnahmen an die Hand und fordert mehr Transparenz in der Software-Lieferkette
Zwei kritische Schwachstellen in der Programmiersprache PHP (PHP2Shell, CVE-2026-109618 und -109619) haben gestern weltweit Behörden, Kliniken, Hochschulen und Unternehmen veranlasst, Websites vorsorglich vom Netz zu nehmen. Angreifer können ohne Anmeldung Schadcode auf Webservern ausführen (Remote Code Execution). Die Updates liegen seit gestern vor, doch viele Systeme dürften noch ungepatcht sein. PHP steckt hinter rund 70 Prozent aller Websites mit bekannter Konfiguration, aber auch in Routern, Speichersystemen und Sicherheitsprodukten, oft ohne dass Betreiber es wissen. Entdeckt wurden die Lücken mit Hilfe von KI. Der Vorfall zeigt aus Sicht von eco, wie verletzlich Software-Lieferketten sind und wie schnell sich die Bedrohungslage im KI-Zeitalter zuspitzt.
Norbert Pohlmann, Vorstand IT-Sicherheit im eco – Verband der Internetwirtschaft e.V.:
„PHP2Shell ist mehr als ein weiterer Patch-Day. Wenn ein Baustein, der hinter einem Großteil aller Websites steckt, eine kritische Lücke hat, wackelt ein Teil der digitalen Infrastruktur. KI hilft heute nicht nur Verteidigern beim Finden von Schwachstellen. Sie ermöglicht Angreifern auch, aus Updates in kürzester Zeit funktionierende Exploits zu bauen. Das Zeitfenster zwischen Patch und erstem Angriff schrumpft. Hersteller, Hoster und Betreiber brauchen deshalb belastbare Schwachstellenprozesse und eine koordinierte Offenlegung, die auf dieses Tempo ausgelegt ist. Außerdem gilt: Open-Source-Software wie PHP ist das Fundament des Internets. Wer wirtschaftlich davon profitiert, sollte ihre Sicherheit als Teil der eigenen Resilienz verstehen und nachhaltig unterstützen. Kritische Software braucht ausreichend Entwickler und verlässliche Ressourcen für Wartung und Sicherheitsprüfung, nicht nur Einzelprojekte.“
Olaf Pursche, Leiter der Kompetenzgruppe Sicherheit im eco:
„Für Betreiber zählt jetzt: Patches einspielen, und zwar überall, und prüfen, dass sie tatsächlich wirken. Viele Unternehmen wissen nicht, wo PHP bei ihnen im Hintergrund läuft, etwa in Verwaltungsoberflächen von Routern, Speichersystemen oder Sicherheitsprodukten. Wer IT auslagert, lagert nicht die Verantwortung aus: Unternehmen müssen mit Hostern und Dienstleistern verbindlich klären, wer Updates einspielt und deren Umsetzung bestätigt. Der Fall zeigt auch, warum klassische Prävention allein nicht mehr genügt. Wenn Angriffe mit KI immer schneller werden, ist Cyberresilienz entscheidend: Angriffe früh erkennen, Auswirkungen begrenzen und den Betrieb schnell wiederherstellen. Dazu gehört auch, nach dem Patch zu prüfen, ob Systeme bereits kompromittiert wurden.“
Was Betreiber jetzt tun sollten
- Bestand erfassen: PHP-Einsatz identifizieren, auch in Containern, ausgelagerten Anwendungen und Produkten mit eingebettetem PHP. Aus dem Internet erreichbare Systeme zuerst
- Updates einspielen: Korrigierte Versionen installieren (PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, bei Distributionen und Hostern gegebenenfalls als Backport) und prüfen, ob der laufende Dienst sie tatsächlich nutzt. Ein Update von CMS oder Plugins reicht nicht aus.
- Veraltete Versionen ablösen: Bei PHP 8.1 und älter einen verifizierten Patch des Anbieters nutzen oder aktualisieren.
- Risiken begrenzen: Systeme, die sich nicht rechtzeitig absichern lassen, nach Risikobewertung isolieren oder vorübergehend vom Netz nehmen. Eine Web Application Firewall (WAF) ersetzt das Update nicht.
- Kompromittierung prüfen: Logs auf Auffälligkeiten untersuchen, bei Verdacht Incident Response einleiten.
- Dienstleister einbinden: Hoster und IT-Dienstleister nach dem Patch-Status fragen und sich die Umsetzung bestätigen lassen.
Forderungen und Empfehlungen aus Sicht von eco
- Schneller reagieren: definierte Prozesse zum Priorisieren und Beheben kritischer Schwachstellen, Update-, Wiederherstellungs- und Incident-Response-Abläufe regelmäßig testen. Koordinierte Offenlegung (Coordinated Vulnerability Disclosure) muss KI-beschleunigte Exploits einplanen.
- Software-Transparenz: Komponenten und Abhängigkeiten kennen und dokumentieren (Software-Stückliste, SBOM).
- Klare Verantwortung in der IT-Lieferkette: Zuständigkeiten mit Hostern und Dienstleistern verbindlich festlegen.
- Open Source absichern: Wer davon wirtschaftlich profitiert, sollte die Sicherheit zentraler Komponenten in Beschaffung und Risikomanagement berücksichtigen und nachhaltig unterstützen.
- Lieferkette konsequent regeln: Der Cyber Resilience Act (CRA) verpflichtet Hersteller künftig zu Security-by-Design und zur Behebung von Schwachstellen über den gesamten Lebenszyklus.
