Über Automatisierung hinaus: Warum die Zunahme KI-gestützter Sicherheitsschwachstellen menschliche IT-Expertise erfordert

Zukünftige Historiker werden sich an das Frühjahr 2026 als den Beginn der KI-gestützten Meldung von Sicherheitsschwachstellen erinnern. Am 7. April kündigte Anthropic eine Preview von Claude Mythos an, einem KI-Modell, das ausgewählten Unternehmen im Rahmen von Project Glasswing zur Verfügung gestellt wird. Die Initiative gab an, Tausende von Schwachstellen mit hohem und kritischem Schweregrad im gesamten Open Source-Ökosystem entdeckt zu haben. Drei Wochen später meldete die Xint-Initiative eine lokale Schwachstelle im Linux-Kernel zur Ausweitung von Berechtigungen mit dem Namen Copy Fail. Ein paar Tage später erfuhr die Welt von einer weiteren Schwachstelle namens Dirty Frag und danach von einer weiteren namens Fragnesia. Weitere werden folgen.

Project Glasswing, Copy Fail und Dirty Frag haben Probleme bei der verantwortungsvollen Offenlegung gemeinsam. Project Glasswing verbreitete trotz der großen Ankündigung nur wenige verwertbare Informationen. Die Forschenden hinter Copy Fail gaben ihre Ergebnisse an die Entwicklungsteams von kernel.org weiter, nicht jedoch an Systemanbieter. Jemand hat vorzeitig Details zu Dirty Frag veröffentlicht und den Forscher Hyunwoo Kim gezwungen, Details in einem öffentlichen E-Mail-Thread offenzulegen, bevor jemand Patches entwickeln konnte.

In diesem Blog-Beitrag wird die Reaktion von Red Hat auf Copy Fail untersucht und erörtert, wie unser Technical Account Management Service für Produktsicherheit Unternehmen beim Verwalten ihrer Sicherheitslage in dieser neuen Ära der schnellen und kontinuierlichen KI-generierten Offenlegungen unterstützen kann.

Geschichte und Hintergrund von Red Hat Product Security

Das Team von Red Hat Product Security ist seit 2001 führend in der IT-Sicherheits-Community und hat sich kontinuierlich mit der Bedrohungslandschaft weiterentwickelt. 

CVE.org verwaltet die Meldung von Softwareschwachstellen in der gesamten IT-Branche mithilfe des Konzepts Common Vulnerabilities and Exposures (CVE). Eine CVE Numbering Authority (CNA) ist eine Mitgliedsorganisation, die CVEs veröffentlicht. CVE.org hat mehr als 500 CNA-Mitglieder aus der IT-Branche. Eine CNA-LR ist eine CVE Numbering Authority of Last Resort. Mitgliedsorganisationen verlassen sich auf sie, um Streitigkeiten über CVEs beizulegen. Root-Organisationen zeigen anderen CNAs, wie sie CVEs einreichen.

Heute ist Red Hat das einzige Privatunternehmen weltweit, das die CNA-LR-Rolle innehat, und eines von nur 2 Privatunternehmen mit der Root-Rolle. Dies bedeutet, dass Red Hat eine wohlverdiente Position des Respekts, der Verantwortung und des Vertrauens in der gesamten Branche einnimmt. Wir sind oft diejenigen in der Mitte und übersetzen einen undurchschaubaren Kernel-Commit in etwas Umsetzbares, während der Rest der Welt Schlagzeilen nachjagt.

Mit der Zunahme von KI-gestützten Meldungen von Sicherheitslücken entwickelt sich die Bedrohungslandschaft nicht nur weiter, sondern beschleunigt sich. Mozilla arbeitete vor Kurzem mit Anthropic zusammen, um 22 sicherheitsrelevante Fehler in der JavaScript-Engine zu entdecken, gefolgt von 271 zusätzlichen Schwachstellen in einem anschließenden Durchgang, der die gesamte Browser-Codebasis untersuchte. Im gesamten Software-Ökosystem markierten KI-gesteuerte Discovery-Tools, die größtenteils von Mythos angeführt wurden, bis Mitte Mai 2026 über 10.000 potenzielle Probleme – fast der Umfang eines ganzen Jahres an traditioneller Discovery in nur 2 Wochen.

Red Hat ist mittendrin in dieser Explosion. Im Jahr 2025 hat Red Hat Product Security 7.722 Sicherheitsschwachstellen gesichtet. In den ersten 4 Monaten des Jahres 2026 – vom 1. Januar bis zum 30. April – betrug die Zahl 2.826. Würde diese Rate anhalten, stiege die jährliche Gesamtzahl auf 8.596. Vom 1. Mai bis zum 15. Mai 2026 stieg die Zahl der geprüften Schwachstellen auf 712 an, was auf über 17.000 für das gesamte Jahr anwachsen würde – mehr als das Doppelte von 2025.

Copy Fail: Die erste von vielen weiteren

An jedem beliebigen Tag veröffentlicht CVE.org Hunderte von Datensätzen zu Schwachstellen. Am 22. April 2026 veröffentlichte eine CNA, kernel.org, 100 Schwachstellen mit den Nummern CVE-2026-31431 bis CVE-2026-31530. 

CVE-2026-31431 enthält diese Beschreibung.

„Im Linux-Kernel wurde die folgende Schwachstelle behoben: crypto: algif_aead – Revert to operating out-of-place. Dies macht den Commit 72548b093ee3 weitgehend rückgängig, mit Ausnahme des Kopierens der zugehörigen Daten. Die In-Place-Ausführung in algif_aead bietet keinen Vorteil, da Quelle und Ziel aus unterschiedlichen Zuordnungen stammen. Entfernen Sie die gesamte Komplexität, die für den In-Place-Betrieb hinzugefügt wurde, und kopieren Sie die AD einfach direkt.“

Dies war kein Grund zur Aufregung, bis eine Woche später, am 29. April, ein Dienst namens Xint.io eines Unternehmens namens Theori einen Proof-of-Concept-Angriff veröffentlichte und diesen Copy Fail nannte. Hinter dieser kryptischen Beschreibung verbarg sich eine Möglichkeit für unprivilegierte lokale Nutzende, sei es auf Bare Metal, in einer virtuellen Maschine (VM) oder in einem Container, Root-Zugriff auf ein System zu erhalten.

Glücklicherweise erfordert dieser Angriff Zugriff auf den Rechner. Angreifende müssen sich zuerst anmelden. Leider erfuhren Red Hat und andere Linux-Distributionen am selben Tag von dem Angriff wie die Öffentlichkeit.

Presseartikel und Online-Threads verbreiteten sich rasant. Das Rennen hatte begonnen.

Red Hat Product Security hat die Schwachstellenbewertung für dieses CVE umgehend auf „Important“ aktualisiert und das Sicherheitsbulletin um eine Strategie zur Risikominimierung sowie einen Zeitplan für die Fehlerbehebung ergänzt. Red Hat veröffentlichte den ersten von vielen Sicherheitshinweisen 5 Tage später, am 4. Mai. Mehrere weitere folgten kurz darauf.

Doch die Geschichte endet hier nicht.

Bereitstellung für Kunden

Bis 12 Uhr mittags (US Central Daylight Time) am 12. Mai generierte Copy Fail 1.132 Support-Fälle von Kunden, die Red Hat Enterprise Linux (RHEL), Red Hat OpenShift und Red Hat OpenStack nutzen. Später im Mai war diese Zahl auf über 1.300 Fälle gestiegen. Viele dieser Support-Fälle enthielten detaillierte Fragen oder komplexe Probleme, die nicht in einem einfachen FAQ-Dokument abgebildet werden können. Zum Beispiel:

• Einige Organisationen sind auf Anwendungen angewiesen, für die es nur begrenzten oder keinen Support gibt und die bei Upgrades oder Patches des Betriebssystems oft Probleme verursachen. In diesem neuen Zeitalter schneller Patches und Upgrades stellen diese Anwendungen ein noch größeres Risiko dar.
• Es stellen sich immer wieder Fragen dazu, wie CVSS-Scores (Common Vulnerability Scoring System) zur Risikobewertung herangezogen werden können. Die beste Antwort lautet: Es kommt darauf an. CVSS-Scores weisen Schweregrade isoliert zu. Die Bewertung von Risiken hängt von kundenspezifischen Details ab und erfordert menschliches Ermessen.
• Wie halten Sie mit einer endlosen Flut von KI-gekennzeichneten Problemen Schritt? Das Modell „alles patchen“ ist fehlerhaft. Anstatt den Betrieb ständig für Patch-Vorgänge zu unterbrechen, sollten Sie Ihre IT-Umgebung so gestalten, dass Sie Schwachstellen durch Defense-in-Depth mindern. Nutzen Sie bewährtes menschliches Ermessen, um zu bewerten, welche Schwachstellen tatsächlich eine Bedrohung für Ihre spezifische Umgebung darstellen, und patchen Sie diese.
• Mindestens ein Kunde wollte wissen, wie OpenStack 17.1 gepatcht wird, das von RHEL 9.2 abhängt. Die Lösung bestand darin, den SAP-Release-Stream von RHEL 9.2 zu nutzen.
• Ein anderer Kunde wollte wissen, welche Auswirkungen die Verwendung neuerer, gepatchter Kernel bei älteren RHEL 8-Systemen hätte. 
• Einige Organisationen nutzten alte OpenShift-Versionen und benötigten eine Patch-Strategie.
• Viele benötigten Hilfe dabei, das Patch-Deployment mit Anwendungsteams zu koordinieren, die eine Zero-Downtime anstreben.
• Andere Organisationen hatten Bedenken hinsichtlich der Performance.
• Einige benötigten Unterstützung bei Risikoanalysen für verschiedene Compliance-Initiativen.
• In zahlreichen Fällen baten Kunden um offizielle Zusicherungen von Red Hat für die Führungsebene.

Dies sind nur einige Beispiele. Sicherheitsbedrohungen sind immer belastend. Wir haben festgestellt, dass es wertvoll ist, direkt mit Kunden zusammenzuarbeiten, um Spekulationen von der Realität zu trennen – insbesondere wenn Schlagzeilen über den alarmierendsten Linux-Bug seit einem Jahrzehnt erscheinen. 

Der Bedarf an einem kommerziellen Partner, der die Lücke zwischen Upstream-Innovation und Sicherheitsschutz auf Unternehmensniveau schließt, war noch nie so deutlich.

Red Hat Technical Account Management Service für Produktsicherheit

Um Sicherheitssituationen wie diese zu bewältigen, bietet Red Hat jetzt den Red Hat Technical Account Management Service für ProduktsicherheitSeite verfügbar in Englisch (Deutsch ist nicht verfügbar) an. Technical Account Manager (TAMs) fungieren als Verbindungspersonen zwischen Kunden sowie Produkt- und Engineering-Teams bei Red Hat und der Open Source Community. Während sich die meisten TAMs auf ein bestimmtes Produkt oder eine bestimmte Technologie konzentrieren, betrachten Security-TAMs von Red Hat die Sicherheitslage im gesamten Produktportfolio von Red Hat ganzheitlich. Diese TAMs unterstützen Sie bei Folgendem:

• Vermittlung von Ad-hoc-Wissen über verschiedene Angriffstaktiken
• Unterstützung bei der Nutzung von Sicherheits- und Compliance-Tools von Red Hat
• Vorschlagen von gehärteten Konfigurationen und Deployments nach Bedarf
• Erläuterung, wie Red Hat Risiken reduziert und Schwachstellen mindert
• Bereitstellung präziserer Schwachstellenanalysen für Produkte von Red Hat
• Unterstützung bei der Priorisierung von Berichten aus Schwachstellen-Scans
• Erleichterung der Kommunikation mit Kunden, Teams von Red Hat, Partnern, anderen Anbietern und der Open Source Community, sofern möglich
• Einflussnahme auf das Produktmanagement von Red Hat, Produktsicherheitsteams, Partner, andere Anbieter und die Open Source Community durch Vertretung von Kundenstandpunkten
• Förderung des Bewusstseins für die Software-Wertschöpfungskette und Angriffe auf die Lieferkette
• Beratung zu möglichen Abhilfemaßnahmen bei größeren Sicherheitsvorfällen
• Unterstützung bei der Erstellung von Post-Mortem-Bewertungen von Sicherheitsvorfällen

Kontinuierliche Kommunikation ist immer entscheidend, insbesondere in Krisenzeiten. Dies gilt umso mehr, da KI die Geschwindigkeit und den Schweregrad von Meldungen zu Sicherheitslücken erhöht. Security-TAMs von Red Hat sind besonders positioniert. Sie unterstützen Kunden dabei, relevantes Wissen von irrelevanten Informationen zu unterscheiden und auf andere Anliegen einzugehen. 

Sicherheit und Vertrauen

In diesem neuen Zeitalter KI-gestützter Schwachstellenberichte stellt die größte Bedrohung nicht nur die Anzahl der Fehler dar, sondern ein zu großes Vertrauen in Automatisierung. KI kann Schwachstellen finden. Sie kann jedoch keine risikobasierte Sicherheitsstrategie entwickeln oder die Integrität gewährleisten, die erforderlich ist, um Ihrem Unternehmen in einer Krise zur Seite zu stehen. Das menschliche Urteilsvermögen bleibt das Einzige, auf das Sie sich wirklich verlassen können. Fehler in Prozessen zur verantwortungsvollen Offenlegung stellen eine weitere Bedrohung dar. Jedes Mal, wenn jemand eine neue Schwachstelle offenlegt, bevor Entwicklungsteams eine Abhilfemaßnahme oder einen Patch veröffentlichen können, ermöglicht dies Angreifenden, Kunden zu überraschen.

Niemand kann vollständige Immunität gegen Angriffe versprechen. Security-TAMs von Red Hat helfen jedoch durch eine enge Abstimmung mit Red Hat Product Security und der Community. So bieten sie die strategische Anleitung und technische Unterstützung, die KI nicht leisten kann. 

Die Fähigkeit, den Unterschied zwischen Hype und Realität zu erkennen oder eine frühzeitige Warnung vor einem bevorstehenden Angriff zu erhalten, kann den Ausschlag zwischen einer rechtzeitigen Abhilfemaßnahme und einer Katastrophe geben. Warten Sie nicht auf die nächste wichtige Offenlegung, um Ihre Infrastruktur zu schützen. Erfahren Sie mehr darüber, wie ein Security-TAM von Red Hat die proaktive Planung und technische Unterstützung bietet, die Ihr Unternehmen benötigtSeite verfügbar in Englisch (Deutsch ist nicht verfügbar).

Wenden Sie sich an Ihr Red Hat Account Team, um mehr zu erfahren, oder kontaktieren Sie Red Hat.
 

Finden Sie diese Zahlen, indem Sie zur für Menschen lesbaren Red Hat CVE-Datenbank navigieren, einen geeigneten Datumsbereich auswählen und die Anzahl am Ende der Seite prüfen.