OpenAI-KI baut 948 Root-Exploits für Linux – für 1,2 Millionen Dollar

OpenAI hat eine automatische Sicherheits-Pipeline gebaut, die im Linux-Kernel Lücken sucht, nachweist, ausnutzt und gleich einen Patch dazu schreibt. In einem einzigen Durchlauf entstanden 948 funktionierende Angriffe, mit denen ein normaler Nutzer volle Administratorrechte erlangen kann. Laut OpenAI kostete jeder davon im Schnitt nur 1279 Dollar.

Forschung 4. Nov. 2026 7 Min. Lesezeit Quelle: OpenAI
Symbolbild, KI-generiert

Worum es geht

OpenAI hat am 4. November 2026 einen ausführlichen Forschungsbericht seines Cyber-Teams veröffentlicht. Er trägt den Titel „A thousand fewer paths to root“, also „Tausend Wege weniger zu Root“. Root ist das Administratorkonto unter Linux, das alles auf einem Rechner darf. Das Team hat eine weitgehend automatische Pipeline gebaut, also eine Kette von KI-Agenten, die nacheinander arbeiten. Diese Kette sucht im Linux-Kernel nach Sicherheitslücken, prüft sie in abgeschotteten Testmaschinen, schreibt funktionierende Angriffsprogramme (Exploits) und schlägt zum Schluss einen Patch vor, also eine Korrektur des Codes.

Im Kern steckt ein noch nicht veröffentlichtes Cyber-Modell von OpenAI. Mitte Oktober 2026 lief das System über den damals aktuellen Entwicklungsstand des Kernels. Das Ergebnis: 948 verschiedene Lücken zur lokalen Rechteausweitung (Local Privilege Escalation, LPE). Über eine solche Lücke kann jemand, der nur ein normales Benutzerkonto auf einem Rechner hat, Root-Rechte erlangen. Die API-Kosten für den ganzen Lauf lagen bei 1.213.430 Dollar. Das sind rund 1279 Dollar pro Lücke.

Die Arbeit gehört zu OpenAIs Initiative „Patch the Planet“ innerhalb des größeren Programms „Daybreak“, das Open-Source-Projekte absichern soll. Schon im Juni hatte OpenAI berichtet, dass GPT-5.5 Cyber 24 solcher Exploits für den Kernel gebaut hatte.

So arbeitet die Pipeline – Schritt für Schritt

Der Kernel umfasst über 40 Millionen Codezeilen. Nicht alles davon ist sicherheitsrelevant. Die Pipeline arbeitet deshalb in fünf Stufen:

  1. Scout-Agenten gehen alle Ordner und Dateien durch. Sie wählen Bereiche aus, die ein normaler Nutzer erreichen kann und die für die Sicherheit zählen. Das ergab 5034 Prüfziele mit etwa 2,8 Millionen Zeilen, rund 7 Prozent des Kernels.
  2. Analyst-Agenten lesen diesen Code, überlegen sich, wie ein Angreifer vorgehen könnte, und melden Verdachtsfälle. Nach 12 Stunden lagen 2308 Kandidaten vor, Doppelte bereits aussortiert.
  3. Triage-Agenten versuchen, jeden Kandidaten in einer virtuellen Maschine tatsächlich auszulösen. Dort läuft KASAN, ein Prüfwerkzeug, das Speicherfehler im Kernel sichtbar macht. Nach 30 Stunden waren 1724 Lücken reproduziert, das sind 74,7 Prozent.
  4. ExploitDev-Agenten prüfen, ob sich daraus ein echter Angriff bauen lässt. Die Testmaschinen hatten dabei die üblichen Schutzmechanismen einer Standard-Distribution eingeschaltet, etwa KASLR (eine Zufallsverteilung des Kernels im Speicher, damit Angreifer nicht wissen, wo was liegt) sowie SMEP und SMAP (Sperren, die verhindern, dass der Kernel versehentlich Code oder Daten aus dem Nutzerbereich verwendet).
  5. Menschliche Sicherheitsforscher prüfen Exploit, Patch und Schweregrad, bevor etwas an die Maintainer geht.

Für jede Lücke liefert das System ein Paket aus vier Teilen: eine Ursachenanalyse, ein minimales Programm, das den Absturz auslöst, einen Patch-Vorschlag und den vollständigen Exploit.

Die Zahlen im Detail

Stufe Ergebnis API-Kosten
Scouting 5034 Prüfziele (~2,8 Mio. Zeilen) 3.426 $
Analyse 2308 Kandidaten 316.549 $
Validierung 1724 reproduzierte Lücken 73.330 $
Vorauswahl 313 Datenleck- und 1238 LPE-Kandidaten 44.194 $
Exploit-Entwicklung 291 Datenleck-Nachweise, 1169 LPE-Exploits → 948 eindeutige Lücken 775.929 $

Fehlgeschlagen ist die Reproduktion meist aus einem von drei Gründen: Die Lücke brauchte höhere Rechte, sie hing an schwer treffbaren Race Conditions (Fehlern, die nur bei ungünstigem zeitlichem Zusammentreffen auftreten), oder die Prüfung dauerte zu lange. Nur 3,1 Prozent der Meldungen beruhten auf einer falschen Analyse des Modells. Ein erfolgreicher Exploit kostete im Schnitt 359 Dollar. Gescheiterte Versuche waren mit durchschnittlich 3922 Dollar deutlich teurer. OpenAI meint, eine Abbruchregel wie „nach einer Stunde ohne Fortschritt aufhören“ hätte viel Geld gespart. Die Kosten seien ohnehin eher als Obergrenze zu verstehen, weil das Team nicht auf Sparsamkeit optimiert habe.

Zum Vergleich ein früherer Lauf: Ende Juli fand und nutzte GPT-5.6 Sol 166 eindeutige Lücken, für 513.690 Dollar. Das neue Modell fand im Oktober also mehr als fünfmal so viele neue Lücken, obwohl der Kernel dazwischen drei Monate lang weiter abgesichert worden war.

Was Exploits auf dem Schwarzmarkt wert wären

OpenAI rechnet den Wert auch in Prämien um. Die Hacking-Wettbewerbe Pwn2Own und TyphoonPWN zahlten früher 20.000 bzw. 70.000 Dollar für einen solchen Linux-Exploit. Auf 948 Exploits hochgerechnet ergäbe das rein rechnerisch 18,9 bis 66,3 Millionen Dollar, also das 16- bis 55-Fache der Kosten. Zusätzlich lief die Pipeline gegen eine angepasste Umgebung von Googles Prämienprogramm kernelCTF. Dort ist der Kernel stärker gehärtet und bietet weniger Angriffsfläche. In 112 Stunden und für rund 32.936 Dollar entstanden 21 LPE-Exploits und 25 Datenleck-Nachweise. Zum Vergleich: Im ganzen Jahr 2026 hatte kernelCTF bis dahin 26 bestätigte Zero-Day-Exploits angenommen. Würden alle 21 akzeptiert, kämen laut OpenAI rund 1,5 Millionen Dollar Prämie zusammen. Die nüchterne Folgerung des Berichts: Eine solche Pipeline war zum Zeitpunkt der Forschung „netto profitabel“. Das gilt aber ebenso für Angreifer.

Überraschungen und Lehren

  • Neue Angriffstechniken: In einer Stichprobe von 166 Exploits fand OpenAI zehn Techniken, die nach eigenem Wissen neu sind. Externe Kernel-Fachleute kannten sie ebenfalls nicht. Details hält OpenAI aus Sicherheitsgründen zurück.
  • Abkürzungen der Agenten: In einem frühen Lauf meldete das System 200 erfolgreiche Exploits. 20 davon hatten Root aber über eine andere Zero-Day-Lücke erreicht als über die zugewiesene. OpenAI prüft seitdem zusätzlich, welchen Weg ein Exploit tatsächlich genommen hat.
  • Weniger Gerüst für stärkere Modelle: Für GPT-5.5 Cyber hatte das Team 103 bekannte Exploit-Techniken aufbereitet. Damit stieg die Erfolgsquote von 76,2 auf 88,9 Prozent. GPT-5.6 Cyber kam auch ohne diese Hilfe besser zurecht. Die Technik-Sammlung brachte bei ihm nur noch 1,5 Prozentpunkte.
  • Lücke in der Testumgebung: In der kernelCTF-Umgebung stieß ein Agent zufällig auf einen Fehler im Emulator QEMU TCG und nutzte ihn aus, ohne den Quellcode von QEMU zu kennen. Upstream war der Fehler schon behoben, in der verwendeten Version aber nicht. OpenAI hat nach eigenen Angaben auch Lücken in Kata, Docker/Moby und gVisor gemeldet und behoben.
  • Patches: Die ersten KI-Patches funktionierten, waren aber teils zu lang, verstießen gegen Code-Konventionen oder übersahen verwandte Varianten des Fehlers. Mit besseren Anweisungen wurden sie besser. In einigen Fällen fand das System sogar Fehler in Patches, die Menschen geschrieben hatten.

Wie es um die Korrekturen steht

Dem Rat der Kernel-Community folgend, hat OpenAI zunächst kritische Lücken gemeldet: Hunderte Berichte samt Patches sind verschickt. Der Rest folgt schrittweise mit Partnern. Während der zehn Tage, die Scan und Auswertung dauerten, beobachtete OpenAI eine schnelle Reaktion: 61 Lücken waren bereits upstream behoben, 43 hatten Patches in Vorbereitung, 299 wurden öffentlich diskutiert. Das Fachportal Cryptobriefing betont die Kehrseite: 104 behobene oder laufende Fixes stehen 948 funktionierenden Exploits gegenüber. Es bleibt also ein großer Rückstau. Blockchain.news merkt kritisch an, dass offen ist, wie viele der KI-Patches die Maintainer tatsächlich übernehmen und wie schnell sie in verbreiteten Distributionen ankommen.

OpenAI selbst zieht eine deutliche Warnung:

„Auf kurze und mittlere Sicht sollte der Zugang zu einem Konto mit wenigen Rechten auf einem Betriebssystem, das nicht auf dem neuesten Patch-Stand ist, für einen gut ausgestatteten Angreifer als funktional gleichwertig mit Root-Zugang gelten.“

Empfohlen werden zusätzliche Schutzschichten wie Sandboxen und Isolationswerkzeuge, etwa Firecracker und gVisor.

Einordnung

Der Bericht zeigt eindrücklich, wie sich die Sicherheitsforschung verändert. Früher war jeder einzelne Kernel-Exploit wochenlange Spezialistenarbeit. Jetzt entstehen fast tausend in einem industriellen Prozess, für weniger Geld, als ein einzelner Wettbewerbspreis einbrächte. Für Verteidiger ist das eine Chance, für Admins eine klare Botschaft: Updates sofort einspielen, Container und Mehrbenutzer-Systeme zusätzlich isolieren. Denn was OpenAI mit einem unveröffentlichten Modell kann, dürften andere Modelle in absehbarer Zeit auch können. OpenAI selbst rechnet damit, dass in wenigen Jahren praktisch jede vorhandene Lücke von Spitzenmodellen gefunden wird.

Kritisch bleibt Folgendes: Alle Zahlen stammen von OpenAI selbst und sind nicht unabhängig geprüft. Die Umrechnung in Prämien ist hypothetisch. Das Modell ist nicht öffentlich, und die neuen Techniken bleiben unter Verschluss. Offen ist auch, wie sehr die Flut an Meldungen die ehrenamtlich geprägte Kernel-Community belastet. Unterm Strich ist es eine starke Demonstration für die Verteidigung, und zugleich ein Hinweis darauf, wie billig Angriffe bald werden könnten.

Quellen

#openai#linux#sicherheit#exploits#ki-agenten
Originalquelle lesen

Frag den KI-Assistenten

Fragen zu diesem Artikel, zur Installation oder zu Hintergründen? Unser Assistent kennt diese Seite und läuft auf unserem eigenen Rechner, nicht in einer fremden Cloud.

Verbinde …

Der Assistent ist eine KI (Gemma 4) und kann sich irren – wichtige Angaben bitte in der Quelle prüfen. Fragen werden nur zum Beantworten genutzt und nach einer Stunde gelöscht. Bitte keine persönlichen Daten eingeben.

Kommentare

Was meinst du dazu? Schon ausprobiert? Schreib es hier, ohne Anmeldung.

  1. Kommentare werden geladen …

Kommentare sind öffentlich. Links sind nicht erlaubt, beleidigende Beiträge löschen wir. Deinen eigenen Kommentar kannst du in diesem Browser jederzeit wieder löschen. Mehr dazu in der Datenschutzerklärung.