Azuls Bericht zur KI-Schwachstellenlücke 2026: Unternehmen schließen Sicherheitslücken langsamer als KI-Angreifer sie ausnutzen können

Azuls Bericht zur KI-Schwachstellenlücke 2026 zeigt eine Diskrepanz zwischen der Geschwindigkeit, die Sicherheitsverantwortliche KI-gestützten Angreifern zutrauen, und der Zeit, die ihre Unternehmen benötigen, um Sicherheitskorrekturen einzuspielen. In einer Umfrage unter 300 US-amerikanischen Sicherheitsverantwortlichen gaben 69 % an, Angreifer könnten innerhalb von drei Tagen einen funktionsfähigen Exploit entwickeln. 44 % sagten dagegen, ihr Unternehmen benötige vier Tage oder länger, um eine kritische Schwachstelle in der Produktionsumgebung zu beheben.

Der bemerkenswerteste Befund des Berichts betrifft die Erfahrungen, die die Befragten mit solchen Verzögerungen verbinden: 85 % berichteten von einem Vorfall, einem vermuteten Vorfall oder einem Beinahevorfall, der auf langsame Sicherheitsupdates zurückzuführen sei. Diese Zahl beschreibt berichtete Erfahrungen, keine unabhängig bestätigte Einbruchsquote – und sie belegt nicht, dass KI diese Ereignisse verursacht hat.

Die von Azul in Auftrag gegebene und von Censuswide durchgeführte Studie konzentriert sich auf Unternehmen mit umfangreichen Java-Implementierungen. Ihre übergeordnete Aussage ist operativer Natur: Eine Schwachstelle zu erkennen, ist erst der Anfang. Eine Sicherheitskorrektur muss Tests bestehen, die betroffenen Systeme erreichen und die Gefährdung in einer Systemlandschaft beseitigen, die den Teams möglicherweise nicht vollständig bekannt ist.

Zwei Uhren, die nicht synchron laufen

Die Umfrage unterscheidet zwischen den Erwartungen der Sicherheitsverantwortlichen an Angreifer und den eigenen Möglichkeiten ihres Unternehmens, Sicherheitsupdates einzuspielen:

• 69 % glauben, dass KI-gestützte Angreifer innerhalb von höchstens drei Tagen einen Exploit entwickeln können. 22 % veranschlagen dafür weniger als 24 Stunden.
• 56 % geben an, einen kritischen Patch innerhalb von drei Tagen in der Produktionsumgebung ausrollen zu können: 13 % schaffen dies in weniger als 24 Stunden, 43 % innerhalb von ein bis drei Tagen.
• 44 % benötigen länger: 32 % brauchen vier bis sechs Tage, 12 % noch mehr Zeit.

Dabei handelt es sich um Verteilungen der Umfrageantworten und nicht um Messungen dazu, wie Angreifer bei denselben Schwachstellen mit bestimmten Unternehmen um die Wette arbeiten. Die Unterschiede geben Anlass zur Sorge um die Bereitschaft der Unternehmen, sollten aber nicht als präzises dreitägiges Gefährdungsfenster für jedes Unternehmen verstanden werden.

Auch bei einer Schwelle von einem Tag zeigt sich dasselbe Ungleichgewicht: 22 % erwarten, dass Angreifer so schnell vorgehen, während nur 13 % angeben, dass ihr Unternehmen innerhalb dieses Zeitraums eine Sicherheitskorrektur einspielen kann. Gleichzeitig räumen 59 % ein, dass sie sich durch KI-gestützte Angriffswerkzeuge stärker gefährdet sehen, ohne ihre Sicherheitsmaßnahmen angepasst zu haben.

Tests tragen maßgeblich zu den Verzögerungen bei

Bei 58 % der befragten Unternehmen verlängern Tests von Java-Laufzeitupdates den Patch-Zyklus um mindestens vier Tage. Darunter entfallen 36 % auf vier bis sechs Tage und 22 % auf eine Woche oder länger. Weitere 33 % berichten von ein bis drei Tagen, 9 % von weniger als 24 Stunden. Niemand gab an, auf Tests zu verzichten.

Änderungen an Laufzeitumgebungen können viele Anwendungen betreffen, daher erfüllen Tests einen praktischen Zweck: Wenn ein Sicherheitsupdate einen kritischen Dienst beeinträchtigt, entsteht ein weiteres betriebliches Problem. Dem Bericht zufolge trägt auch der Umfang der Updates zu diesem Aufwand bei, denn vierteljährliche OpenJDK-Komplettversionen können neben Schwachstellenbehebungen auch Änderungen enthalten, die nicht die Sicherheit betreffen.

Azul untersuchte unabhängig davon 26 vierteljährliche OpenJDK-Updates über einen Zeitraum von mehr als sechs Jahren und stufte sechs davon als Auslöser schwerwiegender Regressionen ein. Die Quote von 23 % ist die Bewertung der Releases durch den Anbieter und keine Schätzung aus einer Umfrage dazu, wie häufig die Anwendung eines einzelnen Kunden ausfallen wird.

Zu den am häufigsten genannten Hindernissen für schnellere Sicherheitsupdates zählen umfangreiche Tests (44 %), die Komplexität oder das Alter der betroffenen Systeme (40 %) und der begrenzte Überblick über bekannte Schwachstellen (36 %). Verzögerungen bei Patches der Anbieter nannten 25 %. Das Muster zeigt, dass ein großer Teil der Herausforderung bei der Behebung von Schwachstellen in den unternehmenseigenen Bereitstellungsprozessen liegt.

Vorfallsmeldungen und Lücken im Systembestand erfordern unterschiedliche Einordnungen

55 % berichten von einem bestätigten Vorfall, der auf langsame Sicherheitsupdates zurückzuführen sei, und 53 % von einem Beinahevorfall. Die Befragten konnten mehrere Antworten auswählen; die Angaben überschneiden sich daher und dürfen nicht addiert werden. Die übergeordnete Zahl von 85 % umfasst außerdem vermutete Vorfälle.

Die Umfrage belegt nicht, dass all diese Ereignisse Java-Schwachstellen betrafen. Die Teilnehmenden arbeiten zwar in Unternehmen mit umfangreicher Java-Nutzung, doch die Studie enthält sowohl Fragen zu Software-Updates allgemein als auch spezifische Fragen zu Java-Laufzeitumgebungen.

Eine weitere Schwierigkeit ist der Überblick über den Systembestand. Nur 19 % geben an, dass mindestens 90 % ihrer Java-Laufzeitumgebungen in der Produktionsumgebung den neuesten Sicherheits-Patch-Stand aufweisen. Das bedeutet, dass 81 % unter diesem Schwellenwert liegen – nicht, dass 81 % keine aktuellen Laufzeitumgebungen haben. Etwa jedes fünfte Unternehmen gibt an, dass höchstens die Hälfte seiner Systemlandschaft auf dem aktuellen Stand ist.

Unabhängig davon räumen 51 % ein, nur teilweise oder eingeschränkt den Überblick über kritische Java-Laufzeitumgebungen zu haben, darunter eingebettete, ältere und nicht verwaltete Instanzen. Eine anfällige Laufzeitumgebung in einer gebündelten Anwendung oder einem Container zu finden, kann schwieriger sein als eine zentral verwaltete Installation zu identifizieren. Ein Patch kann die Gefährdung auf einem System nicht beseitigen, das der Bereitstellungsprozess nie erreicht.

Was Azuls Technologie zur Diskussion beiträgt

Azuls Angebot für Sicherheitsupdates beschränkt ausgewählte Releases auf Sicherheitskorrekturen auf einer zuvor stabilisierten OpenJDK-Basis. Das Unternehmen stellt vierteljährliche, gezielte monatliche und außerplanmäßige Updates bereit. Damit soll der Umfang nicht zusammenhängender Änderungen verringert werden, die Unternehmen bei der Bereitstellung eines dringenden Fixes bewerten müssen.

Das ist ein enger begrenzter technischer Eingriff, als die Notwendigkeit einer Änderungskontrolle zu beseitigen. Eine Begrenzung der Codeänderungen kann den Umfang der Validierung verringern; anwendungsspezifische Prüfungen, die Verantwortung für die Bereitstellung und die Vorbereitung eines Rollbacks bleiben jedoch wichtig. Azul ist Sponsor des Berichts und verkauft Produkte, die auf die darin untersuchten Probleme abzielen.

Azuls Werkzeuge für Java-Bestandsaufnahme und Schwachstellenanalyse decken die andere Seite des Ablaufs ab: Sie ermitteln Laufzeitumgebungen, Versionen und Gefährdung, damit eine neu bekannt gewordene Schwachstelle den betroffenen Systemen zugeordnet werden kann. Der Bericht enthält keinen kontrollierten Vergleich, der belegt, in welchem Umfang sich die untersuchten Unternehmen durch den Einsatz dieser Produkte verbessern würden.

„Unsere Forschung zeigt, dass Sicherheitsverantwortliche die Bedrohung verstehen: Nicht das Bewusstsein ist die Lücke, sondern die Umsetzung“, sagte Scott Sellers, Mitgründer und CEO von Azul.

Aus der Absicht, Patches einzuspielen, einen messbaren Prozess machen

Für das kommende Jahr nennen 32 % schnellere und häufigere Patch-Installationen als ihre wichtigste Strategie zur Verringerung der Gefährdung; 26 % setzen dagegen auf eine bessere Bestandsaufnahme von Software und Laufzeitumgebungen. Weitere 17 % räumen Erkennung und Reaktion Vorrang vor schnelleren Patch-Installationen ein.

Die Forschung legt nahe, den gesamten Weg von der Bekanntgabe einer Schwachstelle bis zu ihrer Behebung nachzuverfolgen: Welche Systeme sind betroffen, wer ist dafür verantwortlich, welche Tests sind erforderlich und hat der Fix tatsächlich die Produktionsumgebung erreicht? Eine Frist ist nur dann sinnvoll, wenn Teams die vollständige Umsetzung in der relevanten IT-Landschaft überprüfen können.

Die US-Ergebnisse stammen aus einer Erhebung, die vom 3. bis 7. August 2026 unter Sicherheitsverantwortlichen in Unternehmen mit mindestens 1.000 Beschäftigten und erheblichem Java-/JVM-Einsatz in der Produktionsumgebung durchgeführt wurde. Es handelt sich um selbst gemeldete Antworten einer klar definierten Gruppe, nicht um eine Vollerhebung aller Unternehmen oder eine direkte Messung der Entwicklung von Exploits.

Der vollständige Bericht zur Lücke bei KI-Schwachstellen 2026 enthält ausführliche Informationen zu den Ergebnissen und zur Methodik. Die wichtigste Schlussfolgerung lautet: Die Geschwindigkeit beim Einspielen von Patches und die Transparenz über Laufzeitumgebungen müssen sich gemeinsam verbessern. Ein schneller Fix ist nur begrenzt hilfreich, wenn ein Unternehmen nicht alle betroffenen Installationen ermitteln oder bestätigen kann, dass das Update sie erreicht hat.