"Zero-Day-Exploits: Warum Unternehmen nicht mehr auf den nächsten Patch warten können"
Samstagnacht, 23 Uhr: Der Sicherheitsdienstleister eines Mittelständlers meldet, dass eine in der Produktion eingesetzte VPN-Appliance eine Schwachstelle aufweist, die bereits aktiv ausgenutzt wird – nicht irgendwo, sondern nachweislich auch bei vergleichbaren Unternehmen der Branche. Ein Patch existiert noch nicht. Das Projektteam, das seit Wochen an der Migration der Kernsysteme arbeitet, muss die Arbeit unterbrechen, den Netzwerkzugang isolieren und binnen Stunden eine Risikoeinschätzung liefern – ohne zu wissen, ob man bereits kompromittiert wurde. Szenarien wie dieses sind längst kein Einzelfall mehr, sondern ein Muster, das Projektverantwortliche zunehmend in ihre Planung einkalkulieren müssen.
Vom Ausnahmefall zur strukturellen Konstante
Ein Zero-Day-Exploit nutzt eine Schwachstelle aus, für die zum Zeitpunkt des Angriffs noch kein Patch existiert – der Hersteller hatte buchstäblich null Tage Zeit zur Reaktion. Über Jahre hinweg galten solche Angriffe als seltenes Werkzeug hochspezialisierter Akteure. Diese Einschätzung lässt sich heute nicht mehr halten. Nach Auswertungen von Googles Threat Intelligence Group wurden 2023 rund 100 aktiv ausgenutzte Zero-Days registriert – ein Rekordwert –, 2024 waren es 78, 2025 wieder 90. Die Zahl schwankt also, pendelt sich aber seit mehreren Jahren stabil in einer Bandbreite von 60 bis über 100 pro Jahr ein. Bemerkenswerter als die absolute Zahl ist die Verschiebung der Ziele: Browser, einst das bevorzugte Einfallstor, machen inzwischen weniger als zehn Prozent der Fälle aus – ein historisches Tief, auch dank verbesserter Sandbox-Architekturen. Stattdessen rücken Unternehmenssoftware und Betriebssysteme in den Vordergrund, mit einem historischen Höchstwert bei Enterprise-Technologien. Besonders betroffen sind Sicherheits- und Netzwerk-Appliances von Herstellern wie Cisco, Fortinet, Ivanti oder VMware – gerade weil solche Edge-Geräte häufig ohne die Überwachungsfunktionen klassischer Endpunktsicherheit laufen und damit blinde Flecken im Verteidigungssystem bilden.
Auch die Akteurslandschaft hat sich verschoben. Erstmals überholten kommerzielle Überwachungsanbieter – Firmen, die Spyware und Exploits gegen Bezahlung an staatliche wie private Kunden liefern – die klassischen staatlichen Spionagegruppen als treibende Kraft. Gleichzeitig haben sich chinanahe Angreifergruppen auf Edge-Geräte spezialisiert und ihre Zahl an genutzten Zero-Days binnen eines Jahres verdoppelt. Auch finanziell motivierte Cyberkriminelle, etwa Gruppen, die Schwachstellen in Unternehmenssoftware wie ERP-Systemen ausnutzen, bewegen sich nahe an Rekordwerten. Zero-Day-Exploits sind damit kein Nischenphänomen der Geheimdienste mehr, sondern ein Werkzeug, das über kommerzielle Märkte breiter verfügbar geworden ist.
Wenn Maschinen selbst nach Lücken suchen
Die vielleicht folgenreichste Entwicklung der jüngsten Zeit ist der Einsatz künstlicher Intelligenz bei der Schwachstellensuche selbst. Google bestätigte den ersten öffentlich dokumentierten Fall, in dem eine Angreifergruppe mithilfe eines KI-Modells eine bis dahin unbekannte Schwachstelle in einer verbreiteten Open-Source-Administrationssoftware fand und für einen gezielten Bypass der Zwei-Faktor-Authentifizierung nutzte. Bemerkenswert daran ist weniger der Einzelfall als die Art der gefundenen Lücke: ein semantisches Logikproblem in der Vertrauenslogik der Software – genau die Art von Fehler, an der klassische automatisierte Scanner regelmäßig scheitern, weil sie Muster statt Bedeutung erkennen. Reasoning-fähige Sprachmodelle sind darin nachweislich besser.
Diese Entwicklung wirkt in beide Richtungen. Auf der Angreiferseite lässt sich davon ausgehen, dass sich Aufklärung, Schwachstellensuche und Exploit-Entwicklung weiter automatisieren und beschleunigen – Analysten beobachten bereits, dass die Zeitspanne zwischen der Veröffentlichung einer Schwachstelle und ihrer massenhaften Ausnutzung durch mehrere Gruppen schrumpft. Auf der Verteidigerseite eröffnen agentenbasierte KI-Systeme umgekehrt die Möglichkeit, Patches proaktiver und schneller zu entwickeln und Angriffsflächen kontinuierlich zu überwachen. Für die kommenden Jahre ist deshalb kein linearer Trend zu erwarten, sondern ein Wettlauf, bei dem beide Seiten ihre Fähigkeiten gleichzeitig ausbauen.
Warum BANI die Lage besser beschreibt als VUKA
Für die Einordnung dieser Entwicklung eignet sich das BANI-Modell besser als das ältere VUKA-Modell, weil es nicht nur Unsicherheit und Komplexität beschreibt, sondern auch Zerbrechlichkeit und Nichtlinearität – zwei Eigenschaften, die Zero-Day-Risiken treffend charakterisieren. Brittle, zerbrechlich, sind viele der betroffenen Systeme deshalb, weil sie über Jahre gewachsene, hochgradig vernetzte Architekturen sind, die von außen robust wirken, im Ernstfall aber schlagartig und vollständig versagen können – ein einzelner ungepatchter Edge-Zugang kann ein gesamtes Netzwerk kompromittieren. Nonlinear zeigt sich die Wirkung, wenn eine einzelne Schwachstelle in einer weitverbreiteten Bibliothek oder Appliance nicht nur ein Unternehmen, sondern über Lieferketten hinweg Tausende nachgelagerter Kunden gleichzeitig betrifft – die Wirkung steht in keinem proportionalen Verhältnis zur Ursache. Incomprehensible, unbegreiflich, ist die Angriffsfläche moderner Softwarelandschaften schlicht deshalb, weil kein einzelnes Team mehr vollständig überblicken kann, welche Abhängigkeiten, Bibliotheken und Konfigurationen tatsächlich im Einsatz sind. Und anxious, die diffuse Grundangst, entsteht aus der Gewissheit, dass eine Kompromittierung nicht mehr eine Frage des Ob, sondern des Wann ist – bei gleichzeitiger Unmöglichkeit, sich vollständig zu schützen.
Was das für Organisationen, Teams und Projekte bedeutet
Für Organisationen bedeutet das einen Wechsel der Grundhaltung: von reiner Prävention hin zu Resilienz. Patch-Management lässt sich nicht mehr als periodische Aufgabe planen, sondern muss als kontinuierlicher Prozess mit klaren Eskalationswegen verankert sein, inklusive der Frage, wer im Ernstfall außerhalb der üblichen Geschäftszeiten entscheidungsbefugt ist. Sicherheitsarchitektur wird damit zunehmend zum Vorstandsthema statt zur reinen IT-Angelegenheit, und Business-Continuity-Planung gehört in jede grössere Digitalisierungsinitiative von Beginn an.
Für Teams heißt das vor allem: psychologische Sicherheit im Umgang mit eigenen Fehlern und verdächtigen Beobachtungen. Wer befürchten muss, für das frühe Melden einer möglichen Kompromittierung sanktioniert zu werden, meldet später – und später ist in diesem Kontext oft zu spät. Security-Verantwortung darf nicht bei einer isolierten Sicherheitsabteilung verbleiben, sondern gehört als Rolle – etwa als Security Champion – direkt in Entwicklungs- und Projektteams hinein, verbunden mit kontinuierlicher Weiterbildung, weil sich die Bedrohungslage schneller wandelt als jedes einmalige Schulungscurriculum.
Für Projekte schließlich bedeutet dies, Sicherheitsanforderungen nicht als nachgelagerten Prüfschritt, sondern von der Kickoff-Phase an im Projektauftrag, im Risikoregister und im Lieferantenmanagement zu verankern. Wer eine Software oder Appliance eines Drittanbieters einsetzt, übernimmt automatisch dessen Zero-Day-Risiko – Lieferkettenrisiken gehören deshalb explizit auf die Risikoliste, nicht nur die eigenen Systeme. Und jedes größere Projekt sollte über einen definierten Vorgehensplan für den Fall eines aktiven Sicherheitsvorfalls verfügen, inklusive der Frage, wer kurzfristig zusätzliche Kapazität übernehmen kann, wenn ein Krisenfall eintritt und reguläre Projektressourcen gebunden sind.
Ein typisches Beispiel
Ein mittelständisches Unternehmen befindet sich mitten in einem Projekt zur Modernisierung seiner IT-Infrastruktur, als eine genutzte Netzwerk-Appliance von einer aktiv ausgenutzten Zero-Day-Lücke betroffen ist. Weil im Projektauftrag von Beginn an ein Incident-Response-Plan mit klaren Verantwortlichkeiten hinterlegt war, kann das Team binnen Stunden reagieren: Zugänge werden isoliert, betroffene Systeme forensisch geprüft, Stakeholder informiert. Das eigentliche Projekt verzögert sich um wenige Tage – ohne diese Vorbereitung hätte derselbe Vorfall Wochen gekostet und das Vertrauen der Kunden nachhaltig beschädigt.
Auf den Punkt
Zero-Day-Exploits sind von einem seltenen Spezialwerkzeug zu einem strukturellen Merkmal der digitalen Risikolandschaft geworden, verstärkt durch kommerzielle Exploit-Märkte und zunehmend durch KI-gestützte Schwachstellensuche auf beiden Seiten. Das BANI-Modell macht deutlich, warum klassische Präventionslogik allein nicht mehr ausreicht: Zerbrechliche, nichtlineare und schwer durchschaubare Systeme verlangen nach Resilienz statt Kontrolle. Für Organisationen, Teams und Projekte bedeutet das, Sicherheit nicht als Add-on, sondern als durchgängigen Bestandteil von Governance, Teamkultur und Projektplanung zu verankern – bevor der nächste Zero-Day zuschlägt.
(Erstellt mit KI-Unterstützung, redaktionell geprüft)