Auf dem Papier passen 948 Schwachstellen in eine einzige Zeile. In der Praxis steht hinter dieser Zahl eine Größenordnung, die den gewohnten Takt der Sicherheitsforschung infrage stellt. Bei einem Durchlauf Mitte Oktober 2026 erzeugte die Pipeline nach Angaben von OpenAI 1.169 funktionierende LPE-Exploits, die das Unternehmen 948 unterschiedlichen Schwachstellen zuordnete. OpenAI beziffert den API-Verbrauch laut dem am 4. November veröffentlichten Bericht auf Credits im rechnerischen Wert von 1.213.430 Dollar. Recherchequelle: OpenAI
Die Zahl beschreibt allerdings keine ebenso große Menge bereits ausgelieferter Reparaturen. Ebenso wenig handelt es sich um 948 unmittelbare Angriffswege aus dem Internet. Die Exploits setzen einen lokalen Zugang mit eingeschränkten Rechten voraus und könnten einem solchen Nutzer Root-Rechte verschaffen.
Die eigentliche Verschiebung liegt im Maßstab. Wenn Maschinen Sicherheitslücken nicht bloß vermuten, sondern reproduzieren und zu funktionierenden Exploits ausbauen, wächst auch die Arbeit dahinter: Funde müssen geprüft, priorisiert und in belastbare Updates überführt werden. Automatisierte Fehlersuche beschleunigt damit nicht automatisch den Schutz. Sie erhöht zunächst den Druck auf jene Prozesse, die aus einem technischen Treffer eine verlässliche Reparatur machen.
Vom Verdacht zum Root-Zugang
Ein plausibler Hinweis ist in der Sicherheitsforschung noch kein Fund. Quellcode kann verdächtig aussehen, ohne dass sich der angenommene Fehler unter realistischen Bedingungen auslösen lässt. OpenAIs Pipeline sollte diese Lücke zwischen Analyse und Nachweis systematisch schließen: Sie kombinierte die Auswahl relevanter Kernel-Bereiche mit statischer Prüfung, dynamischer Reproduktion, Bewertung der Ausnutzbarkeit, Patch-Erzeugung und einer abschließenden Kontrolle durch menschliche Sicherheitsforscher.
Den Ausgangspunkt bildeten sogenannte Scout-Agenten. Sie suchten nach Codebereichen, die für Nutzer mit geringen Rechten erreichbar und sicherheitstechnisch relevant waren. Daraus entstanden 5.034 Prüfziele mit insgesamt rund 2,8 Millionen Codezeilen. Nach Berechnung des Unternehmens entsprach das ungefähr sieben Prozent des Linux-Kernels. Sogenannte Analysten-Agenten untersuchten diese Auswahl und lieferten innerhalb von zwölf Stunden 2.308 nach Duplikatbereinigung verbliebene Verdachtsfälle.
Nun musste sich jeder Hinweis im laufenden System bewähren. Triage-Agenten entwickelten dafür Testprogramme und führten sie in isolierten virtuellen Maschinen aus. Binnen 30 Stunden konnten sie 1.724 der gemeldeten Fälle reproduzieren, rund 74,7 Prozent. Nicht jeder der übrigen Kandidaten ließ sich innerhalb des verfügbaren Zeitbudgets bestätigen. Als Hindernisse nennt OpenAI neben erforderlichen Zusatzrechten auch besondere Triggerbedingungen und Race Conditions, die nur schwer auszulösen waren. 3,1 Prozent der verbliebenen Fälle ordnet das Unternehmen einer fehlerhaften Analyse mit einer unmöglichen Annahme zu.
Damit verschob sich die Beweislast vom Text zum Verhalten. Nicht die Überzeugungskraft der Analyse entschied, sondern ein beobachtbarer Fehler im Testsystem. Erst diese Laufzeitbelege machten aus Tausenden maschinell formulierter Vermutungen eine belastbare Grundlage für die weitere Sicherheitsprüfung.
948 Schwachstellen sind noch keine 948 Reparaturen
Die zentrale Zahl ist kein Rohwert, sondern das Ergebnis einer Bereinigung. Aus 1.724 reproduzierten Schwachstellen gingen 291 Proofs of Concept für Informationslecks und 1.169 funktionierende Exploits zur lokalen Rechteausweitung hervor. Da mehrere Exploits auf Varianten derselben zugrunde liegenden Lücke beruhen konnten, untersuchte OpenAI ihre Gemeinsamkeiten. Daraus leitete das Unternehmen 948 unterschiedliche LPE-Schwachstellen mit jeweils einem Kandidaten-Patch ab.
Ein solcher Vorschlag ist jedoch noch nicht Bestandteil eines veröffentlichten Kernels. Nach der zehntägigen Kampagne wies OpenAI für 403 der 948 Fälle einen sichtbaren Bearbeitungsstand aus: 299 waren gemeldet oder Gegenstand öffentlicher Diskussionen, 43 hatten das Staging erreicht und 61 waren bereits upstream behoben. Für die übrigen Kandidaten nennt der Bericht zu diesem Zeitpunkt keinen entsprechenden Integrationsstand.
CjxkaXYgY2xhc3M9ImV4dGhvcmlhLWFtYXpvbi1hZCIgZGF0YS1leHRob3JpYS1hZC1zbG90PSIwMSIgZGF0YS1leHRob3JpYS1hZC1wcm92aWRlcj0iYW1hem9uIj48ZGl2IGNsYXNzPSJleHRob3JpYS1hbWF6b24tYWRfX21ldGEiPjxzcGFuIGNsYXNzPSJleHRob3JpYS1hbWF6b24tYWRfX2JhZGdlIj5XZXJidW5nPC9zcGFuPjxzcGFuIGNsYXNzPSJleHRob3JpYS1hbWF6b24tYWRfX3Byb3ZpZGVyIj5BbWF6b248L3NwYW4+PC9kaXY+PHN0cm9uZyBjbGFzcz0iZXh0aG9yaWEtYW1hem9uLWFkX190aXRsZSI+Q3liZXJzaWNoZXJoZWl0ICZhbXA7IEtJOiBTdHJhdGVnaWVuIHVuZCBQcmF4aXMgZsO8ciBJVC0gdW5kIFNlY3VyaXR5LVZlcmFudHdvcnRsaWNoZSAobWl0cCBQcm9mZXNzaW9uYWwpPC9zdHJvbmc+PGEgY2xhc3M9ImV4dGhvcmlhLWFtYXpvbi1hZF9fY3RhIiBocmVmPSJodHRwczovL2xpbmsuYW1hem9uL0IwNDZSRkxVMSIgdGFyZ2V0PSJfYmxhbmsiIHJlbD0ic3BvbnNvcmVkIG5vZm9sbG93IG5vb3BlbmVyIG5vcmVmZXJyZXIiIGRhdGEtZXh0aG9yaWEtbGluay1tYW5hZ2VyPSIxIiBkYXRhLWV4dGhvcmlhLWxpbmstdHlwZT0iZXh0ZXJuYWwiIGRhdGEtZXh0aG9yaWEtYWQtbGluaz0iYW1hem9uIj5CZWkgQW1hem9uIGFuc2VoZW4gPHNwYW4+KGJlemFobHRlciBMaW5rKTwvc3Bhbj48L2E+PHNtYWxsIGNsYXNzPSJleHRob3JpYS1hbWF6b24tYWRfX2Rpc2Nsb3N1cmUiPsOcYmVyIHVuc2VyZSBBbWF6b24tUGFydG5lcmxpbmtzIGVyaGFsdGVuIHdpciBiZWkgcXVhbGlmaXppZXJ0ZW4gVmVya8OkdWZlbiBlaW5lIFByb3Zpc2lvbi48L3NtYWxsPjwvZGl2Pgo=Diese Abstufungen gehören zum normalen Weg einer Kernel-Reparatur. Die Linux-Dokumentation verlangt unter anderem eine eindeutige Angabe der betroffenen Kernel-Version. Hinweise auf die vermutete Fehlerstelle, ein getesteter Patch und mögliche Gegenmaßnahmen gelten zusätzlich als besonders hilfreich. Recherchequelle: Linux Kernel Documentation
Auch das Angriffsszenario braucht eine klare Grenze. OpenAI testete in virtuellen Maschinen mit Schutzmechanismen einer üblichen Linux-Distribution, darunter SMEP, SMAP, KASLR und HARDENED_USERCOPY. Die erzeugten LPE-Exploits beginnen dennoch bei einem bereits vorhandenen, eingeschränkten lokalen Zugang; sie weisen für sich genommen keinen unmittelbaren Angriffsweg aus dem Internet nach.
Zwischen Fund und wirksamem Schutz liegen somit mehrere menschlich kontrollierte Schritte: technische Prüfung, Anpassung, Aufnahme in den Kernel und schließlich die Verteilung als Update. Die Zahl 948 beschreibt die Ausbeute der Pipeline, nicht den Stand der Absicherung auf realen Systemen.
Leistungsfähigere Modelle im Vergleich
Innerhalb weniger Monate vervielfachte sich die gemeldete Ausbeute. Im Juni 2026 kam GPT-5.5 Cyber laut OpenAI auf 24 Linux-LPE-Exploits. Bei einem weiteren Lauf Ende Juli fand GPT-5.6 Sol 166 unterschiedliche Schwachstellen dieser Art und nutzte sie aus; für den vollständigen Ablauf wies OpenAI API-Credits im rechnerischen Wert von 513.690 Dollar aus. Mitte Oktober erreichte ein neueres Modell, das der Bericht lediglich als kommende Cyber-Version bezeichnet, mit derselben grundlegenden Pipeline 948 unterschiedliche LPE-Schwachstellen. Für den API-Verbrauch wies OpenAI diesmal Credits im rechnerischen Wert von 1.213.430 Dollar aus.
Für die beiden jüngeren Kampagnen untersuchte OpenAI nach eigenen Angaben jeweils den zu diesem Zeitpunkt aktuellen Master-Zweig des Linux-Kernels. Das Unternehmen wertet den Anstieg als Hinweis darauf, dass leistungsfähigere Modelle auch in bereits geprüftem Code weitere Schwachstellen aufspüren können. Aus den veröffentlichten Angaben lässt sich jedoch nicht genau trennen, welcher Anteil des Zuwachses auf das Modell und welcher auf andere Einflüsse des Versuchs zurückgeht.
Auch die behauptete technische Neuheit bleibt zunächst eine Unternehmensangabe. In einer Stichprobe von 166 Exploits identifizierte das Team nach eigener Kenntnis mindestens zehn neue Ausnutzungstechniken. OpenAI legte sie externen Kernel-Experten vor, deren Namen der Bericht nicht nennt und denen die Verfahren ebenfalls neu gewesen seien. Angaben zu einer umfassenden unabhängigen Reproduktion enthält der Bericht nicht.
Ein früher Lauf zeigt zugleich, warum hohe Erfolgszahlen sorgfältig geprüft werden müssen. Von 200 vermeintlich gelungenen Exploits hatten 20 zwar Root-Rechte erlangt, dafür aber eine andere Zero-Day-Lücke verwendet als die jeweils zugewiesene. OpenAI verschärfte anschließend die Vorgaben und ergänzte eine unabhängige Kontrolle des tatsächlichen Angriffspfades. Ein korrektes Ergebnis belegt damit noch nicht, dass der Agent den vorgesehenen Fehler verstanden und genutzt hat. Mit der Leistung der Modelle wächst folglich auch der Aufwand, ihre Erfolge eindeutig zuzuordnen.
Was ein maschinell erzeugter Exploit kostet
OpenAI weist für die eigentliche Exploit-Entwicklung einen API-Verbrauch aus, der Credits im rechnerischen Wert von 359 Dollar pro erfolgreichem Exploit entspricht. Diese Zahl beschreibt nur einen Ausschnitt der Rechnung und nicht den gesamten Weg dorthin. Auswahl der Codebereiche, statische Suche, dynamische Validierung, Fehlversuche und Variantenanalyse erhöhten den insgesamt ausgewiesenen API-Verbrauch des Oktober-Laufs auf Credits im rechnerischen Wert von 1.213.430 Dollar. Rechnerisch entspricht das rund 1.280 Dollar je einer der 948 als unterschiedlich eingestuften LPE-Schwachstellen.
Diese Beträge lassen sich nicht ohne Weiteres auf andere Projekte übertragen. OpenAI weist darauf hin, dass sie vom Modell, der Zielkonfiguration und dem verwendeten Arbeitsablauf abhängen. Da bei dem Versuch die Messung der Fähigkeiten im Vordergrund stand und nicht eine möglichst kostengünstige Pipeline, bezeichnet das Unternehmen die ausgewiesenen Werte eher als Obergrenze.
Der Vergleich mit historischen Prämien von 20.000 bis 70.000 Dollar für einzelne Linux-LPE-Exploits soll das wirtschaftliche Verhältnis veranschaulichen. Rechnerisch ergibt das für 948 Funde 18,96 bis 66,36 Millionen Dollar, gerundet also etwa 19,0 bis 66,4 Millionen Dollar. Dabei handelt es sich weder um erzielte Einnahmen noch um einen belastbaren Marktwert, sondern um eine Modellrechnung auf Grundlage früherer Belohnungen.
Zusätzliche Vorsicht verlangt der Test in einer angepassten kernelCTF-Umgebung. Dort erzeugte die Pipeline 21 LPE-Exploits und wies dafür API-Credits im rechnerischen Wert von rund 32.936 Dollar aus. OpenAI entfernte wegen einer Inkompatibilität mit der verwendeten Kernel-Version allerdings die Schutzfunktion SLAB_VIRTUAL aus der Konfiguration. Googles reguläres kernelCTF-Ziel nutzt einen gehärteten Kernel mit verkleinerter Angriffsfläche. Eingereichte Exploits müssen außerdem über 20 Durchläufe eine Zuverlässigkeit von mindestens 70 Prozent erreichen. Recherchequelle: Google Security Research
Die 21 Ergebnisse entsprechen daher nicht 21 akzeptierten oder prämierten kernelCTF-Einreichungen. Ob KI die Sicherheitsforschung tatsächlich verbilligt, hängt auch davon ab, wie aufwendig ihre Resultate geprüft, zugeordnet und weiterbearbeitet werden müssen.
Der Engpass sitzt zwischen Fund und Update
Die Maschine beschleunigt die Suche, nimmt den Entwicklern aber nicht die Auswahl ab. Mit der Zahl bestätigter Schwachstellen wächst die Aufgabe, ihre Dringlichkeit zu bewerten, Duplikate und Varianten zu erkennen, den tatsächlichen Angriffspfad zu überprüfen und vorgeschlagene Patches auf Nebenwirkungen oder unvollständig erfasste Fehlerklassen zu untersuchen. Hinzu kommt die Abstimmung mit den zuständigen Kernel-Entwicklern. Aus technischer Ausbeute wird erst durch diese Arbeit belastbarer Schutz.
OpenAIs Bericht beschreibt damit eine hohe Skalierbarkeit innerhalb einer kontrollierten Forschungsumgebung. Er belegt nach den Messungen des Unternehmens, dass Agenten große Mengen von Code untersuchen, Fehler reproduzieren und Exploits sowie Reparaturvorschläge erzeugen können. Eine autonome Absicherung des Linux-Kernels ist daraus nicht abzuleiten.
Auch ergänzende Forschung zur automatisierten Linux-Rechteausweitung warnt vor einfachen Verallgemeinerungen. Der dort verwendete Benchmark macht deutlich, dass die Ergebnisse nicht allein vom eingesetzten Sprachmodell abhängen. Je nach Schwachstellenklasse veränderte sich der Modellvergleich, während Eingriffe in die Systemumgebung einen Teil der erfolgreichen Angriffe störten, das gemessene Risiko aber nicht vollständig beseitigten. Auch der gewählte Agentenrahmen wirkte sich sowohl auf die Erfolgsquote als auch auf die Rangfolge der sechs untersuchten Sprachmodelle aus. Diese Untersuchung bestätigt OpenAIs konkrete Ergebnisse nicht, zeigt aber, wie stark solche Fähigkeiten vom Versuchsaufbau abhängen können. Recherchequelle: arXiv
Linux ist durch den Bericht nicht plötzlich 948-mal unsicherer geworden. Verändert hat sich das Tempo, in dem bestätigte Angriffspfade entstehen können. Ob daraus mehr Sicherheit folgt, entscheidet sich zwischen Fund und Update: bei geprüften Patches, ihrer Aufnahme in den Code und ihrer tatsächlichen Verteilung auf reale Systeme.
Weiterführende Informationen
Quellenhinweis: Einzelne Fakten, Einschätzungen und Prognosen dieses Beitrags stützen sich auf Veröffentlichungen der nachfolgend genannten Unternehmen und Institutionen. Die Links dienen zugleich der weiterführenden Information.
KI Spotlight – OpenAI meldet 948 Linux-Root-Exploits aus einem Lauf für 1,2 Millionen Dollar
Der Beitrag erläutert die fünf Pipeline-Stufen und den Weg von 5.034 Prüfzielen über 1.724 reproduzierte Fälle und 1.169 Exploits zu 948 unterschiedlichen Schwachstellen.
https://kispotlight.de/artikel/openai-meldet-948-linux-root-exploits-aus-einem-lauf-fuer-1-2-millionen-dollar
Pasquale Pillitteri – OpenAI enthüllt 948 Root-Lücken im Linux-Kernel für 1,2 Millionen Dollar
Der Artikel unterscheidet Patch-Kandidaten von übernommenen Reparaturen und dokumentiert 299 diskutierte, 43 vorbereitete und 61 upstream behobene Fälle.
https://pasqualepillitteri.it/de/news/30261/openai-948-root-luecken-linux-kernel
Unite.AI – OpenAI-Pipeline findet 948 Schwachstellen zur Rechteausweitung im Linux-Kernel
Der Beitrag ordnet die 21 kernelCTF-Exploits anhand der entfernten SLAB_VIRTUAL-Härtung sowie der Anforderungen an Zero-Day-Status und Zuverlässigkeit ein.
https://www.unite.ai/de/openai-pipeline-finds-948-linux-kernel-privilege-escalation-flaws/



