2.308 potenzielle Schwachstellen fand ein automatisiertes Forschungssystem im Linux-Kernel. 1.724 davon wurden bestätigt, 948 ermöglichen lokale Privilegieneskalation. Die Zahlen zeigen, wo automatisierte Sicherheitsforschung heute steht: Sie findet schnell Kandidaten, die Bewertung bleibt aber aufwendig.
Der OpenAI-Cyber-Prototyp zeigt, wie Schwachstellensuche vom Einzelexperiment zu einem reproduzierbaren Prozess werden kann. Statt jedes potenzielle Problem einzeln zu prüfen, arbeitet eine Pipeline mit spezialisierten Modellen, isolierten Testumgebungen und menschlicher Kontrolle. Das ist nicht nur ein Automatisierungsprojekt. Es geht um Priorisierung: Der Linux-Kernel ist so groß und wird so aktiv entwickelt, dass klassische Forschungskapazitäten an der Zahl der Funde scheitern.
Die Wahl des Kernels ist kein Zufall. Rund 40 Millionen Zeilen Code bilden die Grundlage von Android-Geräten, Cloud-Infrastruktur, Supercomputern und vielen anderen Systemen. Jede Schwachstelle dort kann weitreichende Folgen haben. Das 2026 durchgeführte Projekt ist deshalb mehr als eine technische Demonstration. Es zeigt, wie sich ein Modellsystem in die Arbeit etablierter Kernel-Entwickler einfügen lässt, ohne menschliche Verantwortung zu ersetzen.
Die fünf Stufen der automatisierten Schwachstellensuche
Die Pipeline arbeitet in fünf Schritten. Zuerst identifizieren Scout-Agenten sicherheitsrelevante Bereiche des Codes. Analyst-Agenten untersuchen diese Ziele und liefern potenzielle Schwachstellen. Ein Triage-Agent versucht anschließend, jeden Fund dynamisch zu reproduzieren und Laufzeitbelege zu sichern.
Nach der Validierung prüft ein weiterer Agent, ob die bestätigte Lücke praktisch ausnutzbar ist. Zuerst läuft eine statische Analyse, danach entwickeln Agenten Exploits in isolierten virtuellen Maschinen. Für jede bestätigte Schwachstelle erzeugt das System außerdem einen Korrekturvorschlag. Am Ende prüfen Menschen: Forschende bewerten Exploit, Patch und vorgeschlagenen Schweregrad, bevor eine Meldung an die Maintainer geht.
Jedes Paket enthält eine Ursachenanalyse, einen minimalen Proof of Concept, einen Patch und gegebenenfalls einen vollständigen Exploit. Für Auditoren ist das ein Werkzeugkasten. In der Praxis wirkt es vor allem als Sortierstrecke: Tausende Kandidaten durchlaufen ein Raster, das Möglichkeit, Reichweite und tatsächliche Ausnutzbarkeit trennt. Am Ende bleiben Berichte, die ein Maintainer verstehen und priorisieren kann.
Die Kosten der Stufen unterscheiden sich stark. Die Entdeckung war mit 3.426 API-Credits für die Zielauswahl und 316.549 Credits für die Analyse vergleichsweise günstig. Teurer wurde die Validierung mit 73.330 Credits, am teuersten die Exploit-Entwicklung mit 775.929 Credits. Die Ausgaben zeigen, wo Automatisierung viel bringt und wo Menschen weiterhin eingebunden bleiben müssen.
Warum der Linux-Kernel als Testobjekt diente
Der Linux-Kernel verbindet Verbreitung mit Komplexität. Das macht ihn für diese Frage geeignet. Systemaufrufe, Netzwerkprotokolle, Dateisysteme und Gerätetreiber bieten eine große Angriffsfläche. Viele Komponenten greifen direkt auf Speicher- und Berechtigungsmechanismen zu. Fehler dort führen nicht nur zu Abstürzen, sondern können Sicherheitsgrenzen aushebeln.
Die Auswahl war bewusst anspruchsvoll. Ziel war keine bequeme Testumgebung, sondern die Frage, wie gut ein Modell mit einer Codebasis umgeht, die größer ist als der übliche Blick einzelner Sicherheitsforscher. Hunderttausende Dateien, komplexe Schnittstellen und laufende Änderungen im Upstream-Projekt erzeugen Reibung, die Automatisierung adressieren soll.
Ein zweiter Grund ist Verantwortung. Schwachstellen im Kernel betreffen nicht nur Testsysteme. Eine offene Lücke kann in Produktionssysteme wandern, wenn Updates ausbleiben. Die Ergebnisse mussten deshalb nicht nur zahlreich sein. Sie mussten belastbar genug sein, um von der Community akzeptiert, priorisiert und repariert zu werden. Der Linux-Kernel ist damit Testfall mit realen Folgen.
Der Scan orientierte sich am Kernelstand von Mitte Oktober 2026. Nach zehn Tagen autonomer Suche und anschließender manueller Analyse waren 61 der gefundenen LPEs bereits upstream gepatcht. Weitere 43 waren mit Staging-Patches in Bearbeitung, 299 wurden öffentlich gemeldet und diskutiert. Die Reaktion zeigt: Die Pipeline arbeitet nicht gegen die Maintainer, sondern liefert Werkzeuge für bestehende Prozesse.
Von 2.308 Funden zu 1.724 bestätigten Lücken
Der Unterschied zwischen Kandidat und bestätigter Schwachstelle ist entscheidend. Statische Codeanalyse liefert Hinweise, keine Beweise. Ein Modell kann eine Fehlinterpretation als Befund melden, die sich real nicht auslösen lässt. Die Validierung wurde deshalb eng gefiltert: Untersucht wurden nur Funde, die ein niedrig privilegierter Benutzer erreichen kann, keine besonderen Fähigkeiten erfordern und messbare Hinweise auf Speicherkorruption liefern.
Für jeden Kandidaten erzeugte ein Triage-Agent einen Proof of Concept und führte ihn in einer isolierten virtuellen Maschine mit einem per Kernel Address Sanitizer instrumentierten Linux-Kernel aus. Beobachtet wurden Programmausgabe und Systemkonsole. Die Agenten wiederholten den Vorgang, bis sich das gemeldete Verhalten reproduzieren ließ oder die möglichen Auslösebedingungen erschöpft waren. Innerhalb von 30 Stunden wurden 1.724 Schwachstellen reproduziert, rund 74,7 Prozent aller Kandidaten.
Die Quote offensichtlich falscher Analysen war niedrig. Nur 3,1 Prozent der Befunde gingen von unmöglichen Bedingungen aus. Die übrigen nicht reproduzierten Funde benötigten erhöhte Privilegien, scheiterten an schwer auslösbaren Race Conditions oder an seltenen Voraussetzungen wie einer Allocation-Fehlerbedingung an genau einer Stelle. Solche Fälle sind nicht zwingend unbedeutend. Sie zeigen aber, wo dynamische Validierung an Grenzen stößt und statische Empfehlungen weniger belastbar sind.
Für die Kosten ist diese Trennung wichtig. Die Validierung eines echten und eines falschen Befunds kostete ähnlich viel. Jeder Kandidat musste mit einem lauffähigen Proof of Concept konfrontiert werden, unabhängig vom Ergebnis. Das spricht für eine frühe Bereinigung offensichtlicher Fehlbefunde. Wird eine falsche Analyse vor der teuren dynamischen Phase aussortiert, sinken die Gesamtkosten.
Exploitbarkeit, Schutzmechanismen und echte Risiken
Eine bestätigte Schwachstelle ist nicht automatisch dringend. Manche Lücken ermöglichen nur lokalen Denial-of-Service, andere verhelfen einem unprivilegierten Benutzer zu Root-Rechten. Diese Unterscheidung entscheidet, welche Meldungen zuerst bearbeitet werden. Ein erster Screening-Agent prüfte deshalb jeden Bericht, Crash-Log und relevanten Quellcode-Abschnitt. Er arbeitete bewusst großzügig, um möglicherweise schwere Funde nicht vorschnell zu verlieren.
Das Ergebnis waren 313 Kandidaten für Informationslecks und 1.238 für lokale Privilegieneskalation. Die Exploit-Entwicklung lief in virtuellen Maschinen mit den Schutzmechanismen einer Standard-Linux-Distribution: SMEP, SMAP, KASLR und HARDENED_USERCOPY. Diese Konfiguration verhindert unrealistische Bewertungen, die nur ohne Sicherheitsfunktionen funktionieren würden. Der Exploit musste also unter Bedingungen laufen, wie sie ein normales System tatsächlich bietet.
Am Ende entstanden 291 Proofs of Concept für Informationslecks und 1.169 funktionierende LPE-Exploits. Variantenanalyse und unterschiedliche Korrekturen ergaben 948 eigenständige Patches für die zugrunde liegenden Schwachstellen. Diese Zahl gilt als Maß für die tatsächlich eigenständigen LPEs. Ein erfolgreicher Exploit kostete im Durchschnitt 359 Credits, ein fehlgeschlagener Versuch 3.922 Credits pro Fall.
Die Ursache lag in einzelnen schwer ausnutzbaren Schwachstellen wie Race Conditions. Eine klare Abbruchregel – etwa nach einer Stunde ohne Fortschritt – hätte die Ausgaben in dieser Phase deutlich reduziert. Für den praktischen Betrieb heißt das: Gute Automatisierung braucht nicht nur Fähigkeiten, sondern auch Grenzen. Ein System, das endlos weiterläuft, ist nicht gründlicher, sondern teurer.
Patch-Erstellung und Zusammenarbeit mit der Community
Für jede validierte Schwachstelle erzeugt die Pipeline außerdem einen Patch. Das Modell erhält den relevanten Quellcode und die Vorgabe, etablierte Praktiken der Kernel-Community zu befolgen. Dazu gehören statische Prüfungen, die Stilregeln des benachbarten Codes und Variantenanalyse, damit die Korrektur nicht nur einen einzelnen Auslöser abdeckt. Ein Patch soll nicht nur gebaut, sondern eingebettet werden.
Nach den Empfehlungen der Kernel-Community wurden zuerst besonders kritische Schwachstellen gemeldet. Hunderte Berichte und Patches sind bereits übermittelt. Für die übrigen Funde arbeitet das Team mit Partnern der Patch-the-Planet-Initiative daran, weitere Korrekturen schrittweise nachzureichen. Das Vorgehen ist bewusst konservativ. Die Verantwortung für das Upstreaming bleibt bei erfahrenen Sicherheitsforschenden und Maintainern; das automatisierte System übernimmt die aufwendige Vorarbeit.
Ein wichtiger Punkt ist die Geschwindigkeit des Patch-Zyklus. Eine erneute Prüfung gegen den neuesten Code ist nötig, weil inzwischen zusammengeführte Änderungen neue Schwachstellen enthalten können. Funde, die gegen eine ältere Version korrekt waren, können in der aktuellen Version bereits behoben oder obsolet sein. Ohne diese Prüfung entstehen doppelte Meldungen und unnötiger Aufwand. Automatisierte Triage muss deshalb den Patch-Fluss berücksichtigen, nicht nur die Entdeckung.
Die Ergebnisse gehören zum größeren Daybreak-Programm, mit dem OpenAI die Sicherheit offener Softwareprojekte unterstützt. Der Prototyp zeigt, dass der Ansatz über eine einzelne Schwachstellensammlung hinausgeht. Er beschreibt eine Infrastruktur, die künftig laufend eingesetzt werden kann, um Funde zu reproduzieren, zu priorisieren, auszunutzen und zu reparieren.
Was die Zahlen zeigen
Wichtiger als die Zahl der Funde ist ihre Verteilung über die Pipeline. Die Entdeckung ist der günstigste und am leichtesten skalierbare Schritt. Validierung bindet deutlich mehr Ressourcen. Die Exploit-Entwicklung ist am teuersten; dort liegt auch der größte Hebel für bessere Abbruchlogik und gezieltere Auswahl.
Die Kostenangaben sind als Obergrenze zu verstehen. Das Team betont, dass es um Methodik und die Messung der Modellfähigkeit ging, nicht um maximale Effizienz. Bessere Testumgebungen, eine bessere Aufteilung der Agenten und eine frühere Bereinigung von Fehlbefunden könnten die Ausgaben pro Stufe deutlich senken. Wer die Zahlen liest, sollte daher nicht auf eine fertige Produktionsmaschine schließen, sondern auf einen klar vermessenen ersten Prototypen.
Die Zusammenarbeit mit der Kernel-Community zeigt, dass Automatisierung vor allem dort funktioniert, wo sie in bestehende Verantwortungsstrukturen eingebettet ist. Die Pipeline liefert Beweise, Patches und Analysen. Die Entscheidung über Schweregrad, Upstreaming und langfristige Wartung bleibt bei Menschen. Diese Arbeitsteilung trägt: Maschinen vervielfachen die Reichweite der Forschung, die Community behält die Verantwortung für die Reparatur.
Für Anwender bleibt ein Rat: Updates installieren. Die 61 binnen Tagen upstream gepatchten LPEs zeigen, wie schnell aus einem Befund ein reales Risiko wird. Moderne Schwachstellensuche verkürzt die Zeit zwischen Fehler und Entdeckung. Sie kann aber auch die Zeit bis zur Ausnutzung verkürzen. Automatisierung hilft Angreifern wie Verteidigern. Wer sie nutzt, sollte Updates zügig einspielen.
Quelle: openai.com
