Eine Woche, in der die IT-Welt brannte

Zehn kritische Sicherheitslücken, ein ausserplanmässiges Firewall-Update und ein Team, das über sich hinausgewachsen ist. Ein Blick hinter die Kulissen der Kalenderwoche 43

Zwischen dem 20. und dem 26. Oktober 2026 wurden innerhalb weniger Tage zehn kritische Sicherheitslücken bekannt. Dazu kam ein ausserplanmässiges Sicherheitsupdate von Fortinet. Betroffen waren Werkzeuge, auf denen viele Unternehmen täglich arbeiten: Webserver, Entwicklungsplattformen, Firewalls, Java und Linux. Für uns bei Leuchter bedeutete das mehrere Tage im Ausnahmezustand. Wir haben über 1000 Webseiten sowie Public IP’s und 100 verschiedene Kunden geprüft, über 100 Firewalls aktualisiert und gefährdete Dienste vorsorglich vom Netz genommen. Möglich war das nur, weil ein ganzes Team weit mehr gegeben hat als üblich.

Ich war als Techniker im Security Operations Center (SOC) mittendrin. In diesem Beitrag erzähle ich, was in dieser Woche geschah, wie wir reagiert haben und was Unternehmen daraus mitnehmen können.

Wie alles begann

Krisen kündigen sich selten mit einem einzigen, klaren Signal an. Die ersten Hinweise kamen aus verschiedenen Richtungen: Kollegen lasen von Auffälligkeiten in Newsfeeds, Hersteller informierten uns, Fachforen diskutierten erste Details. Innerhalb kurzer Zeit verdichteten sich diese Einzelteile zu einem Bild, und das SOC übernahm die Führung.

Die Koordination lief zunächst über das SOC und unseren SOC-Teamlead, danach über alle Teamleiter bis zu den einzelnen Beteiligten. Dank der Erfahrung aus den letzten Jahren war uns schnell klar, dass das kein gewöhnlicher Patch-Tag werden würde. Ab diesem Moment ging es um Zeit.

PHP2Shell: Wenn das Zeitfenster schrumpft

PHP ist eine Programmiersprache, auf der ein grosser Teil des Internets läuft. Websites, Intranets, Wikis, Webportale und viele Geräte mit Weboberfläche nutzen PHP im Hintergrund, oft ohne dass die Betreiber es wissen.

Am Dienstag, 20. Oktober, sickerten Details zu zwei kritischen Lücken in PHP an die Öffentlichkeit, noch bevor ein Patch verfügbar war. Sie erlauben es Angreifern, ohne Anmeldung aus der Ferne Code auf betroffenen Servern auszuführen. Kurz darauf war ein Exploit-Werkzeug öffentlich verfügbar, und laut späteren Berichten hatte es bereits vier Tage vor der Offenlegung erste Angriffsversuche gegeben. Das offizielle Update war für Mittwoch, 16:00 Uhr angekündigt. Auch das Bundesamt für Cybersicherheit (BACS) warnte eindringlich.

Die Herausforderung war klar: Wir mussten in wenigen Stunden herausfinden, wo bei unseren Kunden PHP läuft, ob diese Systeme aus dem Internet erreichbar sind und was bis zum Patch geschehen soll.

Bei den Kunden, deren Umgebungen unser SOC überwacht, haben wir gezielt nach PHP-Installationen, laufenden PHP-Prozessen und von aussen erreichbaren Diensten gesucht. Wo ein betroffenes System öffentlich erreichbar war und nicht sofort gepatcht werden konnte, haben wir es vorsorglich vom Netz genommen.

Eine Abschaltung ist nie eine leichte Entscheidung, denn sie unterbricht den Betrieb. In diesem Fall war das Risiko einer Kompromittierung aber deutlich höher als ein vorübergehender Unterbruch einzelner Dienste. Das PHP-Update erschien pünktlich, und auch die Hersteller betroffener Produkte zogen erstaunlich schnell nach. Alle relevanten Kundensysteme waren innerhalb von 24 Stunden gepatcht und wieder in Betrieb.

Auch unsere eigene Umgebung haben wir untersucht und die nötigen Massnahmen sofort umgesetzt.

Unsere SOC-Kunden haben wir aktiv und transparent informiert. Dazu gehörte auch eine klare Abgrenzung: Unsere Prüfung gilt für die Geräte, die wir überwachen. Systeme von Drittanbietern, etwa extern gehostete Plattformen oder Appliances, müssen beim jeweiligen Hersteller abgeklärt werden.

Node2Shell: Entwicklergeräte im Fokus

Am selben Tag veröffentlichte das Node.js-Projekt Sicherheitsupdates für zehn Schwachstellen. Die gravierendste betrifft den eingebauten Brotli-Decoder, eine Komponente zum Entpacken komprimierter Daten. Sicherheitsforscher zeigten, dass sich darüber ebenfalls Code ohne Anmeldung ausführen lässt.

Node.js läuft selten auf klassischen Servern unserer Kunden, aber sehr oft auf Entwicklergeräten. Die Installation allein macht ein Gerät zwar noch nicht angreifbar. Gängige Werkzeuge wie der eingebaute fetch()-Befehl, axios oder Express 5 entpacken solche Daten aber standardmässig. Wer im Alltag externe Daten abruft, und das tun Entwickler ständig, erfüllt die Voraussetzung schnell.

Unsere erste Einschätzung haben wir nach 24 Stunden nochmals geschärft, als neue Informationen zur Ausnutzbarkeit vorlagen, und die Frist für Updates entsprechend verkürzt. Entwicklergeräte haben naturgemäss mehr Freiheiten als normale Arbeitsplätze. Gerade deshalb brauchen sie besondere Aufmerksamkeit, und genau dort unterstützen wir.

eMudhra: Wenn Signaturen nicht mehr vertrauenswürdig sind

Bei der indischen Zertifizierungsstelle eMudhra liessen sich die privaten Schlüssel von acht Zwischenzertifikaten rekonstruieren. Mit solchen Zertifikaten wird unter anderem Software digital signiert. Eine Signatur soll belegen, dass ein Programm echt und unverändert ist. Ist der Schlüssel dahinter kompromittiert, können Angreifer Schadsoftware so signieren, dass sie vertrauenswürdig aussieht. Deshalb haben wir bei allen Kunden, deren Umgebungen unser SOC überwacht, nach ausgeführten Programmen gesucht, die mit einem dieser Zertifikate signiert waren. Das Ergebnis war sauber.

Fortinet: über 100 Firewalls, alle Teams an Bord

Am Donnerstag, 22. Oktober, folgte der nächste Paukenschlag. Fortinet veröffentlichte ausserplanmässig Updates für FortiOS, FortiManager, FortiAnalyzer, FortiMail und FortiAuthenticator. Die Lücken wurden laut Fortinet mit KI-gestützten Tests gefunden und können zur vollständigen Übernahme eines Systems führen. CVE-Nummern und technische Details will Fortinet erst am 10. November publizieren. Die Empfehlung des Herstellers war deutlich: sofort patchen und nicht auf das nächste Wartungsfenster warten, weil Angreifer Patches heute sehr schnell zurückentwickeln.

Ab hier war das Ganze kein reines SOC-Thema mehr. Netzwerk-Team, System Engineering, Key Account Management und viele weitere Kolleginnen und Kollegen waren beteiligt.

Nicht immer lief alles glatt. Einige Ansprechpersonen bei Kunden waren kurzfristig nicht erreichbar. In solchen Fällen haben wir das Vorgehen über das Key Account Management abgestimmt und die Kunden schriftlich informiert. Bei vielen Kunden war das Vertrauensverhältnis so gross, dass wir die Entscheidung selbst treffen konnten.

Das Ergebnis: Alle Firewalls wurden fristgerecht gepatcht, und die Updates liefen ohne grössere Probleme.

Und dann war da noch …

Parallel dazu liefen weitere Prüfungen. Lücken in GitLab, im Linux Kernel und in Java haben wir dort untersucht, wo sie für unsere Kunden relevant waren, und die nötigen Patches und Massnahmen umgesetzt. Nicht jede Lücke muss überall mit gleicher Tiefe angegangen werden. Entscheidend ist, die richtigen Systeme zuerst anzuschauen.

Warum CVSS 10 nicht automatisch Vorrang hat

Ein gutes Beispiel dafür lieferte ebenfalls diese Woche. Microsoft veröffentlichte vier kritische Schwachstellen in Cloud-Diensten wie Azure DevOps und Entra, drei davon mit der Höchstwertung CVSS 10.0. Auf dem Papier waren das die gefährlichsten Lücken der Woche. Microsoft hatte die betroffenen Dienste aber bereits serverseitig korrigiert, Kunden mussten nichts tun. Für uns blieb zu prüfen, ob und wie diese Dienste genutzt werden.

Ganz anders bei PHP: Mit einem CVSS-Wert von 9.2 lag die Lücke formal tiefer. Sie war aber öffentlich ausnutzbar, betraf unzählige selbst betriebene Systeme und verlangte sofortiges Handeln.

Der CVSS-Wert beschreibt, wie schwer eine Lücke im schlimmsten Fall wiegt. Wie gross das Risiko für ein bestimmtes Unternehmen ist, beantwortet er nicht.

Der Unterschied, den ein SOC macht

Eine Woche wie diese zeigt deutlich, was Sichtbarkeit wert ist. Bei unseren SOC-Kunden konnten wir tief prüfen: Logs auswerten, nach Angriffsspuren suchen, laufende Prozesse und erreichbare Dienste identifizieren und proaktiv kommunizieren.

Bei Kunden ohne SOC-Dienstleistung haben wir mit den verfügbaren Ressourcen und in der verfügbaren Zeit nach bestem Wissen und Gewissen geprüft und gehandelt. Ohne den Einblick in die Systeme bleibt aber vieles eine Abklärung von Fall zu Fall. Wer seine Umgebung nicht sieht, kann sie im Ernstfall auch nicht schnell schützen.

Was uns durch die Woche getragen hat

Technik allein hätte nicht gereicht. Es braucht klar definierte Rollen und Menschen, die den Überblick behalten, wenn ständig neue Meldungen eintreffen. Während die PHP-Massnahmen noch liefen, kamen laufend neue Themen dazu. Dass wir trotzdem den Überblick behielten, verdanken wir eingespielten Abläufen und internen Werkzeugen, aber vor allem den Menschen.

Viele Kolleginnen und Kollegen haben freiwillig eine Schippe draufgelegt. Sie haben weitergedacht, Aufgaben übernommen, ohne gefragt zu werden, und Überstunden sowie Zusatzeinsätze geleistet. Nach den ersten langen Tagen hätte die Motivation sinken können. Stattdessen stieg sie, weil alle im selben Boot sassen und gemeinsam so viel wie möglich erreichen wollten. Die Zusammenarbeit über Teams und Hierarchien hinweg hat einmal mehr gezeigt, was möglich ist, wenn die ganze IT-Welt brennt.

Bilanz

Alle betroffenen Firewalls sind aktualisiert. Die vorsorglich abgeschalteten Dienste waren innerhalb von 24 Stunden gepatcht und wieder online. Nach Auswertung der verfügbaren Logs und Informationen haben wir keine Hinweise darauf gefunden, dass eine der Lücken bei unseren Kunden ausgenutzt wurde.

Von unseren Kunden kamen viele Rückfragen und viele positive Rückmeldungen. Eine Reklamation erhielten wir nicht, auch nicht wegen der Abschaltungen. Das werten wir als Zeichen, dass transparente Kommunikation auch unangenehme Massnahmen verständlich macht.

Was Unternehmen jetzt mitnehmen sollten

1. Patches nicht aufschieben. Kritische Updates gehören nicht ins nächste Wartungsfenster, wenn der Hersteller zur Eile mahnt.
2. Wissen, was läuft. Viele Unternehmen wussten nicht, dass PHP in ihren Systemen steckt. Ein aktuelles Inventar spart im Ernstfall Stunden.
3. Notfälle vorab regeln. Erreichbare Ansprechpersonen und ein vereinbartes Vorgehen für Notfall-Patches oder Abschaltungen verhindern, dass es an administrativen Fragen scheitert.
4. Risiko statt nur CVSS bewerten. Entscheidend ist, ob ein System betroffen, erreichbar und ungepatcht ist.

Ausblick

Diese Woche war vermutlich kein Ausreisser. Fortinet hat seine Lücken mit KI-gestützten Tests gefunden, und gleichzeitig belegen mehrere Berichte, dass Angreifer KI-Agenten in realen Kampagnen einsetzen, teils gegen Tausende Cloud-Umgebungen gleichzeitig. Schwachstellen werden schneller gefunden und schneller ausgenutzt.

Darauf müssen wir vorbereitet sein: mit agilen Prozessen, mit Systemen, die uns die nötige Sicht geben, und vor allem mit kompetenten Menschen, die Durchhaltevermögen haben und auch im grössten Chaos einen ruhigen Kopf bewahren. In dieser Woche haben wir gesehen, dass wir genau das haben.