Die Flut an Sicherheitslücken 2026: Was KI verändert hat

Lange war das Finden von Sicherheitslücken der Engpass. 2026 übernehmen KI-Modelle einen wachsenden Teil dieser Arbeit, und sie finden Fehler schneller, als Teams sie schließen können. Die Threat Intelligence Group von Google hat für Januar 2026 insgesamt 5.045 veröffentlichte Schwachstellen gezählt, für August 10.740. Das ist mehr als das Doppelte in sieben Monaten.
Für die Geschäftsleitung hat das eine handfeste Folge. Mehr Hinweise auf Lücken landen bei denselben Menschen, die heute die Updates einspielen. Zu klären ist deshalb, welche Lücken zuerst geschlossen werden und wer über die übrigen entscheidet.
Was KI am Finden von Lücken verändert hat
Im April hat Anthropic Project Glasswing vorgestellt. Das Modell Claude Mythos Preview hat nach Angaben des Unternehmens Tausende schwerwiegende Schwachstellen gefunden, darunter in jedem großen Betriebssystem und jedem großen Webbrowser. Eine davon steckte seit 27 Jahren in OpenBSD, einem Betriebssystem, das als besonders gehärtet gilt. Allgemein verfügbar will Anthropic das Modell nicht machen. Warum solche Funde das alte Sicherheitsmodell von Unternehmen brechen, haben wir im April in KI findet Schwachstellen: Warum Resilienz jetzt Pflicht ist beschrieben.
FIRST, der internationale Verbund der Incident-Response- und Sicherheitsteams, nennt KI als einen wesentlichen Treiber der Flut. Bei Mozilla stieg die Zahl der CVEs, also der öffentlich registrierten Schwachstellen, im ersten Quartal um 164 Prozent. FIRST führt das direkt auf KI-Werkzeuge zurück, die den Code der Firefox-Engine durchsuchen.
Im Juni hat FIRST seine Prognose für das ganze Jahr von 59.427 auf rund 66.000 Schwachstellen angehoben. Bis dahin lagen die Meldungen 46,3 Prozent über dem Stand, den FIRST im Februar für diesen Zeitraum vorhergesagt hatte. Nach FIRST nähert sich die Jahreszahl damit zum ersten Mal der Marke von 70.000.
KI ist nicht die einzige Ursache. FIRST nennt daneben strukturelle Gründe, die die Zahlen aufblähen. Wie viele Lücken mit KI gefunden wurden, lässt sich aus öffentlichen Daten nicht ablesen, weil CVE-Einträge dafür keine einheitliche Kennzeichnung tragen. Das hält auch Google fest.
Ein Beispiel: die Firewall mit wenigen gemeldeten Lücken
Wie das im Betrieb ankommt, zeigt OPNsense. Das ist eine quelloffene Firewall, die zwischen dem eigenen Netz und dem Internet steht und regelt, welcher Datenverkehr hinein- und hinausdarf. Über Jahre wurden dort wenige Lücken öffentlich registriert. Die US-Schwachstellendatenbank NVD führt zu OPNsense für die acht Jahre von 2018 bis 2025 zusammen 23 Einträge. In sieben dieser Jahre waren es höchstens drei, nur 2023 waren es 15.
Bis zum 25. Oktober 2026 sind 30 Einträge dazugekommen. Zehn davon wurden für eine Fassung aus dem Jahr 2019 nachgetragen. Das Projekt selbst hat von März bis Ende September in seinem Repository auf GitHub 31 Sicherheitshinweise veröffentlicht, fünf davon als kritisch eingestuft. Am 1. Juli kamen neun an einem einzigen Tag.
Unter den neun war eine kritische Lücke, über die sich Code mit Root-Rechten ausführen ließ, also mit vollem Zugriff auf die Firewall. heise nennt dafür einen CVSS-Wert von 9,9. Auf dieser Skala für die Schwere einer Lücke ist 10 der Höchstwert. Ob KI beim Finden half, sagen die meisten Hinweise nicht. Einer der 31 nennt ausdrücklich KI-Unterstützung beim Lesen des Codes und beim Schreiben des Berichts.
Für den Betrieb ist die Ursache aus unserer Sicht zweitrangig. Wer OPNsense einsetzt, hatte am 1. Juli neun Hinweise für das Gerät zu prüfen, an dem das eigene Netz ans Internet grenzt. Mit jedem weiteren Produkt im Haus wird die Liste länger.
Ausgenutzt wird ein kleiner Anteil, und die Zahl steigt
Die Zahl, nach der sich die Reihenfolge richten sollte, steht in der Auswertung von Google. Nur 0,23 Prozent aller 2026 veröffentlichten Schwachstellen wurden überhaupt bei einer aktiven Ausnutzung beobachtet, etwa eine von 431. Allein Einträge zum Linux-Kernel ergaben von Januar bis August rund 5.000 CVEs. Dass einer davon als Zero-Day ausgenutzt wurde, also bevor ein Update bereitstand, hat Google nicht beobachtet.
Trotzdem steigt die absolute Zahl. Google zählte von Januar bis August 141 ausgenutzte Lücken, mehr als im ganzen Jahr 2025 mit 127. Seit Mai wächst die Ausnutzung nach Google fast genau so schnell wie die Zahl der Veröffentlichungen.
Die Menge der Lücken taugt deshalb nicht als Maßstab für die Arbeit im Unternehmen. Es zählt, welche davon ausgenutzt werden und ob sie in den eigenen Systemen stecken.
Der Engpass liegt beim Patchen
FIRST fasst die Lage so zusammen: Wenn KI weit mehr Fehler findet als menschliche Analysten, ist das Finden nicht mehr der Engpass. Knapp wird die menschliche Fähigkeit, zu prüfen, abzustimmen und zu patchen. Unternehmen sollen sich nach FIRST auf eine verdoppelte Patchlast einstellen.
Ob die heutige Besetzung der IT eine doppelte Last trägt, ist eine Frage an die Geschäftsleitung. In einem Haus mit kleiner IT kommt nicht hinterher, wer jeden Hinweis gleich behandelt. Warum der Engpass vom Finden zum Beheben wandert, haben wir im September in Warum KI-Angriffe das goldene Zeitalter der Cybersicherheit eröffnen ausführlicher beschrieben.
Was die Geschäftsleitung festlegen sollte
Aus unserer Sicht ordnen vier Festlegungen die wachsende Last. Sie gelten in dieser Reihenfolge.
Ein aktuelles Verzeichnis der Systeme
Ein Hinweis zählt nur, wenn das betroffene Produkt in der betroffenen Fassung bei Ihnen läuft. Ohne aktuelles Verzeichnis der Systeme und Versionen lässt sich das nicht beantworten, und jeder Hinweis wird zur Einzelrecherche. Die Zeit für dieses Verzeichnis sollte die Geschäftsleitung ausdrücklich freigeben.
Ausgenutzte Lücken zuerst
Die US-Behörde CISA führt den Katalog Known Exploited Vulnerabilities, nach eigener Darstellung die maßgebliche Quelle für Lücken, die nachweislich ausgenutzt wurden. CISA empfiehlt, ihn in die eigene Priorisierung einfließen zu lassen. Steht eine Lücke aus Ihrem Bestand dort, ist sie zuerst dran. Für die übrigen Lücken schätzt das Exploit Prediction Scoring System von FIRST, kurz EPSS, wie wahrscheinlich eine CVE in den nächsten 30 Tagen ausgenutzt wird. Der CVSS-Basiswert allein ordnet die Liste nicht. Er beschreibt die Schwere einer Lücke nach ihren festen Eigenschaften und sagt nichts darüber, ob jemand sie ausnutzt.
Was am Internet hängt, vor dem Rest
Firewalls und VPN-Zugänge stehen zwischen dem eigenen Netz und dem Internet. Ist die betroffene Funktion von außen erreichbar, wiegt eine kritische Lücke dort für uns schwerer als derselbe Wert auf einem Rechner im internen Netz. Ein Angreifer erreicht sie dann ohne weiteren Zwischenschritt.
Wer über einen Aufschub entscheidet
Nicht jede Lücke lässt sich sofort schließen. Manche Updates brauchen einen Test, andere ein Wartungsfenster. Wird eine Lücke bewusst später geschlossen, sollte feststehen, wer das entschieden hat, bis wann und mit welcher Begründung. Ab welcher Schwere die Geschäftsleitung selbst entscheidet, sollte sie vorab festlegen. Dann lässt sich im Audit zeigen, dass das Risiko bewusst getragen wurde.
Wo KI auf der Seite der Verteidigung hilft
Dieselbe Technik, die zur Flut beiträgt, kann aus unserer Sicht beim Abarbeiten helfen. Ein Modell liest den Sicherheitshinweis, gleicht ihn mit dem Verzeichnis der eigenen Systeme ab und schlägt vor, ob er zutrifft und wie dringend er ist. Die Entscheidung, was zuerst geschlossen wird und welches Risiko das Haus trägt, bleibt beim Menschen.
Wer weiter gehen will, lässt die eigene Software von einer KI angreifen, bevor es ein Fremder tut. Wie wir das jede Nacht mit einer Kopie unserer Plattform machen, steht in Wir lassen uns jede Nacht hacken.
Nach allem, was die Zahlen zeigen, wird die Last in diesem Jahr nicht kleiner. Wer weiß, was bei ihm läuft, und die ausgenutzten Lücken zuerst schließt, hat eine Liste, die sich abarbeiten lässt.
Quellen: Google Threat Intelligence Group, 30. September 2026; FIRST, Mid-Year Vulnerability Forecast, 15. Juni 2026 und Blogbeitrag dazu; Anthropic, Project Glasswing, 7. April 2026; OPNsense, Sicherheitshinweise auf GitHub; NVD, Stichwortsuche „opnsense“; heise, 6. Juli 2026; CISA, Known Exploited Vulnerabilities Catalog; FIRST, EPSS; FIRST, CVSS 4.0; OPNsense, Dokumentation. Abgerufen am 24. und 25. Oktober 2026.
