Naar de inhoud
NLEN
Illustratie: OpenAI-pijplijn vond 948 Linux-rootlekken in één run: wat autonome bugjacht betekent

OpenAI-pijplijn vond 948 Linux-rootlekken in één run: wat autonome bugjacht betekent

Door Ivo Donker · — samengesteld met AI-ondersteuning (DeepSeek V4.1 Flash)

Op 4 november 2026 publiceerde OpenAI 'A thousand fewer paths to root': een prototype van een autonome pijplijn die kwetsbaarheden vindt, valideert, beoordeelt en van kandidaat-patches voorziet. De pijplijn draaide in een gecontroleerde onderzoeksomgeving en wordt aangedreven door een aankomend cybermodel dat OpenAI niet publiek heeft uitgebracht; er is geen productnaam en geen beschikbaarheid. In één run, halverwege oktober 2026, valideerde en voorzag het prototype 948 local privilege escalation (LPE)-kwetsbaarheden in de Linux-kernel van kandidaat-patches, tegen een API-kostprijs van ongeveer $1,2 miljoen.

De vraag die veel beheerders stellen is de juiste: word je systeem hier veiliger of juist kwetsbaarder van? Het antwoord is beide, en het onderscheid zit in wat er daadwerkelijk is gepatcht. OpenAI heeft niet 948 patches in de kernel gemerged. Het leverde kandidaat-patches op, met menselijke review, die via Patch the Planet en partners naar maintainers gaan. In de momentopname na 10 dagen waren 61 LPE's al upstream gepatcht, hadden 43 er staging-patches en waren 299 publiek gemeld en in discussie bij maintainers en de bredere securitycommunity. Voor je eigen systemen geldt daarom hetzelfde als altijd: wat in je updatekanaal zit, is wat telt.

Wat OpenAI heeft gedaan

OpenAI bouwde een prototype-pijplijn die het volledige traject van vondst tot rapport aflegt, maar wel met een mens in de lus. De run vond plaats op de laatste Linux-kernel (de master-branch op dat moment). De doel-VM's draaiden een standaard desktop-besturingssysteem van een veelgebruikte Linux-distributie, dus geen verzwakt doel: de beschermingen van een normale distributie stonden aan, waaronder SMEP, SMAP, KASLR en HARDENED_USERCOPY. OpenAI zegt hetzelfde dreigingsmodel te hanteren als wedstrijden zoals Pwn2Own en TyphoonPWN.

Dat detail is relevant voor de vraag of dit iets over de praktijk zegt. Een gehardende kernel met standaardbeschermingen is precies de omgeving die je op servers en in de cloud tegenkomt. Wie de bredere ontwikkeling van AI in dit domein wil volgen, vindt achtergrond in het dossier over AI en cybersecurity, waar de verschuiving van detectie naar autonome analyse centraal staat. Deze publicatie past in dat beeld, maar met een belangrijke beperking: het gaat om onderzoek in een gecontroleerde omgeving, niet om een dienst die je vandaag kunt inhuren.

Het model achter de pijplijn is aankomend en niet publiek. OpenAI noemt geen productnaam en geeft geen releasedatum. Wat er wel ligt, is een beschrijving van de opzet, de aantallen en de kosten. De technische details van de gebruikte exploitietechnieken heeft OpenAI bewust weggelaten.

De pijplijn in vijf stappen (op hoofdlijnen)

OpenAI beschrijft vijf stappen. Ten eerste het vinden van kwetsbaarheden: agents identificeren security-relevante delen van de code en scannen die op kandidaat-bevindingen. Ten tweede dynamische validatie: agents proberen elke kandidaat in een geïsoleerde omgeving te reproduceren. Ten derde de beoordeling van exploiteerbaarheid: leidt de bug tot informatielekken of tot lokale privilege-escalatie? Ten vierde het genereren van een patch. Ten vijfde menselijke review: securityonderzoekers beoordelen exploit, patch en voorgestelde ernst voordat er iets naar maintainers gaat.

Per bevinding levert de pijplijn een bundel op met een root cause-analyse, een minimale crashing proof of concept, een kandidaat-patch en een volledige exploit, zodat menselijke onderzoekers de ernst en de upstream-fix kunnen beoordelen. Die exploits worden niet gepubliceerd. De isolatie waarin de validatie plaatsvindt, is een onderwerp op zichzelf; achtergrond over het scheiden van uitvoerende modellen en hun werkomgeving staat in het stuk over sandboxing en isolatie van LLM-tools in de praktijk. Dat is precies het soort maatregel dat bepaalt of een dergelijke pijplijn beheersbaar blijft.

Belangrijk voor de interpretatie: de pijplijn is een prototype in een onderzoeksopstelling. De stappen zijn hier op hoofdlijnen beschreven, zonder de gebruikte technieken, de kwetsbare objecten of manieren om mitigaties te omzeilen. Dat is een bewuste keuze van OpenAI en van deze redactie.

De cijfers: van 2.308 kandidaten naar 948 unieke LPE's

De trechter is het meest concrete deel van de publicatie. Na deduplicatie bleven 2.308 kandidaat-bevindingen over. Daarvan werden 1.724 kwetsbaarheden dynamisch gereproduceerd, ongeveer 74,7%. Die validatiestap rondde de reproductie af binnen 30 uur; die 30 uur geldt dus alleen voor de validatiefase, niet voor de hele pijplijn. Slechts 3,1% van de kandidaten bleek op een onjuiste analyse van het model te berusten, aldus OpenAI.

Vervolgens leidde dat tot 291 proof of concepts voor informatielekken en 1.169 werkende LPE-exploits. Na variantanalyse bleven daar 948 verschillende patches uit over; OpenAI gebruikt 948 als het aantal unieke LPE's. Het onderscheid tussen 1.169 en 948 is geen detail: 1.169 zijn de ruwe, werkende exploits, 948 is het aantal unieke kwetsbaarheden nadat varianten zijn samengevoegd.

FaseAantalToelichting
Kandidaat-bevindingen2.308Na deduplicatie
Dynamisch gereproduceerd1.724Ongeveer 74,7%; validatiestap rondde dit af binnen 30 uur
Informatielek-PoC's291Proof of concepts voor informatielekken
Werkende LPE-exploits1.169Ruwe, werkende exploits voor lokale privilege-escalatie
Unieke LPE's na variantanalyse948Het aantal dat OpenAI als unieke LPE's hanteert

Wat LPE precies betekent, is voor de risicobeoordeling essentieel. Bij local privilege escalation krijgt een lokale gebruiker zonder privileges root. Daarvoor is lokale toegang nodig, dus een account op het systeem. Het is op zichzelf geen aanval op afstand. Dat nuanceert de kop 'honderden rootlekken', maar maakt ze niet onschuldig: op een meergebruikerssysteem, in een container of op een machine waar een aanvaller al een laag-geprivilegieerde positie heeft, is dit het verschil tussen vastzitten en doorkunnen.

Wat de run kostte

De totale run kostte $1.213.430 aan API-credits, ongeveer $1,2 miljoen, ofwel $1.279 per LPE-exploit. OpenAI noemt de gerapporteerde kosten eerder een bovengrens; verbeteringen in de harness-engineering kunnen ze volgens het bedrijf verlagen.

Ter vergelijking noemt OpenAI een aparte zijrun in het kernelCTF-programma van Google, op een gehardende kernel met een verkleind aanvalsoppervlak: 25 proof of concepts voor informatielekken en 21 LPE-exploits, tegen een campagnekostprijs van ongeveer $32.936 aan API-credits. Die zijrun laat zien dat de opbrengst sterk afhangt van het doel en de opzet.

Voor securityteams is het kostenplaatje vooral een signaal over schaal. Handmatig onderzoek naar kernelkwetsbaarheden is arbeidsintensief en specialisten zijn schaars. Als een geautomatiseerde pijplijn tegen een bekende prijs per bevinding honderden kandidaten oplevert, verschuift de bottleneck naar review, rapportage en patching. Wie wil inschatten welke tools of modellen in dat proces passen, kan de vergelijking in de keuzegids voor AI-modellen in cyberbeveiliging en code-audits gebruiken; de vraag is daar niet 'het slimste model', maar 'het model met de juiste review- en validatielus'.

Kandidaat-patches en wat upstream echt gebeurde

De patches die de pijplijn oplevert zijn kandidaat-patches, bedoeld voor review door maintainers. Menselijke onderzoekers hebben de output beoordeeld. OpenAI volgde de richtlijn van de Linux-kernelgemeenschap om bij kritieke kwetsbaarheden te beginnen, zegt al honderden rapporten en patches voor kritieke kwetsbaarheden te hebben verstuurd, en werkt met Patch the Planet-partners om de rest geleidelijk te verspreiden. Dit maakt deel uit van OpenAI's Daybreak-toezegging. Wat OpenAI niet heeft gedaan: 948 patches in de kernel mergen. Dat onderscheid moet je vasthouden, want het bepaalt of jouw systeem al beschermd is.

De momentopname na 10 dagen, toen de autonome scan en de handmatige analyse klaar waren, geeft het eerlijkste beeld van de upstream-stand: 61 LPE's waren al upstream gepatcht, 43 hadden staging-patches en 299 werden publiek gemeld en besproken. Dat gebeurde door Linux-maintainers en de bredere securitycommunity, niet doordat OpenAI iets heeft samengevoegd. OpenAI bedankt de maintainers en benadrukt software up to date te houden.

Dat is de kern van het antwoord op de vraag of je nu veiliger bent. De 61 upstream-patches zijn concreet: als jouw distributie ze heeft opgenomen, ben je voor die gevallen beschermd. De 43 met staging-patches zijn onderweg. De 299 die publiek gemeld en besproken zijn, vragen om opvolging in je patchproces. De rest is nog in rapportage of review. Je veiligheid hangt dus af van je updatebeleid, niet van de publicatie zelf.

Eerdere runs: van 24 naar 166 naar 948

De reeks eerdere runs maakt de ontwikkeling zichtbaar zonder dat er iets speculatiefs nodig is. In juni 2026 deelde OpenAI, als onderdeel van Patch the Planet, dat GPT-5.5 Cyber Linux-kernelkwetsbaarheden had gevonden en 24 LPE-exploits had ontwikkeld om ze te valideren en te rapporteren. Eind juli 2026 vond en exploiteerde GPT-5.6 Sol 166 unieke LPE's, end-to-end voor $513.690. De run van half oktober met het nieuwere cybermodel vond meer dan vijf keer zoveel nieuwe LPE's, ondanks drie maanden van hardening.

Die vergelijking is de moeite waard voor iedereen die een meerjarenplan voor vulnerability management maakt. De opbrengst per run groeit, en de tegenkracht van hardening vertaalt zich niet automatisch in minder bevindingen. Voor bouwers betekent dat: code-audit en patchsnelheid worden belangrijker, niet minder. Wie de red-teamkant van dit soort modellen wil wegen, vindt een kader in het overzicht van red teaming en veiligheidstests; het helpt om claims over 'autonoom vinden' te toetsen aan een meetbare opzet.

Dual-use: verdediging met een scherpe rand

OpenAI presenteert de publicatie defensief. De missie van het Cyber-team is volgens het bedrijf om software waar de wereld van afhankelijk is veiliger te maken, verdedigers te helpen kwetsbaarheden te vinden en te verhelpen, en de kosten voor aanvallers te verhogen. Via Patch the Planet, een Daybreak-initiatief, wil OpenAI dit uitbreiden naar meer kritieke softwareprojecten, samen met maintainers en securitypartners. De keuze voor Linux is goed te begrijpen: het ligt onder Android, cloudinfrastructuur en supercomputers, en omvat meer dan 40 miljoen regels code.

Tegelijk is dit dual-use in de praktijk. Dezelfde pijplijn die verdedigers sneller aan fixes helpt, demonstreert dat een goed gefinancierde partij op schaal lokale escalatiepaden kan vinden. OpenAI noemt in een steekproef van 166 exploits minstens 10 nieuwe exploitietechnieken, door externe kernel-exploitatie-experts bevestigd als nieuw. Om veiligheidsredenen laat OpenAI de technische details weg. Die keuze is verstandig en moet ook zo blijven: de details zijn niet nodig om je systemen te beschermen, en wel bruikbaar voor wie kwaad wil.

Bij de waardering past één harde voorwaarde: wat OpenAI presenteert is een hypothetische waardering, door OpenAI zelf opgesteld. Als je historische bountybedragen voor Linux-kernel-LPE's uit Pwn2Own ($20.000) en TyphoonPWN ($70.000) op de 948 exploits toepast, kom je op een hypothetisch bedrag van $18,9 miljoen tot $66,3 miljoen, ruwweg 16 tot 55 keer de kostprijs van de pijplijn. Dat is een rekenexercitie, geen marktwaarde en geen bewezen businesscase. Behandel het als zodanig.

Deze publicatie komt in een drukke week. Eerder deze week waren er OpenAI's securitysprint en de verhoogde bug bounties, waarmee OpenAI eerder ook al op security inzette. Ook speelden CrowdStrike's AI-overnames en de Kill Switch-discussie deze week, wat laat zien dat de vraag 'wie beheerst het AI-gereedschap in de beveiligingsketen' breder speelt dan één vendor. Voor teams die dit soort ontwikkelingen willen bijhouden naast hun eigen detectie- en responsproces, is er het overzicht van AI-tools voor cybersecurity en het SOC. En wie liever lokaal en gecontroleerd experimenteert met modelondersteuning, kan beginnen bij een lokale LLM op Linux draaien. Voor organisaties die hulp zoeken bij het inrichten van dit soort processen, bestaat er een overzicht van bedrijven die helpen met AI-security.

Wat dit artikel bewust niet claimt of uitlegt

Wat dit betekent voor Linux-beheerders en bouwers

OpenAI trekt zelf een aantal lessen die voor beheerders direct bruikbaar zijn. De eerste: verifieer het pad naar een resultaat, niet alleen het resultaat. In een vroege run bereikten 20 van de 200 gerapporteerde exploits root via een andere 0-day dan waaraan ze waren toegewezen; OpenAI voegde daarop een onafhankelijke controle toe. Voor je eigen proces betekent dat: een geslaagde test of scan is pas bruikbaar als je begrijpt via welke weg het resultaat tot stand kwam.

De tweede les is het hervalideren van bevindingen tegen de laatste code, om dubbele rapporten te voorkomen, en het opnieuw scannen van code naarmate modellen beter worden. In de praktijk vertaalt dat zich naar een ritme waarin je niet één keer per jaar kijkt, maar periodiek opnieuw toetst tegen de versie die je daadwerkelijk draait.

De derde les is de meest confronterende. Voor de nabije en middellange termijn moet je volgens OpenAI een laag-geprivilegieerd account op een systeem dat niet up to date is met patches, functioneel gelijkstellen aan root voor een goed gefinancierde aanvaller. Dat is geen reden tot paniek, wel een reden om least privilege en patchdiscipline serieus te nemen. In multi-useromgevingen en containers betekent dat concreet: beperk wie een account krijgt, scheid workloadtaken, en ga ervan uit dat een gecompromitteerde laag-geprivilegieerde positie een opstap kan zijn.

De vierde les is defense in depth met sandboxes en isolatie, zoals Firecracker en gVisor, om de blast radius te beperken. Dat sluit aan bij wat je in elke serieuze containeromgeving al zou willen: niet vertrouwen op één grens, maar op meerdere. Als toekomstig onderzoek noemt OpenAI modellen die standaard veilige code schrijven, het verkleinen van het aanvalsoppervlak en formele verificatie. Dat zijn richtingen, geen beloftes met een datum.

Voor beheerders is de praktische conclusie saai en belangrijk: de waarde van deze publicatie zit niet in de kop, maar in de 61 upstream-patches, de 43 staging-patches en de 299 meldingen die al in beweging zijn. Wat jij doet met je updatevenster bepaalt of jouw systemen meeprofiteren.

Praktische checklist

De publicatie van 4 november 2026 laat vooral zien dat de productiekant van vulnerability research opschuift: niet alleen sneller vinden, maar ook valideren, beoordelen en van een kandidaat-patch voorzien, met een mens die de laatste stem heeft. Dat is een relevante ontwikkeling voor iedereen die Linux draait, maar het verandert niets aan de basisregel. Je systemen worden niet veiliger van een artikel, wel van patches die je daadwerkelijk installeert.

De eerlijke samenvatting is daarom tweeledig. Ja, dit soort pijplijnen kan het vinden van kwetsbaarheden versnellen en daarmee de verdediging helpen, mits rapportage en review op orde zijn. En ja, het maakt zichtbaar dat een goed gefinancierde aanvaller met vergelijkbare middelen op schaal naar lokale escalatiepaden kan zoeken. De maatregelen die daar tegen werken zijn niet nieuw: patchen, updaten, isoleren en rechten beperken. Wie dat consequent doet, heeft aan deze publicatie vooral een argument voor een strakker patchproces.

Gecontroleerd op 2026-11-05.

Dit bericht is samengesteld met AI-ondersteuning en redactioneel gecontroleerd; bronnen staan hieronder.

Lees ook: ChatGPT Images 2.6: GIF's, referentiebeelden en Flare/Sunburst

Bronnen