KI-gestützte Schwachstellensuche: Zero-Days am Fließband

Wenn KI-Modelle Sicherheitslücken in großer Zahl finden, schrumpft das Zeitfenster zwischen der Entdeckung einer Lücke und ihrem Ausnutzen, weil Angreifer und Verteidiger dieselben Werkzeuge haben. Wer Patches erst nach Wochen einspielt, ist zu langsam. Wer die Modelle selbst gegen die eigenen Systeme laufen lässt, findet die Lücken vor dem Angreifer.

Was sich geändert hat

KI-Modelle finden heute Fehler in Betriebssystemen und Browsern, die Menschen über Jahrzehnte übersehen haben. Das ist keine Ankündigung mehr, es ist belegt. Mozilla meldete im April 2026: Firefox 150 enthält Korrekturen für 271 Schwachstellen, die Mozilla bei einer ersten Prüfung mit einer frühen Version des KI-Modells Claude Mythos Preview gefunden hat. Firefox wird nach Mozillas eigener Darstellung seit Jahren von einem internen Red Team geprüft und mit Fuzzing (automatisch erzeugten Fehleingaben) getestet. Die Funde stammen also aus Code, der bereits intensiv untersucht worden war.

Der zweite Fall betrifft ein Betriebssystem. Das KI-Modell Claude Mythos Preview fand in OpenBSD einen nach Angaben von Anthropic 27 Jahre alten Fehler in der TCP-Verarbeitung (SACK), über den ein Angreifer jeden über TCP erreichbaren OpenBSD-Rechner zum Absturz bringen konnte; der Fehler ist behoben. Der Quellcode von OpenBSD ist offen, jeder konnte die Stelle in all den Jahren lesen.

Für ein Unternehmen folgt daraus zweierlei. Die Software, die es einsetzt, enthält Lücken, die bisher niemand kannte. Und diese Lücken werden jetzt schneller gefunden: Was ein Hersteller mit einem Modell aufspürt, findet früher oder später auch ein Angreifer mit einem vergleichbaren.

Die Debatte ist dreißig Jahre alt

Ob ein Werkzeug, das Lücken findet, zu gefährlich für die Öffentlichkeit ist, wurde schon einmal gestritten. Im Frühjahr 1995 erschien S.A.T.A.N. (Security Administrator Tool for Analyzing Networks), ein Programm, das Netzwerke automatisch nach bekannten Schwachstellen absuchte und zu jedem Fund erklärte, wie er sich beheben lässt. Die Autoren nannten es in ihrer Originaldokumentation selbst ein zweischneidiges Schwert: Es hilft Administratoren, Lücken zu schließen, und es zeigt Angreifern, wo sie suchen müssen.

Der Streit um diesen Dual Use (die doppelte Verwendbarkeit für Schutz und Angriff) war heftig, weil das Werkzeug Angriffe billiger und einfacher zu machen schien. Heute ist die Frage erledigt. Schwachstellenscanner wie Nessus gehören zum Handwerkszeug von IT-Abteilungen und Prüfern, und niemand hält ihren Einsatz für anrüchig.

Die Lehre aus damals gilt für KI-Modelle genauso: Im Vorteil ist, wer das Werkzeug früher und gründlicher gegen die eigenen Systeme einsetzt. Aufhalten lässt sich die Technik nicht mehr, die Modelle sind in der Welt.

Das Zeitfenster zwischen Entdeckung und Patch

Jede Lücke durchläuft fünf Stationen, und gefährlich ist die Strecke zwischen ihrer Entdeckung und dem Einspielen des Patches. Davor kennt niemand die Lücke, danach ist sie geschlossen. Dazwischen kann sie ausgenutzt werden, und wie lange dieses Fenster offen steht, entscheidet über das Risiko.

Eingebaut: Ein Programmierfehler landet im Code. Solange ihn niemand kennt, ist das Risiko gering.
Entdeckt: Kennt ihn nur ein Angreifer, lässt er sich als Zero-Day (eine Lücke, für die es noch keinen Patch gibt) unbemerkt ausnutzen. Findet ihn jemand, der den Hersteller informiert, bleibt der Kreis der Wissenden klein.
Veröffentlicht: Jetzt kennt ihn jeder, auch wer ihn ausnutzen will. Das Risiko steigt, gleich wer die Lücke gemeldet hat.
Patch verfügbar: Der Hersteller liefert die Korrektur. Geschützt ist damit noch niemand.
Patch eingespielt: Erst jetzt ist die Lücke im eigenen Haus geschlossen.

KI-Modelle machen die zweite Station häufiger und rücken sie näher an die erste. Auf die ersten vier Stationen hat ein Unternehmen, das Software von Herstellern einsetzt, keinen Einfluss. Es beeinflusst nur die fünfte: wie schnell der Patch eingespielt wird. Dort entscheidet sich, wie lange es selbst offen steht.

Was ein Unternehmen jetzt tut

Vier Hebel liegen in der Hand des Unternehmens: der Patch-Prozess, die Prüfung in der eigenen Entwicklung, eine Regel für eingehende Hinweise und die Fragen an Lieferanten.

Patch-Prozess beschleunigen

Wer nicht weiß, welche Software wo läuft, kann sie nicht patchen. Am Anfang steht deshalb ein Inventar: Server, Arbeitsplätze, Netzwerkgeräte, Anwendungen und die Bibliotheken darin. Jedes System bekommt eine verantwortliche Person, die die Sicherheitsmeldungen des Herstellers verfolgt und entscheidet. Standardsoftware wie Betriebssysteme, Browser und Office-Pakete spielt Updates automatisch ein; begründet werden muss die Ausnahme. Für alles andere gelten Fristen nach Kritikalität. Eine Lücke, die von außen erreichbar ist und bereits ausgenutzt wird, hat Vorrang vor allem anderen, eine interne mit geringer Wirkung kommt in den nächsten regulären Wartungslauf.

KI-Prüfung in die Entwicklung einbauen

Wer eigene Software entwickelt, auch Skripte, Schnittstellen und Workflows, lässt dieselben Modelle gegen den eigenen Code laufen, bevor er ausgeliefert wird. Aus DevOps wird DevSecOps: Die Sicherheitsprüfung ist ein fester Schritt in der Pipeline und kein Termin kurz vor dem Release. Welche Prüfschritte dorthin gehören und warum Code aus Assistenten eigene Aufmerksamkeit braucht, steht auf der Seite zu KI-generiertem Code. Wie Teams die Assistenten selbst einführen, beschreibt die Seite zu KI-Coding-Assistenten.

Responsible Disclosure regeln

Responsible Disclosure (verantwortungsvolle Offenlegung) heißt: Wer eine Lücke findet, meldet sie zuerst dem Hersteller und veröffentlicht sie erst, wenn ein Patch bereitsteht oder eine vereinbarte Frist abgelaufen ist. Üblich sind Fristen von ein bis drei Monaten. Die Frist schützt die Nutzer und setzt den Hersteller unter Druck, die Lücke tatsächlich zu schließen.

Für das eigene Unternehmen heißt das: Es braucht eine feste Meldeadresse für Sicherheitslücken und eine Person, die eingehende Hinweise prüft und dem Finder antwortet. Dazu kommt die Zusage, bis wann eine bestätigte Lücke geschlossen wird. Findet das eigene Team eine Lücke in fremder Software, meldet es sie auf demselben Weg an den Hersteller.

Lieferanten fragen

Was ein Unternehmen nicht selbst entwickelt, liegt beim Lieferanten, und dort gehört die Frage hin, wie er mit KI-gefundenen Lücken umgeht. Prüft er sein Produkt selbst mit KI-Modellen, und hat er eine Meldeadresse für Sicherheitsforscher? Ebenso wichtig ist, wie schnell er Patches liefert, wenn eine Lücke bekannt wird, und wie seine Kunden davon erfahren. Die Antworten gehören in die Auswahl neuer Software und in die Verträge bestehender. Wie Angriffe über zugelieferte Bausteine funktionieren, beschreibt die Seite zu Supply Chain (OWASP LLM03).

Was das für KI-Systeme selbst bedeutet

Dieselben Modelle, die Lücken in Browsern finden, prüfen auch LLM-Anwendungen, vom Chatbot bis zum Agenten mit Zugriff auf Werkzeuge. Gesucht wird dort nach anderen Fehlern. Lässt sich das System über eine Prompt Injection umlenken? Prüft es die Rechte, bevor es eine Aktion auslöst? Wird seine Ausgabe geprüft, bevor eine andere Anwendung sie übernimmt?

So arbeitet der KI-Sicherheitscheck: mit einer Sammlung von Testfällen, die man wiederholen kann. Ein Teil greift den System Prompt direkt an, ein anderer bringt Anweisungen über Dokumente, E-Mails oder Webseiten ins Spiel, die das System verarbeitet. Weil die Testfälle wiederholbar sind, lässt sich nach jeder Änderung an Modell, Datenquelle oder Werkzeug nachprüfen, ob eine geschlossene Lücke geschlossen bleibt.

Wie oft KI an Sicherheitsvorfällen beteiligt ist und was diese Vorfälle kosten, zeigt das Lagebild KI-Sicherheit mit geprüften Kennzahlen und ihren Quellen.

Fazit

KI-Modelle machen die Suche nach Lücken billig, für Hersteller wie für Angreifer. Das Zeitfenster zwischen Entdeckung und Ausnutzen wird kürzer, und ein Unternehmen verkürzt seinen Teil davon nur über den eigenen Patch-Prozess. Wer zusätzlich die eigene Software und die eigenen KI-Systeme mit denselben Modellen prüft, findet Lücken, bevor es ein anderer tut. Den Überblick über alle Angriffswege auf KI-Systeme gibt unsere Seite zur KI-Sicherheit.

Weiterführend

AI That’s Too Dangerous For You? What we learned from S.A.T.A.N, IBM Technology, 11.6.2026
2026 Cost of a Data Breach Report: AI Is Changing Cybersecurity, IBM Technology, 30.7.2026
KI-Sicherheit im Überblick: alle Angriffswege nach OWASP und der Sicherheitscheck

Häufige Fragen

Finden KI-Modelle auch Fehler in unserer eigenen Software?

Ja, und genau dafür lohnt sich ihr Einsatz. Ein Modell liest Quellcode, Skripte und Konfigurationen und meldet Stellen, an denen ein Angreifer ansetzen könnte, auch in Workflows und Schnittstellen, die Sie selbst gebaut haben. Die Funde brauchen eine Bewertung durch jemanden, der das System kennt: Nicht jede gemeldete Stelle ist ausnutzbar, und manche ernste Lücke entsteht erst im Zusammenspiel mehrerer Systeme. Geben Sie Ihren Code nur einem Modell, dem Sie ihn auch sonst anvertrauen würden, etwa einem lokal betriebenen.

Müssen wir jetzt schneller patchen?

Ja, vor allem bei allem, was aus dem Internet erreichbar ist: Firewall, VPN-Zugang, E-Mail-Server, Website und Fernwartung. Dort zählt jeder Tag, an dem eine bekannte Lücke offen bleibt. Der übliche Einwand, ein ungetestetes Update könne den Betrieb stören, lässt sich mit gestaffeltem Einspielen entkräften: zuerst auf wenigen Testgeräten, dann auf dem Rest. Wo ein Patch nicht sofort möglich ist, etwa bei einer Maschinensteuerung, hilft eine Übergangsmaßnahme, etwa den Zugriff von außen zu sperren oder das Gerät in ein eigenes Netzsegment zu legen.

Was ist Responsible Disclosure, und brauchen wir das als Mittelständler?

Ja, sobald Sie etwas betreiben, das von außen erreichbar ist: eine Website, einen Webshop, ein Kundenportal oder eine App. Findet ein Sicherheitsforscher dort eine Lücke, sucht er eine Adresse für die Meldung. Fehlt sie, landet der Hinweis im allgemeinen Postfach oder gar nicht bei Ihnen. Eingeführt ist dafür die Datei security.txt im Verzeichnis /.well-known/ der Website, beschrieben in RFC 9116. Dazu gehört eine interne Regel, wer Hinweise beantwortet, und die Zusage, dass Finder, die sich an die Absprache halten, keine rechtlichen Schritte befürchten müssen.

Nutzt we-make.ai KI-Modelle zur Schwachstellensuche?

Ja, im KI-Sicherheitscheck als Werkzeug neben den wiederholbaren Testfällen. Bewertung und Priorisierung bleiben beim Menschen: Ob ein Fund tatsächlich ausnutzbar ist und welche Maßnahme im konkreten Unternehmen zuerst kommt, entscheidet der Prüfer. Geprüft werden KI-Systeme, also Assistenten, Agenten und lokale Modelle, entlang ihres Datenflusses bis zu den Rechten ihrer Werkzeuge. Einen Penetrationstest für Netz und Server ersetzt der Check nicht, beide Prüfungen ergänzen sich.

Ist das Ende der Zero-Days in Sicht?

Nein, auch wenn Mozilla nach der Prüfung von Firefox zuversichtlich klingt: „The defects are finite, and we are entering a world where we can finally find them all.“ (Die Fehler sind begrenzt, und wir betreten eine Welt, in der wir sie endlich alle finden können.) Das gilt für einen Hersteller, der seinen eigenen Code systematisch durchprüft. Neuer Code bringt neue Fehler, und Angreifer arbeiten mit vergleichbaren Modellen. Für ein Unternehmen ändert sich vor allem das Tempo, und davon profitiert, wer Patches zügig einspielt.