Kaum waren die Patches für die kritischen PHP-Lücken CVE-2026-109618 und CVE-2026-109619 veröffentlicht, hielt das BSI eine breite Ausnutzung binnen Stunden für wahrscheinlich.
KI verkürzt den Weg vom Patch zum Exploit. Unternehmen brauchen vorbereitete Abläufe statt Ad-hoc-Reaktion.
Ein Patch mit Ansage
Am 21. Oktober 2026 um 16 Uhr deutscher Zeit veröffentlichte das PHP-Team Patches für zwei kritische Schwachstellen in der PHP-Laufzeitumgebung. CVE-2026-109618 und CVE-2026-109619 sind nach CVSS 4.0 jeweils mit 9,2 von 10 bewertet. Angreifer können darüber aus der Ferne Code auf Webservern ausführen – ohne Anmeldung und ohne Zutun eines Nutzers. In Anlehnung an Log4Shell kursiert bereits der Name „PHP2Shell“.
Die Tragweite ergibt sich aus der Verbreitung. Laut BSI sind alle bekannten PHP-Versionen bis mindestens PHP 5 verwundbar, ebenso jede Installation, die Webanfragen verarbeitet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed. PHP steckt in WordPress, Drupal, TYPO3, Magento und Nextcloud, aber auch in den Weboberflächen von Firewalls, Load Balancern und NAS-Systemen. Hersteller wie F5, Citrix und Palo Alto Networks haben bereits eigene Advisories veröffentlicht.
Warum das Zeitfenster schrumpft und der Patch auch Angreifern hilft
Lange galt: Zwischen Patch und breitem Angriff liegen Tage, oft Wochen. Diese Annahme trägt nicht mehr. Ein Patch ist immer auch eine Wegbeschreibung, denn er zeigt, an welcher Stelle im Code etwas repariert wurde. Wer alte und neue Version vergleicht, kann die Schwachstelle rekonstruieren. Dieses Patch-Diffing war lange Handarbeit für Spezialisten. KI-gestützte Werkzeuge können jedoch bei der Codeanalyse und Exploit-Entwicklung unterstützen und damit erheblich beschleunigen.
Das BSI wird in seiner Warnung deutlich: Spätestens seit dem Aufkommen KI-gestützter Tools verfügten Akteure über die Mittel, Patches in kurzer Zeit zu analysieren und Exploits zu generieren. Eine breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Patches hielt die Behörde für wahrscheinlich. KI kann somit sowohl die Entdeckung von Schwachstellen als auch deren Ausnutzung forcieren.
Für Security-Teams heißt das: Der Wettlauf beginnt nicht mit dem ersten Exploit, sondern mit der Veröffentlichung des Patches.
Die eigentliche Hürde: Wissen, ob man betroffen ist
Schnelles Patchen scheitert selten am Update selbst, sondern an der Frage davor: Wo läuft PHP überhaupt? Die offensichtlichen Webserver sind schnell gefunden. Schwieriger sind Container-Images mit eingebettetem PHP, Appliances mit PHP-basierter Weboberfläche oder Anwendungen, die ein Dienstleister betreibt.
Hinzu kommen Tücken im Detail. Linux-Distributionen spielen Korrekturen oft als Backport ein, ohne die Versionsnummer zu ändern – ein Blick auf „php -v“ reicht dann nicht. Und ein Update des CMS schließt die Lücke nicht, solange die PHP-Laufzeitumgebung darunter ungepatcht bleibt. Zudem ist zu prüfen, ob die aktualisierte Version tatsächlich aktiv ist.
Besonders heikel sind Altsysteme: Alle Versionen vor PHP 8.2 haben ihr End-of-Life erreicht, für 8.2 endet der Support zum Jahresende.
Patchen allein reicht nicht
Ein Patch schützt vor künftigen Angriffen, nicht vor solchen, die schon stattgefunden haben. Das BSI berichtet von Ausnutzungsversuchen bereits vor Erscheinen der Patches. Zur Reaktion gehört deshalb immer die Prüfung auf Kompromittierung: Startet der Webserver ungewöhnliche Shells oder Download-Tools wie curl und wget? Gibt es neue oder veränderte PHP-Dateien, die auf Webshells hindeuten? Zeigen die Logs auffällige Upload-Anfragen, gefolgt von Speicherfehlern oder gehäuften HTTP-500-Antworten?
Zusätzlich sollten die zentral gesammelten Sicherheitsmeldungen und Protokolldaten auf bekannt gewordene Angriffsmuster geprüft werden. Dabei hilft ein SIEM-System (Security Information and Event Management): Es sammelt und verknüpft Sicherheitsereignisse und Protokolldaten aus verschiedenen IT-Systemen. So lassen sich bei der Prüfung auf Kompromittierung bekannte Angriffsmuster und verdächtige Zusammenhänge erkennen – etwa auffällige Webanfragen mit anschließendem Start ungewöhnlicher Prozesse. Gespeicherte Ereignisse lassen sich auch rückwirkend untersuchen.
Workarounds wie angepasste PHP-Einstellungen oder Regeln einer Web Application Firewall verkleinern die Angriffsfläche, schließen sie laut BSI aber nicht vollständig. Sie überbrücken die Zeit bis zum Patch. Wo das nicht reicht, empfiehlt das BSI, eine vorübergehende Trennung vom Internet zu erwägen.
Vorbereitung schlägt Reaktion
Wer erst bei der nächsten kritischen Meldung beginnt, Zuständigkeiten zu klären und Systeme zu suchen, verliert die entscheidenden Stunden. Vier Fähigkeiten machen den Unterschied.
- Ein aktuelles Inventar samt Software-Stücklisten (SBOM), das in Minuten statt Tagen zeigt, wo eine Komponente steckt.
- Ein eingeübter Prozess für Notfall-Patches mit klaren Befugnissen – bis zur Frage, wer ein System vom Netz nehmen darf.
- Detektions- und Forensikfähigkeiten, um nach dem Patchen belastbar sagen zu können, ob ein System kompromittiert wurde.
- Ein laufendes Schwachstellenmanagement, das neue Sicherheitslücken kontinuierlich erfasst, die Betroffenheit und Risiken bewertet sowie die Behebung bis zum Abschluss nachverfolgt.
NIS2 und der Cyber Resilience Act verstärken diesen Druck: Meldepflichten und Anforderungen an das Schwachstellenmanagement setzen voraus, dass Unternehmen ihre Betroffenheit schnell und nachvollziehbar bewerten können.
Checkliste: Kritische Schwachstelle veröffentlicht – was Unternehmen jetzt prüfen sollten
1. Betroffenheit klären: Wo ist die Komponente im Einsatz – auf Servern, in Containern, in Appliances, bei Dienstleistern?
2. Exposition bewerten: Welche betroffenen Systeme sind aus dem Internet erreichbar? Diese zuerst angehen.
3. Patchstand verifizieren: Version mit dem Hersteller- oder Distributions-Advisory abgleichen, Backports beachten, Container neu bauen.
4. Zeit überbrücken: Ist sofortiges Patchen nicht möglich, Workarounds und WAF-Regeln umsetzen oder die Trennung vom Netz erwägen.
5. Hersteller-Advisories prüfen: Firewalls, Router, Load Balancer und andere Geräte mit Weboberfläche einbeziehen.
6. Kompromittierung ausschließen: Prozesse, Dateien und Logs auf Auffälligkeiten prüfen – auch rückwirkend.
7. Altsysteme angehen: End-of-Life-Versionen identifizieren und die Migration planen.
8. Lehren ziehen: Wie lange hat die Bewertung gedauert? Was fehlte im Inventar? Den Prozess nachschärfen.
