Sunnyvale, Kalifornien, 10. November 2026 – Azul, der vertrauenswürdige Marktführer für Enterprise Java in der heutigen KI-first-Welt, hat heute The 2026 AI Vulnerability Gap Report veröffentlicht. Es handelt sich dabei um eine Umfrage unter 300 Sicherheitsverantwortlichen in den USA, deren Organisationen Java in erheblichem Umfang in der produktiven Anwendungslandschaft einsetzen. Censuswide hat die Befragung unabhängig durchgeführt. Der Report kommt zu dem Ergebnis, dass bereits 85 Prozent der Organisationen einen Vorfall oder Beinahe-Vorfall aufgrund zu langsamen Patchens erlebt haben – darunter 55 Prozent mit einem bestätigten Vorfall und 53 Prozent mit einem Beinahe-Vorfall. Gleichzeitig verkürzt KI die Zeit, die Angreifer brauchen, um neu offengelegte Schwachstellen auszunutzen.
Gleiche Abwehr, schnellere Angreifer
Die Ergebnisse erscheinen wenige Wochen nach dem vierteljährlichen OpenJDK-Update vom Oktober. Dabei wurden mit einem Rekordwert von 53 OpenJDK-Schwachstellen so viele Sicherheitslücken in einem einzelnen Update offengelegt wie seit weit über zehn Jahren nicht mehr. Gleichzeitig werden Schwachstellen schneller ausgenutzt, als Unternehmen sie patchen können. Nahezu alle befragten Verantwortlichen sagten, dass KI-gestützte Angriffswerkzeuge die Gefährdung ihrer Organisation in den vergangenen zwölf Monaten erhöht haben. Dennoch haben 59 Prozent ihre Sicherheitsstrategie nicht angepasst: 34 Prozent beschreiben einen moderaten Anstieg und überprüfen ihre Maßnahmen, 25 Prozent halten den Anstieg für gering und sehen darin keine Priorität. Gleichzeitig glauben 69 Prozent, dass KI-gestützte Angreifer innerhalb von drei Tagen oder weniger einen funktionierenden Exploit entwickeln können; 47 Prozent nennen einen bis drei Tage, 22 Prozent weniger als 24 Stunden. Der Bericht M-Trends 2026 von Mandiant geht noch weiter: Er schätzt, dass die mittlere Zeit bis zur Ausnutzung (Mean Time to Exploit) 2025 auf minus sieben Tage gesunken ist – Angriffe finden also häufig schon statt, bevor überhaupt ein Patch veröffentlicht wird.
Der Patch-Zyklus wurde für einen anderen Gegner konzipiert
Nur 13 Prozent der Sicherheitsverantwortlichen sagen, dass ihre Organisation einen Patch für eine kritische Schwachstelle in der gesamten Produktionsumgebung in weniger als 24 Stunden ausrollen kann. 43 Prozent brauchen dafür ein bis drei Tage, 32 Prozent vier bis sechs Tage und 12 Prozent länger. Mit anderen Worten: Der Report stellt eine Drei-Tage-Lücke fest. 69 Prozent der Verantwortlichen glauben, dass ein Angreifer innerhalb von drei Tagen einen funktionierenden Exploit entwickeln kann, aber nur 56 Prozent der Organisationen können in dieser Zeit einen kritischen Fix ausliefern. Dieselbe Lücke zeigt sich bei der 24-Stunden-Marke: 22 Prozent glauben, dass Angreifer bereits innerhalb dieses Zeitfensters zum Ziel kommen, aber nur 13 Prozent können so schnell ausrollen.
Ein wesentlicher Grund ist das Testing. Auf die Frage, wie viel Zeit Tests vor dem Deployment ihrem Patch-Zyklus bei Updates der Java-Runtime hinzufügen, nannten 36 Prozent vier bis sechs Tage. 33 Prozent gaben einen bis drei Tage an und 22 Prozent eine Woche oder mehr. Nur 9 Prozent gaben weniger als 24 Stunden an, und kein Befragter verzichtet auf Tests. Insgesamt verlängern Tests den Patch-Zyklus bei 58 Prozent der Organisationen um vier Tage oder mehr. Das ist länger, als ein Angreifer nach Ansicht der meisten Verantwortlichen für einen Exploit braucht: höchstens drei Tage.
Der Testaufwand entsteht, weil die meisten Java-Updates mehr als Sicherheitsfixes enthalten. Ein vollständiges vierteljährliches OpenJDK-Update kann neben den Sicherheitsfixes Hunderte Codeänderungen ohne Sicherheitsbezug umfassen. Laut einer Auswertung der OpenJDK-Releases der vergangenen gut sechs Jahre durch Azul verursachten 23 Prozent der vierteljährlichen Updates (6 von 26) eine schwerwiegende Regression. Unternehmen stehen damit vor der schwierigen Aufgabe, zwischen Sicherheit und Stabilität abzuwägen.
85 Prozent hatten bereits einen Vorfall oder Beinahe-Vorfall
Die Kosten langsamen Patchens sind längst nicht mehr hypothetisch. 55 Prozent der Sicherheitsverantwortlichen berichten von einem bestätigten Vorfall und 53 Prozent von einem Beinahe-Vorfall infolge zu langsamen Patchens; zusammengenommen sind es 85 Prozent (Mehrfachnennungen waren möglich). Der Report legt nahe, dass diese Zahl eher zu niedrig ist, denn ein Vorfall lässt sich nur auf ein ungepatchtes System zurückführen, von dessen Existenz die Organisation wusste. Die Ausnutzung einer bekannten, ungepatchten Schwachstelle war laut dem Data Breach Investigations Report 2026 von Verizon mit 31 Prozent der Sicherheitsverletzungen der häufigste initiale Angriffsvektor.
Die Java-Landschaft, die niemand auf dem Schirm hat
Java bildet das Fundament vieler geschäftskritischer Anwendungen in Unternehmen. Da Entwicklungsteams, Übernahmen und Cloud-Migrationen die Zahl der Runtimes vervielfacht haben, hat kaum eine Organisation einen vollständigen Überblick darüber, wo sich diese befinden. Java läuft zuverlässig, und weil es selten Probleme verursacht, wird ihm oft weniger Aufmerksamkeit geschenkt, als es verdient.
Auf die Frage, welcher Anteil ihrer produktiven Java-Runtimes auf dem neuesten verfügbaren Sicherheits-Patch-Stand ist, antworteten nur 19 Prozent der Verantwortlichen mit „nahezu alle“, also 90 Prozent oder mehr. Damit weisen 81 Prozent der Organisationen Lücken bei der Patch-Abdeckung auf, darunter 21 Prozent, die angeben, dass die Hälfte ihres Bestands oder weniger aktuell ist.
Die mangelnde Sichtbarkeit ist der zweite blinde Fleck. 49 Prozent geben zwar an, vollständigeSichtbarkeit über jede Instanz ihrer kritischen Java-Runtimes zu haben – einschließlich eingebetteter, veralteter (Legacy) und nicht verwalteter Instanzen. 51 Prozent räumen jedoch ein, nur teilweise oder eingeschränkt Sichtbarkeit zu haben, und vermuten, dass es Instanzen gibt, die sie nicht sehen können. Die Analyse von Azul legt nahe, dass selbst die Zahl von 49 Prozent wahrscheinlich zu optimistisch ist, denn fehlende Instanzen sind für die Tools, die sie melden sollten, unsichtbar.
Die Kompromittierung von acht Schlüsseln von eMudhra-Zwischenzertifizierungsstellen (Intermediate CAs) im Oktober zeigt, was dieser blinde Fleck kosten kann: Browser-Hersteller sperrten die Zertifikate, doch Java-Runtimes verwalten eigene Truststores und prüfen standardmäßig nicht, ob Zertifikate widerrufen wurden. Deshalb brauchte jede Runtime – auch solche, die in Anwendungen und Containern eingebettet sind – ein eigenes Update.
Die Absicht zu patchen ist keine Frist
Zwei Drittel der Organisationen (66 Prozent) haben keine verbindliche, zeitlich festgelegte Vorgabe für das Patchen nicht kritischer Schwachstellen. Im Einzelnen patchen 38 Prozent nach dem Prinzip „Best Effort“ und 33 Prozent schreiben ein definiertes Service-Level-Agreement (SLA) vor. 25 Prozent verfolgen einen risikobasierten Ansatz und patchen nur das, was als hoch priorisiert gilt, und 3 Prozent haben überhaupt keine formale Richtlinie. Das ist relevant, weil KI-Agenten zunehmend in der Lage sind, Schwachstellen systemübergreifend zu verketten: In einer Evaluierung von OpenAI im Juli 2026 kombinierten autonome Agenten, die mit reduzierten Schutzmechanismen liefen, Schwachstellen, um aus ihrer Test-Sandbox auszubrechen und sich unbefugten Zugriff auf Systeme von Hugging Face zu verschaffen.
Auf die Frage nach den größten Hürden für schnelles Patchen nannten die Sicherheitsverantwortlichen vor allem drei interne Einschränkungen: aufwendige Tests vor dem Deployment (44 Prozent), die Komplexität oder das Alter der betroffenen Systeme (40 Prozent) und eingeschränkte Sichtbarkeit bekannter Schwachstellen (36 Prozent). Verzögerungen bei der Bereitstellung von Patches durch die Hersteller gehörten mit 25 Prozent zu den am seltensten genannten Hürden – zugleich ist dies die einzige Hürde auf der Liste, die außerhalb der Kontrolle des Unternehmens liegt.
Worauf die Verantwortlichen setzen
Als wichtigste Strategie zur Verringerung der Gefährdung nennen 32 Prozent der Verantwortlichen für die nächsten zwölf Monate schnelleres und häufigeres Patchen, 26 Prozent bessere Sichtbarkeit und ein besseres Inventar von Software und Runtimes. 17 Prozent wollen statt in schnelleres Patchen lieber in Erkennung und Reaktion (Detection and Response) investieren. Zusammen machen schnelleres Patchen und bessere Sichtbarkeit 58 Prozent der primären Strategien aus. Sie spiegeln die beiden Probleme wider, die der Report von Anfang bis Ende nachzeichnet: Man kann nur patchen, was man gefunden hat, und das Finden nützt nichts, wenn die Behebung länger dauert als die Ausnutzung. Jeder Tag zwischen der Verfügbarkeit eines Fixes und seinem Einsatz in der Produktion ist ein Tag, an dem die Organisation aufgrund der eigenen Tests, Fristen und des eigenen Inventars gefährdet bleibt.
„Agentische KI hat den Spielraum zunichtegemacht, auf den Verteidiger angewiesen sind, und die meisten Unternehmen betreiben noch immer Patch-Prozesse, die für einen sehr viel langsameren Gegner konzipiert wurden“, sagt Scott Sellers, Co-Founder und CEO von Azul. „Unsere Studie zeigt: Sicherheitsverantwortliche verstehen die Bedrohung. Nicht das Bewusstsein ist die Lücke, sondern die Umsetzung. Niemand kann das Zero-Day-Risiko beseitigen, aber jede Organisation entscheidet selbst, wie lange sie gefährdet bleibt – nämlich dadurch, wie viel ihrer Java-Landschaft sie sehen kann und wie schnell ein Fix sie durchlaufen kann. Die Security-only, Stability-first™-Updates von Azul enthalten ausschließlich Sicherheitspatches, ohne dass weitere Änderungen mitgeliefert werden, die etwas beschädigen könnten. So können Unternehmen schnell handeln und das Zeitfenster für Angriffe schließen, bevor ihnen ein Angreifer zuvorkommt.“
Um die vollständigen Ergebnisse zu lesen und Ihren eigenen Patch-Zyklus mit diesen zu vergleichen, laden Sie The 2026 AI Vulnerability Gap Report herunter. Weitere Informationen zu den Security-only, Stability-first™-Updates von Azul sind hier verlinkt.
Über den Report
Die Studie wurde von Azul in Auftrag gegeben und von Censuswide unabhängig unter 300 Sicherheitsverantwortlichen in den USA durchgeführt, darunter CISOs, Vice Presidents und Directors für Informationssicherheit, Heads of Security, Sicherheitsarchitekten sowie Verantwortliche für SecOps, DevSecOps und AppSec. Sie arbeiten in Organisationen mit 1.000 oder mehr Beschäftigten, in denen Java und auf der Java Virtual Machine (JVM) basierende Runtimes einen erheblichen Teil der produktiven Anwendungslandschaft ausmachen. Alle Befragten tragen unmittelbare Verantwortung für die Cybersicherheitsstrategie, das Schwachstellenmanagement oder die Patch-Richtlinien, oder haben erheblichen Einfluss darauf. Die Befragung fand vom 3. bis 7. August 2026 statt. Censuswide hält den Verhaltenskodex der Market Research Society (MRS) und die Grundsätze von ESOMAR ein.
Häufig gestellte Fragen
Wie sollten Sicherheitsteams auf KI-Modelle reagieren, die Java mit Maschinengeschwindigkeit ausnutzen können?
Sicherheitsteams sollten ihre Patch-Fristen verkürzen, ein aktuelles Inventar aller Java-Runtimes und Java-Komponenten führen und zuerst bereits ausgenutzte, bekannte Schwachstellen beheben sowie mit dem Internet verbundene Systeme priorisieren. Denn KI verkürzt die Zeit zwischen Offenlegung und Ausnutzung. Die Geschwindigkeit, mit der Hersteller Patches bereitstellen, ist dabei genauso wichtig wie der interne Prozess. Azul liefert Security-only, Stability-first™-Updates für Java 8, 11, 17, 21 und 25 sowie für ältere Versionen wie Java 6 und 7.
Wie schnell sollte eine Java-Runtime-Distribution eine neu offengelegte CVE patchen?
Eine Java-Runtime-Distribution sollte einen Fix für eine neu offengelegte kritische Schwachstelle, die als CVE-Eintrag (Common Vulnerabilities and Exposures) erfasst wird, noch am Tag der Offenlegung bereitstellen, denn Angreifer agieren inzwischen innerhalb von Tagen oder sogar Stunden. Laut Azul erscheinen Community-OpenJDK-Builds in der Regel Tage bis Wochen später. Azul hat seine Security-only, Stability-first™-Updates vom Oktober 2026 am selben Tag veröffentlicht, an dem OpenJDK 53 Schwachstellen offengelegt hat – so viele wie seit weit über zehn Jahren nicht mehr in einem einzelnen Update.
Welcher Rhythmus ist für das Java-Patching im Unternehmen der richtige?
Die meisten Unternehmen sollten Java regelmäßig im Einklang mit dem OpenJDK-Zyklus vierteljährlich patchen. Für kritische Schwachstellen sollten sie zusätzlich monatliche Updates einspielen und in der Lage sein, außerplanmäßige Fixes auszurollen, wenn eine Schwachstelle aktiv ausgenutzt wird. Ein fester Kalender allein reicht nicht mehr aus, da KI die Zeit bis zur Ausnutzung verkürzt. Azul liefert seine Security-only, Stability-first™-Updates vierteljährlich, monatlich und außerplanmäßig für Java 8, 11, 17, 21 und 25 sowie für ältere Versionen wie Java 6 und 7.
Wie patchen wir Java schnell und halten dabei das Produktionsrisiko gering?
Unternehmen können das Produktionsrisiko und den Testaufwand erheblich senken, indem sie Updates einspielen, die ausschließlich Sicherheitsfixes enthalten, denn sachfremde Änderungen sind häufig Ursache von Regressionen und erfordern deutlich mehr Tests. Vollständige vierteljährliche OpenJDK-Updates können Hunderte Codeänderungen ohne Sicherheitsbezug enthalten. Die Security-only, Stability-first™-Updates von Azul enthalten ausschließlich Sicherheitsfixes und bauen auf dem vollständigen OpenJDK-Release des Vorquartals auf, das in der Java-Community bereits breit und stabil im Einsatz ist.
Woran erkennen wir, welche Java-Runtimes von einer neu offengelegten Schwachstelle betroffen sind?
Unternehmen können gefährdete Java-Runtimes identifizieren, indem sie ein automatisiertes Inventar aller Runtimes aufbauen – einschließlich eingebetteter, containerisierter und nicht verwalteter Instanzen, die Asset-Management-Tools oft übersehen. Version und Patch-Stand werden darin mit bekannten Schwachstellen abgeglichen. Tabellenkalkulationen und manuell gepflegte Configuration-Management-Datenbanken (CMDBs) können damit kaum Schritt halten. Das JVM Vulnerability Risk Assessment von Azul bildet die Gefährdung durch Java Virtual Machines (JVMs) im gesamten Unternehmen ab. Es zeigt, welche Runtimes auf End-of-Life-Versionen laufen oder bekannte ausgenutzte Schwachstellen aufweisen, und liefert eine priorisierte Roadmap zur Behebung. Die Funktion JVM Inventory (JVMI) in der Azul Intelligence Cloud ergänzt dies um kontinuierliche Erkennung (Discovery): Wird eine neue Schwachstelle offengelegt, sehen Teams sofort, welche Runtimes betroffen sind, statt eine manuelle Suche zu starten.
Über Azul
Azul ist der vertrauenswürdige Marktführer im Bereich Enterprise Java für die heutige KI-first-Welt. Seine Open-Source-basierte Java-Plattform ermöglicht es Unternehmen, den gesamten Java-Lebenszyklus zu optimieren, um die Leistung zu beschleunigen, die Sicherheit zu erhöhen, Lizenz- und Cloud-Kosten zu senken und die Produktivität der Entwickler zu steigern. Azul unterstützt geschäftskritische Systeme für 37 Prozent der Fortune-100-Unternehmen, 50 Prozent der zehn wertvollsten Marken der Welt laut Forbes und die zehn weltweit führenden Finanzhandelsunternehmen. Weitere Informationen finden Sie unter azul.com und folgen Sie @azulsystems.
# # #
Pressekontakt:
PER Connect
Daniela Fichtl / Nicole Stadtmüller
Hofmannstraße 54
81379 München
Telefon: + 49 89 17959 18-0
E-Mail: [email protected]