Linux-Kernel-Sicherheitslücken: OpenAI-Agenten schrieben 948 Exploits
Sicherheitslücken im Linux-Kernel im großen Stil: Eine Agenten-Pipeline von OpenAI bestätigte in einem Durchlauf 948 Root-Lücken. So lief das ab.
Dieser Artikel in anderen Sprachen:العربيةEnglishEspañolFrançaisItaliano日本語Polski简体中文
In diesem Artikel
Das Sicherheitsforschungsteam von OpenAI hat am 4. November den Bericht „A thousand fewer paths to root“ veröffentlicht. Er beschreibt eine autonome Agenten-Pipeline, die Sicherheitslücken im Linux-Kernel sucht, Exploits dafür schreibt und Patches vorbereitet. In einem einzigen Durchlauf mit dem internen Cybersecurity-Modell von OpenAI bestätigte sie 948 Lücken vom Typ Local Privilege Escalation und bereitete Patches dafür vor, also Lücken, über die ein normaler Benutzer zu root werden kann. API-Kosten: rund 1,2 Millionen Dollar.
Was genau haben die OpenAI-Agenten gefunden?
Die Zahlen aus dem Bericht (zusammengefasst unter anderem von ai-tldr.dev und RuntimeWire):
- 2.308 Kandidaten für Lücken im aktuellen Master-Branch des Kernels von Mitte Oktober 2026,
- 1.724 davon wurden reproduziert, also als echte Schwachstellen bestätigt,
- 948 eindeutige LPE-Lücken (Local Privilege Escalation) endeten mit einem funktionierenden Exploit und einem Patch-Vorschlag,
- die Gesamtkosten lagen bei 1.213.430 Dollar an API-Credits. Den größten Teil, 775.929 Dollar, verschlang das Schreiben der Exploits (die Suche nach Lücken kostete 316.549, die Validierung 73.330 Dollar).
Laut OpenAI nutzten die Agenten dabei 10 Exploit-Techniken, die externe Kernel-Experten noch nie gesehen hatten. Diese Techniken veröffentlicht das Unternehmen nicht.
Das Modell dahinter ist nicht öffentlich verfügbar. Es handelt sich um ein kommendes, spezialisiertes Cybersecurity-Modell von OpenAI, dessen Namen die Berichte nicht nennen.
Wie suchten die Agenten nach Lücken im Linux-Kernel?
Die Pipeline verteilt die Arbeit auf mehrere Arten von Agenten (so beschreibt es ai-tldr.dev):
- Späher-Agenten wählten 5.034 Ziele aus, also Codeabschnitte, die ein Benutzer ohne Rechte erreichen kann (etwa 7 % des Kernel-Codes),
- Analyse-Agenten durchsuchten diese Abschnitte,
- Triage-Agenten schrieben für jeden Fund einen Proof of Concept und führten ihn in einer virtuellen Maschine mit KASAN (Kernel Address Sanitizer) aus, bis sich der Fehler reproduzieren ließ,
- Exploit-Agenten prüften die stärksten Kandidaten auf einer normalen Distribution mit aktivierten Schutzmechanismen SMEP, SMAP und KASLR,
- die letzte Stufe schrieb die Patches.
Spannend: Zu Beginn des Durchlaufs erlangten 20 von 200 „erfolgreichen“ Exploits root über eine ganz andere Zero-Day-Lücke als die, die der Agent ausnutzen sollte. Deshalb gibt es in der Pipeline zusätzliche Prüfungen, ob ein Exploit wirklich den zugewiesenen Fehler nutzt.
Das Team testete die Pipeline auch auf einem gehärteten Kernel aus Googles kernelCTF-Programm. In 112 Stunden entstanden dort 25 Proofs of Concept für Informationslecks und 21 LPE-Exploits, für rund 32.936 Dollar an API-Credits.
Sind diese Lücken schon geschlossen?
Noch nicht alle. 948 ist die Zahl der bestätigten Exploits mit Patch-Kandidaten, nicht die Zahl der Patches im Kernel. Nach 10 Tagen waren 61 Lücken im Mainline-Kernel geschlossen, für weitere 43 warteten Patches in Staging-Branches.
Auf Rat der Kernel-Community begann OpenAI mit den kritischen Lücken und meldet den Rest schrittweise, gemeinsam mit den Partnern des Programms Patch the Planet. Laut Startup Fortune startete das Programm im Juni 2026 unter anderem mit Trail of Bits und HackerOne, und Menschen prüfen jeden Fund, bevor er bei einem Maintainer landet.
Warum wird so viel darüber gesprochen?
Weil die Größenordnung selbst Sicherheitsleute beeindruckt. Der Bericht landete auf der Startseite von Hacker News, wo ein Teammitglied Fragen beantwortet. In den Kommentaren taucht immer wieder eine Frage auf: Wie konnten im Kernel fast tausend Wege zu root stecken?
Am stärksten wirkt das Fazit des Berichts selbst: Vorerst muss man ein Konto mit geringen Rechten auf einem System ohne die neuesten Patches für einen gut ausgestatteten Angreifer wie root-Zugriff behandeln (im Original „functionally equivalent to root access for a well-resourced threat actor“).
Das ist ein weiteres Signal in dieselbe Richtung. Ende Oktober fand Claude Lücken in Chrome, Safari und Linux, und Google stellte Gemini 4 Carbon vor, ein Cybersecurity-Modell nur für ausgewählte Unternehmen. Der Unterschied: Hier geht es um Hunderte Lücken in einem Durchlauf und um eine konkrete API-Rechnung.
Worauf sollte man achten?
Erstens darauf, wer die Zahlen liefert. Das Experiment hat OpenAI selbst durchgeführt und beschrieben, und die Kosten nennt das Unternehmen eine Obergrenze, weil ein besserer Harness sie senken könnte. Unabhängige Überprüfung gibt es bisher kaum, also sollten wir die Zahlen mit Vorsicht genießen.
Zweitens auf die Kehrseite. Dasselbe Werkzeug in den Händen von Angreifern würde die Zeit vom Kernel-Commit bis zum funktionierenden Exploit verkürzen. OpenAI entgegnet, dass das Modell nicht öffentlich ist und die Exploits und neuen Techniken nicht ins Netz gelangen.
Drittens auf Updates. Der Rat von OpenAI an Verteidiger ist einfach: alten Code erneut scannen, wenn bessere Modelle erscheinen, und Systeme aktuell gepatcht halten. Mehr zum Schutz von Agenten und Schlüsseln schreibe ich im Leitfaden zur Sicherheit von KI-Agenten.
FAQ
Wie viele Sicherheitslücken im Linux-Kernel hat OpenAI gefunden?
Die Pipeline meldete 2.308 Kandidaten, reproduzierte 1.724 Schwachstellen und schrieb für 948 eindeutige LPE-Lücken einen funktionierenden Exploit und einen Patch-Vorschlag.
Ist mein Linux gefährdet?
Die Exploits wurden nicht veröffentlicht, und die Patches gelangen schrittweise in den Kernel (nach 10 Tagen waren 61 im Mainline-Kernel). Das Beste, was wir tun können: den Kernel regelmäßig aktualisieren.
Kann man dieses OpenAI-Modell ausprobieren?
Nein. Laut den Berichten ist es ein kommendes, noch nicht veröffentlichtes Cybersecurity-Modell von OpenAI.
Wie viel hat das gekostet?
Laut OpenAI 1.213.430 Dollar an API-Credits für den gesamten Durchlauf.