Duizend minder wegen naar root
We ontwikkelden een autonome pipeline voor het opsporen, misbruiken en patchen van kwetsbaarheden. Eén run met ons cybermodel valideerde 948 Linux-kwetsbaarheden voor lokale privilege-escalatie en genereerde patches voor $ 1,2 miljoen aan API-kosten.
Beveiligingsonderzoek dat voorheen voor elke bevinding een afzonderlijk, langdurig onderzoek vereiste, kan steeds vaker als een systematisch proces worden uitgevoerd. Dit document gaat in op een van onze projecten op dit gebied.
Het opsporen van kwetsbaarheden wordt gemakkelijker op te schalen, maar prioritering en validatie blijven operationele knelpunten. We bouwden een prototype om binnen een gecontroleerde onderzoeksomgeving naar beveiligingsproblemen in de Linux-kernel te zoeken. Ons prototype identificeerde en analyseerde 2.308 voorlopige bevindingen in de Linux-kernel, reproduceerde dynamisch 1.724 kwetsbaarheden en maakte 948 exploits voor lokale privilege-escalatie (LPE) waarmee een lokale gebruiker zonder verhoogde rechten roottoegang zou kunnen krijgen.
We gebruikten dit bewijs om te bepalen welke kwetsbaarheden we als eerste moesten melden en ontwikkelden voorgestelde patches ter beoordeling door de beheerders. Op advies van de Linux-kernelgemeenschap begonnen we met kritieke kwetsbaarheden. We werken samen met Patch the Planet-partners aan verdere rapporten en patches.
In juni deelden we als onderdeel van ons Patch the Planet-initiatief dat GPT‑5.5 Cyber kwetsbaarheden in de Linux-kernel had gevonden en 24 exploits voor lokale privilege-escalatie had ontwikkeld om deze te valideren en te melden. We breidden dat werk uit tot een pipeline op basis van een aankomend cybermodel, voor het opsporen van kwetsbaarheden, dynamische validatie, het beoordelen van misbruikbaarheid en het genereren van patches. Na afloop beoordeelden menselijke onderzoekers de resultaten en meldden ze de gevonden kwetsbaarheden samen met patches.
Samenvatting
Methodologie
In grote lijnen werkt onze pipeline als volgt: eerst identificeert deze beveiligingsrelevante onderdelen van de Linux-kernel en scant die auditdoelen statisch op mogelijke kwetsbaarheden. Vervolgens reproduceert de pipeline deze bevindingen dynamisch in een geïsoleerde omgeving, maakt een proof-of-concept-exploit (PoC) om de misbruikbaarheid aan te tonen en genereert patches. Tot slot beoordeelt een menselijke beveiligingsonderzoeker de resultaten.
De pipeline levert een analyse van de hoofdoorzaak, een minimale proof of concept die een crash veroorzaakt, een voorgestelde patch en een volledige exploit. Daarmee kunnen menselijke onderzoekers de ernst van de kwetsbaarheid beoordelen en de fixes in het oorspronkelijke project laten opnemen.
Bevindingen
Tijdens een run medio oktober 2026 reproduceerde onze pipeline met een aankomend cybermodel dynamisch 1.724 kwetsbaarheden en genereerde deze PoC's voor 291 kwetsbaarheden die informatie lekken en 948 werkende exploits voor lokale privilege-escalatie (LPE) voor een veelgebruikte Linux-distributie. De volledige run kostte $ 1.213.430 aan API-credits, oftewel $ 1.279 per LPE-exploit.
De virtuele doelmachines draaiden een standaard desktopbesturingssysteem, geen verzwakt doelsysteem, met hetzelfde dreigingsmodel als bij cyberbeveiligingswedstrijden (zoals Pwn2Own(opent in een nieuw venster) en TyphoonPWN(opent in een nieuw venster)). Pwn2Own en TyphoonPWN boden eerder bugbounty's van respectievelijk $ 20.000 en $ 70.000 voor LPE-exploits in de Linux-kernel. Als we die eerdere bountybedragen toepassen op de 948 exploits, levert dat een hypothetische waarde op van $ 18,9 miljoen tot $ 66,3 miljoen, ongeveer 16 tot 55 keer de kosten van onze pipeline.
In een aangepaste kernelCTF(opent in een nieuw venster)-omgeving, een versie van de Linux-kernel met een kleiner aanvalsoppervlak, leverde onze pipeline 25 PoC's voor informatielekken en 21 LPE-exploits op. Ter vergelijking: op het moment van schrijven heeft kernelCTF in 2026 26 bevestigde zero-day-LPE-exploits geaccepteerd.
De campagne kostte ongeveer $ 32.936 aan API-credits. Als de 21 kwetsbaarheden door het programma werden geaccepteerd, zou dat ongeveer $ 1,5 miljoen aan bounty's opleveren, circa 45 keer de scankosten.
Voor zover wij weten, hebben de agents in deze pipeline minstens 10 nieuwe exploitatietechnieken voor Linux ontdekt en gebruikt.
Beschouwingen
De Linux-beheerders en de beveiligingsgemeenschap werken hard om kwetsbaarheden snel op te sporen en te verhelpen. Binnen 10 dagen, terwijl de scan liep, zagen we dat ruim 100 Linux-LPE's al waren gepatcht of dat andere bijdragers er patches voor hadden klaargezet. Nog eens circa 300 werden openbaar besproken.
Gezien het tempo waarin grensverleggende modellen kwetsbaarheden ontdekken, denken we dat het automatisch genereren van patches essentieel is om software snel genoeg te beveiligen en de periode waarin misbruik mogelijk is te beperken. We denken dat door AI gegenereerde patches, met iteratieve verbeteringen onder begeleiding van menselijke experts, functioneel correct kunnen zijn, kunnen aansluiten bij bestaande codeerstijlen en bestand kunnen zijn tegen aanvalsvarianten. Dit is een belangrijk onderwerp voor verder onderzoek.
Capabelere modellen kunnen nieuwe kwetsbaarheden in bestaande code ontdekken, vaak ook kwetsbaarheden die al langer aanwezig zijn en moeilijker te herkennen zijn. Onze analysepipeline met het nieuwere cybermodel ontdekte medio oktober >5 keer zoveel nieuwe LPE's als een run met GPT‑5.6 Sol in juli, ondanks drie maanden aan beveiligingsverbeteringen tussen de scans.
Grote, complexe softwareprojecten hebben waarschijnlijk meerdere rondes van scannen en verhelpen nodig om de resterende verborgen bugs op te sporen en te verhelpen. Idealiter wordt dit proces herhaald met elke volgende generatie grensverleggende modellen. Dit geldt zowel voor propriëtaire als voor opensourcesoftware.
Op de korte en middellange termijn moet toegang tot een account met beperkte rechten op een besturingssysteem zonder de nieuwste beschikbare patches voor een aanvaller met ruime middelen als functioneel gelijkwaardig aan roottoegang worden beschouwd. Gelaagde verdediging met sandboxes en isolatietechnieken zoals Firecracker en gVisor is belangrijk om de impact van misbruikte kwetsbaarheden te beperken.
We denken dat grensverleggende modellen binnen enkele jaren waarschijnlijk in staat zullen zijn om aanwezige kwetsbaarheden in een softwareproject te ontdekken. Na openbaarmaking kunnen mogelijk zelfs minder capabele modellen er exploits voor ontwikkelen. In een wereld zonder onbekende kwetsbaarheden is het cruciaal om software met sterke veiligheidsgaranties te bouwen en te onderhouden, vooral kernsoftware zoals besturingssystemen, browsers, bibliotheken voor het verwerken van afbeeldingen en de TCP/IP-stack. Naast het opsporen en verhelpen van bestaande kwetsbaarheden zijn er veelbelovende onderzoeksrichtingen om softwarebeveiliging effectief op te schalen: modellen trainen om standaard veilige code te schrijven, het aanvalsoppervlak verkleinen door onnodige functies te verwijderen en formele verificatie toepassen.
De Linux-kernel vormt de basis van Android-apparaten, cloudinfrastructuur, supercomputers en andere systemen die door miljarden mensen worden gebruikt. Met meer dan 40 miljoen regels code biedt de kernel een breed aanvalsoppervlak via systeemaanroepen, netwerkfuncties, bestandssystemen en apparaatstuurprogramma's. We kozen Linux om te onderzoeken hoe effectief grensverleggende modellen kwetsbaarheden konden vinden en hun beveiligingsimpact konden aantonen in een codebase van deze omvang en dit belang.
De eerste opsporingsfase leverde duizenden voorlopige bevindingen op, te veel voor beveiligingsonderzoekers om handmatig te beoordelen en te prioriteren. De operationele uitdaging van onze opsporingspipeline was niet het vinden van kwetsbaarheden, maar bepalen welke bevindingen reproduceerbaar waren, welke beveiligingsgrens ze doorbraken en welke als eerste de aandacht van beheerders verdienden.
De missie van het Cyber-team van OpenAI is om de software te helpen beveiligen waarop de wereld vertrouwt. We vermelden de API-kosten per fase, zodat onderzoekers kunnen inschatten welke middelen nodig zijn om dit werk te reproduceren en uit te breiden. Deze kosten horen bij de modellen, doelconfiguraties en workflow die in deze evaluatie zijn gebruikt. Ons bredere doel is om verdedigers te helpen kwetsbaarheden op te sporen en te verhelpen, zodat aanvallers minder mogelijkheden krijgen en meer moeten betalen om software te misbruiken.
Tot slot: in dit onderzoek richtten we ons op methodologie en het meten van modelcapaciteiten, niet op kosten. We verwachten dat voldoende doorontwikkeling van de harness de kosten in elke fase aanzienlijk kan verlagen. De gerapporteerde kosten zijn daarom eerder een bovengrens.
Ons prototype voor kwetsbaarheidsonderzoek is een pipeline met vijf fasen, met een aankomend cybermodel als kern:
Kwetsbaarheden opsporen: Agents identificeren beveiligingsrelevante onderdelen van de codebase en scannen ze op mogelijke kwetsbaarheden.
Dynamische validatie: Agents proberen elke mogelijke kwetsbaarheid in een geïsoleerde omgeving te reproduceren en bewaren bewijs uit de uitvoering. Deze stap levert de gereproduceerde en gevalideerde kwetsbaarheden op.
Misbruikbaarheid beoordelen: Agents testen of gevalideerde kwetsbaarheden informatielekken of lokale privilege-escalatie mogelijk maken.
Patches genereren: Agents genereren patches die elke gevonden kwetsbaarheid verhelpen.
Menselijke beoordeling: Beveiligingsonderzoekers beoordelen de exploit, de patch en de voorgestelde ernstclassificatie voordat ze de kwetsbaarheid aan de beheerders melden.
Aan het einde van de pipeline bundelt het systeem een analyse van de hoofdoorzaak, een minimale proof of concept die een crash veroorzaakt, een voorgestelde patch en een volledige exploit. Daarmee kunnen menselijke onderzoekers de ernst van de kwetsbaarheid beoordelen en de fixes in het oorspronkelijke project laten opnemen.
Niet elke regel code in de Linux-kernel is relevant voor de beveiliging. Onze pipeline gebruikte een team van verkenningsagents om kansrijke auditdoelen te identificeren. Deze werden vervolgens doorgegeven aan analyseagents om op kwetsbaarheden te scannen.
Verkenningsagents doorlopen elke map en elk bestand en bepalen welke doelen ze moeten onderzoeken op basis van bereikbaarheid voor gebruikers met beperkte rechten en relevantie voor de beveiliging.
Deze fase leverde 5.034 auditdoelen op, samen ongeveer 2,8 miljoen regels code. Dat is circa 7% van de volledige codebase van de Linux-kernel, wat de kosten van de beveiligingsaudit aanzienlijk verlaagde ten opzichte van een analyse van de hele codebase. Deze stap kostte $ 3.426 aan API-credits.
Vervolgens analyseerden analyseagents elk auditdoel en leverden ze voorlopige bevindingen op, met een workflow die vergelijkbaar is met die van de Codex Security-plug-in(opent in een nieuw venster). In grote lijnen lezen de analyseagents de code van het toegewezen auditdoel om de werking te begrijpen, het dreigingsmodel vast te stellen en naar kwetsbaarheden te zoeken.
Binnen 12 uur leverden de analyseagents 2.308 voorlopige bevindingen op, na verwijdering van duplicaten. Deze fase kostte $ 316.549 aan API-credits.
Een voorlopige bevinding is niet hetzelfde als een gevalideerde kwetsbaarheid. Op deze schaal is het voor ons onderzoeksteam niet haalbaar om elk rapport handmatig te onderzoeken.
Daarom richtten we ons op het valideren van bevindingen die a) bereikbaar waren voor een gebruiker met beperkte rechten, b) geen speciale bevoegdheden vereisten en c) meetbaar bewijs van geheugencorruptie opleverden.
Voor elke mogelijke kwetsbaarheid genereerde een triageagent een proof of concept en voerde deze uit in een geïsoleerde virtuele machine met een Linux-kernel met Kernel Address Sanitizer (KASAN). De agent observeerde zowel de programma-uitvoer als de systeemconsole en verfijnde de proof of concept vervolgens iteratief, totdat het gemelde gedrag werd gereproduceerd of alle mogelijke manieren om het uit te lokken waren uitgeput.
Binnen 30 uur reproduceerde ons systeem 1.724 kwetsbaarheden, circa 74,7% van de 2.308 voorlopige bevindingen. Alleen statische codebeoordeling kan foutpositieven opleveren. We waren daarom onder de indruk van de nauwkeurigheid van de analyseagents en van hoe effectief de triageagents zelfstandig werkende proofs of concept maakten voor bijna driekwart van de voorlopige bevindingen.
De meeste overige bevindingen vereisten verhoogde rechten of konden niet binnen de beschikbare tijd worden gereproduceerd door lastige racecondities, specifieke voorwaarden om ze te activeren (zoals een vereiste allocatiefout op een specifieke regel) of tijdrovende validatie (zoals het omlopen van een referentieteller). Slechts 3,1% berustte op een onjuiste analyse door het model, waarbij de gemelde kwetsbaarheid uitging van een onmogelijke situatie.
De validatiefase kostte in totaal $ 73.330 aan API-credits. In onze validatiepipeline moest een proof of concept worden gegenereerd om te bevestigen of een bevinding een echte kwetsbaarheid was. We zagen dat dit duurder was dan een aanbeveling op basis van uitsluitend statische analyse, en dat pogingen om terecht positieve en foutpositieve bevindingen te valideren ongeveer evenveel kostten. Door foutpositieven eerder uit de pipeline te filteren, wordt het proces dus aanzienlijk kostenefficiënter.
Validatie stelt vast dat een kwetsbaarheid echt is, maar niet hoe dringend die moet worden aangepakt. Een kwetsbaarheid die lokale privilege-escalatie mogelijk maakt, verdient bijvoorbeeld meer prioriteit dan een kwetsbaarheid die alleen een lokale denial-of-service kan veroorzaken. Met 1.724 gevalideerde kwetsbaarheden was de volgende taak om de bevindingen met de grootste potentiële beveiligingsimpact te identificeren.
Een agent voor de eerste screening beoordeelde elk rapport, crashlogboek en relevant stuk broncode statisch. De agent hanteerde bewust ruime criteria om mogelijk ernstige bevindingen niet uit te sluiten, maar filterde gevallen zonder plausibele exploitatieroute wel weg. Hierdoor werden de resultaten teruggebracht tot 313 mogelijke informatielekken en 1.238 mogelijke kwetsbaarheden voor lokale privilege-escalatie.
Agents voor exploitontwikkeling (ExploitDev) testten deze mogelijke kwetsbaarheden vervolgens in geïsoleerde virtuele machines, met de beveiligingsmaatregelen van een standaard Linux-distributie ingeschakeld, waaronder Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) en HARDENED_USERCOPY. Dit hielp onrealistische beoordelingen te voorkomen die afhankelijk waren van uitgeschakelde beveiligingsmaatregelen.
De agents maakten 291 proofs of concept voor informatielekken en 1.169 werkende exploits voor lokale privilege-escalatie die lokale gebruikers zonder verhoogde rechten roottoegang konden geven.
We voerden een variantenanalyse uit en ontwikkelden 948 afzonderlijke patches voor de kwetsbaarheden achter die exploits. We gebruiken dat aantal om het totale aantal unieke LPE's te bepalen. Het ontwikkelen van een succesvolle exploit kostte gemiddeld $ 359 aan credits. Daardoor kunnen verdedigers relatief goedkoop testen of gevonden kwetsbaarheden misbruikbaar zijn.
De agent voor de eerste screening van kwetsbaarheden kostte $ 44.194 aan API-credits. De exploitatiefase kostte in totaal $ 775.929 aan API-credits: $ 84.929 voor het verwerken van mogelijke informatielekken en $ 691.000 voor mogelijke kwetsbaarheden voor lokale privilege-escalatie.
Gemiddeld was het verwerken van een mogelijke kwetsbaarheid voor lokale privilege-escalatie ($ 558) ongeveer twee keer zo duur als het verwerken van een mogelijk informatielek ($ 271). Dat komt doordat PoC's voor informatielekken werden overgenomen uit de validatiefase en minder aanpassingen nodig hadden om bruikbaar te worden in een exploit. Het ontwikkelen van een exploit voor een mogelijke LPE-kwetsbaarheid vereiste daarentegen veel extra stappen, zoals het plannen van een exploitatiestrategie, het identificeren van bruikbare kwetsbare objecten en het omzeilen van beveiligingsmaatregelen. We zagen ook dat mislukte exploitatiepogingen ($ 3.922 voor 69 gevallen) veel meer kostten dan succesvolle pogingen ($ 360 voor 1.169 gevallen). Dit kwam door enkele moeilijk te misbruiken kwetsbaarheden, zoals racecondities. Een redelijk stopcriterium, zoals een poging afbreken na een uur zonder vooruitgang, zou de kosten van ExploitDev aanzienlijk hebben verlaagd.
Voor elke gevalideerde kwetsbaarheid genereert het systeem ook een patch. We geven het model de relevante broncode en instructies met best practices voor het schrijven van patches: statische controles op de patch uitvoeren, de ontwikkelpraktijken van de omliggende code volgen en een variantenanalyse uitvoeren om te zorgen dat de patch volledig is.
Op advies van de Linux-kernelgemeenschap hebben we al honderden rapporten en patches voor kritieke kwetsbaarheden verstuurd. We werken met Patch the Planet-partners samen om geleidelijk patches voor de rest te versturen. Dit werk maakt deel uit van onze bredere inzet via Daybreak om opensourceprojecten te ondersteunen.
In dit gedeelte delen we inzichten, beschouwingen en aanvullende analyses uit dit onderzoek.
Tijdens dit onderzoek zagen we hoe snel de Linux-beheerders werkten om kwetsbaarheden te verhelpen en gebruikers te beschermen. De scan werd medio oktober 2026 uitgevoerd op de nieuwste Linux-kernel. Toen de autonome scan en de handmatige analyse na 10 dagen waren afgerond, waren 61 LPE's al upstream gepatcht, stonden er voor 43 patches klaar en werden 299 openbaar gemeld en besproken.
We zijn de Linux-beheerders zeer dankbaar voor hun voortvarende werk om gevonden problemen te patchen, en ook de bredere beveiligingsgemeenschap die haar bevindingen bijdraagt. Deze gezamenlijke aanpak is nodig om de software van de wereld te beveiligen. Het hoge tempo waarin kwetsbaarheden worden gemeld en gepatcht, onderstreept ook hoe cruciaal het voor gebruikers en bedrijven is om software up-to-date te houden.
Belangrijkste les: Geautomatiseerde triage moet rekening houden met de snelle patchcyclus. Door bevindingen opnieuw te valideren tegen de nieuwste code, inclusief code die na de oorspronkelijke scan is samengevoegd, kunnen dubbele of achterhaalde rapporten worden voorkomen. Zo blijft de aandacht gericht op onopgeloste kwetsbaarheden en krijgen beheerders bruikbaar bewijs zonder onnodig extra beoordelingswerk.
Terwijl we de pipeline ontwikkelden, vond en misbruikte GPT‑5.6 Sol eind juli 2026 166 unieke LPE-kwetsbaarheden, voor in totaal $ 513.690 aan API-credits.
Bij de tweede scan, medio oktober 2026, vond en misbruikte het nieuwere cybermodel 948 unieke LPE-kwetsbaarheden, voor in totaal $ 1.213.430 aan API-credits. Voor beide campagnes scanden we de op dat moment nieuwste masterbranch van de Linux-kernel.
Belangrijkste les: Scan eerder onderzochte code opnieuw naarmate de capaciteiten van modellen verbeteren. Een capabeler model kan kwetsbaarheden blootleggen die eerdere modellen over het hoofd zagen, zelfs met dezelfde onderzoeksharness.
We namen een steekproef van 166 door de agents ontwikkelde exploits en analyseerden de gebruikte exploitatietechnieken. Voor zover wij weten, gebruikten de agents 10 nieuwe exploitatietechnieken in de onderzochte exploits. We deelden de exploitatietechnieken met externe experts in kernelexploitatie. Ook voor hen waren de technieken nieuw.
Van de 10 technieken betreffen er twee nieuwe persistente elastische objecten die het model gebruikte om objecten in de doelcache van de kernel te sprayen. Twee zijn nieuwe page-groomingtechnieken om exploits betrouwbaarder te maken. Vijf zijn nieuwe data-only-technieken om direct of via een schrijfoperatie naar een vrij te kiezen geheugenadres privilege-escalatie te bereiken. De laatste techniek betreft willekeurige typeverwarring. Om veiligheidsredenen delen we in dit artikel niet de volledige technische details van deze nieuwe exploitatietechnieken.
Belangrijkste les: Grensverleggende modellen herkennen niet alleen bekende kwetsbare codepatronen en gebruiken niet uitsluitend bekende exploitatietechnieken; ze tonen creativiteit en nieuwe benaderingen.
Een belangrijk onderdeel van de missie van ons team is het meten van de kosten voor het vinden en misbruiken van kwetsbaarheden, om op basis daarvan richting te geven aan investeringen in verdediging. Ons doel is verdedigers te helpen kwetsbaarheden te verhelpen voordat aanvallers ze kunnen gebruiken, en softwaremisbruik voor aanvallers onrendabel te maken. Door exploitatiekosten te meten, kunnen we beoordelen hoe die uitdaging verandert naarmate de capaciteiten van modellen verbeteren. In dit gedeelte vergelijken we de kosten van onze pipelinerun met de beloningen van bugbountyprogramma's voor de gevonden kwetsbaarheden.
De virtuele doelmachines in ons experiment draaiden een standaard desktopbesturingssysteem, geen verzwakt doelsysteem, met hetzelfde dreigingsmodel als bij cyberbeveiligingswedstrijden (zoals Pwn2Own(opent in een nieuw venster) en TyphoonPWN(opent in een nieuw venster)). Pwn2Own en TyphoonPWN boden eerder bugbounty's van respectievelijk $ 20.000 en $ 70.000 voor exploits voor lokale privilege-escalatie in de Linux-kernel. Als we die eerdere bountybedragen toepassen op de 948 exploits, levert dat een hypothetische waarde op van $ 18,9 miljoen tot $ 66,3 miljoen, ongeveer 16 tot 55 keer de kosten van onze pipeline.
We testten onze pipeline ook tegen Googles beloningsprogramma voor kwetsbaarheden, kernelCTF(opent in een nieuw venster), dat een extra beveiligde Linux-kernel met een kleiner aanvalsoppervlak als doelwit gebruikt. We voerden de pipeline uit op de nieuwste versie van de Linux-kernel in de kernelCTF-omgeving. Omdat deze versie niet compatibel was met de SLAB_VIRTUAL-beveiligingsmaatregel in kernelCTF, verwijderden we die uit de configuratie. Dit leverde 25 proofs of concept voor informatielekken en 21 exploits voor lokale privilege-escalatie op. Ter vergelijking: op het moment van schrijven heeft kernelCTF in 2026 26 bevestigde zero-day-LPE-exploits geaccepteerd. De volledige campagne duurde 112 uur en kostte ongeveer $ 32.936 aan API-credits. Het opsporen van kwetsbaarheden was goed voor 83,7% van de API-kosten. Als de 21 kwetsbaarheden door het programma werden geaccepteerd, zou dat ongeveer $ 1,5 miljoen aan bounty's opleveren, circa 45 keer de kosten.
Belangrijkste les: Op basis van openbare beloningsbedragen was onze onderzoekspipeline voor kwetsbaarheden met de huidige modellen met cybercapaciteiten ten tijde van dit onderzoek netto winstgevend. Verdedigers zouden hun software proactief moeten analyseren om misbruik ervan voor aanvallers onrendabel te maken.
Bij de beoordeling van de misbruikbaarheid kregen ExploitDev-agents een kwetsbaarheidsrapport en de opdracht een volledig werkende exploit te maken. Onze pipeline markeerde een kwetsbaarheid als misbruikt als er succesvol een rootshell was verkregen. Tijdens een vroege run rapporteerde de exploitatiefase 200 succesvolle exploits voor lokale privilege-escalatie. Na menselijke beoordeling bleek echter dat 20 daarvan rootrechten hadden verkregen via een andere zero-day, een andere kwetsbaarheid dan de toegewezen kwetsbaarheid. Dit wijst erop dat ook succesvolle exploitatie door agents grondig moet worden gevalideerd.
We scherpten daarna de taakvoorwaarden aan en voegden een onafhankelijke controle toe om te bevestigen dat elke uiteindelijke exploit de toegewezen kwetsbaarheid gebruikte.
Belangrijkste les: Controleer bij autonoom beveiligingsonderzoek niet alleen het resultaat, maar ook de weg ernaartoe. Isolatie, monitoring en onafhankelijke controles zijn noodzakelijke beheersmaatregelen.
Aan het begin van dit onderzoek onderzochten we of we uitgebreide orkestratie rond de agent moesten bouwen om de cybercapaciteiten te verbeteren. Ons resultaat wees erop dat sterkere modellen minder orkestratie en begeleiding nodig hebben. De marginale verbetering weegt bovendien niet op tegen de onderhoudskosten. Daarom besloten we de uitgebreide orkestratie te verwijderen.
In het experiment vergeleken we GPT‑5.5 Cyber en GPT‑5.6 Cyber. We zagen dat GPT‑5.5 Cyber niet consequent herkende wanneer en hoe bestaande exploitatietechnieken voor de Linux-kernel moesten worden toegepast. We bundelden vervolgens 103 technieken in een formaat dat het model goed kon verwerken, stelden ze beschikbaar in de omgeving van de agent en gaven de agent de instructie ze te gebruiken. Bij 63 mogelijke exploitatiedoelen verhoogde dit het slagingspercentage van 76,2% naar 88,9%.
Toen we dit herhaalden met GPT‑5.6 Cyber, bleek het model beter in staat om zelfstandig relevante technieken te vinden, te selecteren en toe te passen. We verwijderden de orkestratie van technieken en skills. Deze GPT‑5.6 Cyber-workflow met beperkte orkestratie presteerde beter dan de GPT‑5.5 Cyber-workflow met uitgebreidere ondersteuning. Het opnieuw toevoegen van de extra techniekenlaag voor GPT‑5.6 Cyber leverde slechts een marginale verbetering van 1,5 procentpunt op.
Belangrijkste les: Evalueer je orkestratie en harness opnieuw wanneer de capaciteiten van het basismodel veranderen. Ondersteunende structuren die één generatie modellen aanzienlijk verbeteren, kunnen voor een sterker model weinig toevoegen. Beoordeel daarom of de voordelen nog opwegen tegen het onderhoud.
Aanvankelijk maakte het model op een directe opdracht om patches voor te stellen functioneel correcte patches die de proof of concept blokkeerden, maar soms andere problemen introduceerden. Ze bevatten meer code dan nodig, konden de prestaties nadelig beïnvloeden of weken af van codeconventies. Ook onderzocht het model soms geen gerelateerde code op varianten van dezelfde kwetsbaarheid, waardoor patches onvolledig waren.
Aanvullende instructies en iteratieve verbeteringen aan het patchgeneratieproces verhoogden de kwaliteit van de patches. Dit wijst erop dat door AI gegenereerde beveiligingspatches met de juiste aanpak correct, minimaal en consistent met bestaande codeconventies kunnen zijn. Hier wordt actief onderzoek naar gedaan, en we denken dat dit met toekomstige modellen eenvoudiger en effectiever wordt. In enkele gevallen kon ons onderzoeksprototype ook problemen vinden in patches van menselijke experts. Die werden vervolgens verholpen voordat de patches werden samengevoegd.
Belangrijkste les: Modellen kunnen het patchproces versnellen, maar patchskills en harnesses moeten mogelijk iteratief worden verbeterd om te zorgen dat patches betrouwbaar aan zowel functionele als niet-functionele eisen voldoen. Daarnaast raden we aan modellen in te zetten om patches van mensen en AI vanuit het perspectief van een aanvaller te beoordelen. Zo kunnen ze onder meer ontdekken of een patch te omzeilen is of andere aanvalsroutes of varianten mist.
Tijdens onze kernelCTF-run vond en misbruikte ons onderzoeksprototype naast de 21 zero-day-exploits in de Linux-kernel ook een kwetsbaarheid in QEMU TCG. De analyseagent kreeg de opdracht de code voor het afhandelen van binnenkomende systeemaanroepen te analyseren. Bij het schrijven van programma's om met overgangen tussen privilegeniveaus te experimenteren, stuitte de agent op een onverwachte kernelcrash. De agent onderzocht de crash, herleidde het probleem tot QEMU TCG zonder toegang tot de broncode van QEMU en nam de kwetsbaarheid op in het rapport. De ExploitDev-agent ontwikkelde vervolgens met succes een exploit voor lokale privilege-escalatie voor deze kwetsbaarheid. We ontdekten deze QEMU-kwetsbaarheid bij de handmatige analyse van de exploits en bevestigden dat ze upstream in QEMU al was verholpen, maar nog niet in de releasebuild die tijdens het experiment werd gebruikt.
Belangrijkste les: Grensverleggende modellen met cybercapaciteiten kunnen kwetsbaarheden in testinfrastructuur vinden. We raden aan elk onderdeel van de infrastructuur te testen voordat je offensief kwetsbaarheidsonderzoek uitvoert. We hebben onze infrastructuur proactief getest en daarbij veel kwetsbaarheden in Kata, Moby/Docker, gVisor en andere projecten gemeld en gepatcht.
Ons doel is om de toenemende capaciteiten van modellen om te zetten in een blijvend voordeel voor de mensen die het internet beveiligen. Dit onderzoek laat zien dat de groeiende cybercapaciteiten van grensverleggende modellen kunnen worden ingezet om effectief kwetsbaarheden op te sporen in complexe software, zoals de Linux-kernel. Het versterken van de beveiliging van cruciale softwareprojecten zoals Linux en andere opensourceprojecten kan veel achterliggende systemen en gebruikers beschermen.
Via Patch the Planet, een Daybreak-initiatief, willen we dit onderzoek uitbreiden naar meer cruciale softwareprojecten en samen met beheerders en beveiligingspartners betrouwbare geautomatiseerde patching ontwikkelen. We willen de mogelijkheden voor aanvallers steeds verder beperken en de kosten voor het vinden en misbruiken van kwetsbaarheden verhogen, totdat de verwachte opbrengst niet meer opweegt tegen de kosten van de aanval.
Elke generatie modellen zou ons moeten helpen software te bouwen die voor de volgende generatie moeilijker te kraken is. We blijven werken aan een veilig internet waarop iedereen met plezier kan bouwen.
