Tusen färre vägar till root

Säkerhetsforskning som tidigare krävde en separat, långvarig undersökning av varje fynd kan i allt högre grad genomföras som en systematisk process. Det här dokumentet beskriver en av våra satsningar inom området.

Sårbarhetssökning blir lättare att skala upp, men prioritering och validering är fortfarande operativa flaskhalsar. Vi byggde en prototyp för att söka efter säkerhetsbrister i Linux-kärnan i en kontrollerad forskningsmiljö. Vår prototyp identifierade och analyserade 2 308 potentiella fynd i Linux-kärnan, reproducerade dynamiskt 1 724 sårbarheter och tog fram 948 exploits för lokal privilegieeskalering (LPE) som kunde ge en lokal användare utan särskilda behörigheter rootåtkomst.

Vi använde dessa belägg för att prioritera vilka sårbarheter som skulle rapporteras och tog fram patchförslag för granskning av de projektansvariga. På inrådan av Linux-kärnans community började vi med kritiska sårbarheter och arbetar nu med partner inom Patch the Planet för att ta fram fler rapporter och patchar.

I juni berättade vi, som en del av vårt initiativ Patch the Planet, att GPT‑5.5 Cyber hade identifierat sårbarheter i Linux-kärnan och utvecklat 24 exploits för lokal privilegieeskalering för att validera och rapportera dem. Vi vidareutvecklade arbetet till en pipeline som drivs av en kommande cybermodell och omfattar sårbarhetssökning, dynamisk validering, bedömning av möjligheten till utnyttjande och patchgenerering. När körningen var klar granskade mänskliga forskare resultaten och rapporterade de upptäckta sårbarheterna tillsammans med patchar.

Linux-kärnan ligger till grund för Android-enheter, molninfrastruktur, superdatorer och andra system som används av miljarder människor. Med över 40 miljoner kodrader exponerar kärnan en stor attackyta genom systemanrop, nätverksfunktioner, filsystem och drivrutiner. Vi valde Linux för att undersöka hur effektivt banbrytande modeller kan hitta sårbarheter och visa deras säkerhetskonsekvenser i en kodbas av den här storleken och betydelsen.

Det inledande sårbarhetssökningssteget gav tusentals potentiella fynd – för många för att säkerhetsforskare skulle kunna granska och göra triage av dem manuellt. Den operativa utmaningen i vår pipeline för sårbarhetssökning var inte att hitta sårbarheter, utan att avgöra vilka fynd som kunde reproduceras, vilken säkerhetsgräns de passerade och vilka som de projektansvariga behövde uppmärksamma först.

OpenAI:s cyberteam har i uppdrag att hjälpa till att säkra den programvara som världen är beroende av. Vi redovisar API-kostnader för varje steg för att hjälpa forskare att bedöma vilka resurser som behövs för att upprepa och vidareutveckla arbetet. Kostnaderna speglar de modeller, målkonfigurationer och arbetsflöden som användes i den här utvärderingen. Vårt övergripande mål är att hjälpa försvarare att hitta och åtgärda sårbarheter, minska angriparnas möjligheter och höja deras kostnad för att utnyttja programvara.

Observera slutligen att vi i den här forskningen fokuserade på metodik och på att mäta modellernas förmåga, inte på kostnaden. Vi förväntar oss att tillräcklig vidareutveckling av körmiljön skulle kunna sänka kostnaden avsevärt i varje steg. De kostnader vi redovisar bör därför snarare ses som en övre gräns.

Vår prototyp för sårbarhetsforskning är en pipeline i fem steg, med en kommande cybermodell i centrum:

• Sårbarhetssökning: Agenter identifierar säkerhetsrelevanta delar av kodbasen och skannar dem efter potentiella fynd.

• Dynamisk validering: Agenter försöker reproducera varje potentiellt fynd i en isolerad miljö och sparar belägg från körningen. Resultatet av detta steg är de reproducerade och validerade sårbarheterna.

• Bedömning av möjligheten till utnyttjande: Agenter testar om validerade sårbarheter kan möjliggöra informationsläckor eller lokal privilegieeskalering.

• Patchgenerering: Agenter genererar patchar som åtgärdar varje identifierad sårbarhet.

• Mänsklig granskning: Säkerhetsforskare granskar exploiten, patchen och den föreslagna allvarlighetsgraden innan fyndet rapporteras till de projektansvariga.

I slutet av pipelinen sammanställer systemet en grundorsaksanalys, en minimal proof of concept som orsakar en krasch, ett patchförslag och en fullständig exploit. Det hjälper mänskliga forskare att bedöma sårbarhetens allvarlighetsgrad och få rättningarna införda i huvudprojektet.

Alla kodrader i Linux-kärnan är inte säkerhetsrelevanta. Vår pipeline använde ett team av spaningsagenter för att identifiera särskilt viktiga granskningsobjekt, som sedan skickades vidare till analysagenter för sårbarhetsskanning.

Spaningsagenter läser igenom varje mapp och fil och avgör vilka objekt som ska granskas utifrån deras nåbarhet (om de kan nås av användare med låga behörigheter) och säkerhetsrelevans.

I detta steg identifierades 5 034 granskningsobjekt, cirka 2,8 miljoner kodrader, vilket motsvarar ungefär 7 % av hela Linux-kärnans kodbas. Det minskade kostnaden för säkerhetsgranskningen avsevärt jämfört med en analys av hela kodbasen. Detta steg kostade 3 426 USD i API-krediter.

Därefter analyserade analysagenter varje granskningsobjekt och tog fram potentiella fynd med ett arbetsflöde liknande det som används i pluginen Codex Security⁠(öppnas i ett nytt fönster). I stora drag läser analysagenterna koden i det tilldelade granskningsobjektet för att förstå hur den fungerar, identifiera dess hotmodell och leta efter sårbarheter.

Inom 12 timmar hade analysagenterna tagit fram 2 308 potentiella fynd efter att dubbletter tagits bort. Detta steg kostade 316 549 USD i API-krediter.

Ett potentiellt fynd är inte detsamma som en validerad sårbarhet. I den här skalan är det inte praktiskt möjligt för vårt forskarteam att undersöka varje rapport manuellt.

Vi fokuserade därför på att validera fynd som a) kunde nås av en användare med låga behörigheter, b) inte krävde några särskilda behörighetsförmågor och c) gav mätbara belägg för minneskorruption.

För varje potentiellt fynd genererade en triageagent en proof of concept och körde den i en isolerad virtuell maskin med en Linux-kärna utrustad med Kernel Address Sanitizer (KASAN). Agenten observerade både programmets utdata och systemkonsolen och förfinade sedan sin proof of concept iterativt tills den reproducerade det rapporterade beteendet eller hade uttömt de möjliga sätten att utlösa det.

Inom 30 timmar reproducerade vårt system 1 724 sårbarheter, cirka 74,7 % av de 2 308 potentiella fynden. Enbart statisk kodgranskning kan ge falska positiva resultat. Därför imponerades vi av analysagenternas precision och triageagenternas förmåga att självständigt skapa fungerande proof of concept-exempel för nästan tre fjärdedelar av de potentiella fynden.

De flesta återstående fynd krävde antingen förhöjda behörigheter eller kunde inte reproduceras inom tidsramen på grund av svårutlösta kapplöpningstillstånd, specifika utlösningsvillkor (t.ex. att en allokering måste misslyckas på en viss rad) eller tidskrävande validering (t.ex. att en referensräknare måste slå runt). Endast 3,1 % berodde på felaktig analys av modellen, där den rapporterade sårbarheten förutsatte ett omöjligt tillstånd.

Valideringssteget kostade totalt 73 330 USD i API-krediter. I vår valideringspipeline behövde en proof of concept genereras för att bekräfta om ett potentiellt fynd var en verklig sårbarhet. Vi såg att detta var dyrare än att ge en rekommendation enbart utifrån statisk analys, och att kostnaden för att försöka validera ett sant positivt resultat var ungefär densamma som för ett falskt positivt. Att sålla bort falska positiva resultat tidigare i pipelinen gör därför processen betydligt mer kostnadseffektiv.

Validering fastställer att en sårbarhet är verklig, men inte hur brådskande det är att åtgärda den. En sårbarhet som kan möjliggöra lokal privilegieeskalering bör till exempel prioriteras högre än en som bara kan orsaka en lokal överbelastningsattack. Med 1 724 validerade sårbarheter var nästa uppgift att identifiera de fynd som kunde få störst säkerhetskonsekvenser.

En inledande sållningsagent granskade varje rapport, kraschlogg och relevant källkod statiskt. Den släppte avsiktligt igenom många fynd för att undvika att potentiellt allvarliga sådana sållades bort, men filtrerade bort fall utan någon rimlig väg till utnyttjande. Detta begränsade resultaten till 313 potentiella informationsläckor och 1 238 potentiella sårbarheter för lokal privilegieeskalering.

Agenter för exploitutveckling (ExploitDev) testade sedan dessa fynd i isolerade virtuella maskiner, konfigurerade med de skydd som är aktiverade i en vanlig Linux-distribution, däribland Supervisor Mode Execution Prevention (SMEP), Supervisor Mode Access Prevention (SMAP), Kernel Address Space Layout Randomization (KASLR) och HARDENED_USERCOPY. Det bidrog till att undvika orealistiska bedömningar som förutsatte avstängda skydd.

Agenterna tog fram 291 proof of concept-exempel för informationsläckor och 1 169 fungerande exploits för lokal privilegieeskalering som kunde ge lokala användare utan särskilda behörigheter rootåtkomst.

Vi utförde variantanalys och utvecklade 948 separata patchar för sårbarheterna bakom dessa exploits. Vi använder det antalet för att fastställa det totala antalet unika LPE-sårbarheter. Fungerande exploits kostade i genomsnitt 359 USD i krediter att utveckla. Det gör det relativt billigt för försvarare att testa om upptäckta sårbarheter kan utnyttjas.

Den inledande agenten för sårbarhetssållning kostade 44 194 USD i API-krediter. Utnyttjandesteget kostade totalt 775 929 USD i API-krediter: 84 929 USD för att bearbeta potentiella informationsläckor och 691 000 USD för potentiella sårbarheter för lokal privilegieeskalering.

I genomsnitt var det ungefär dubbelt så dyrt att bearbeta ett potentiellt fynd för lokal privilegieeskalering (558 USD) som en potentiell informationsläcka (271 USD). Det beror på att PoC:erna för informationsläckor fördes vidare från valideringssteget och krävde färre ändringar för att kunna användas i en exploit. Att utveckla en exploit från ett potentiellt LPE-fynd krävde däremot många extra steg, som att planera en strategi, identifiera sårbara objekt att använda, kringgå skydd och annat. Vi noterade också att misslyckade försök att utnyttja sårbarheter (3 922 USD för 69 fall) kostade mycket mer än lyckade försök (360 USD för 1 169 fall). Detta berodde på ett fåtal sårbarheter som var svåra att utnyttja, exempelvis kapplöpningstillstånd. Ett rimligt avbrottsvillkor, som att avsluta försöket efter en timme utan framsteg, skulle ha minskat kostnaden för ExploitDev avsevärt.

För varje validerad sårbarhet genererar systemet också en patch. Vi ger modellen den relevanta källkoden och instruerar den att följa god praxis för patchutveckling: utföra statiska kontroller av patchen, följa utvecklingspraxis i närliggande kod och göra en variantanalys för att säkerställa att patchen är fullständig.

På förslag från Linux-kärnans community har vi redan skickat hundratals rapporter och patchar för kritiska sårbarheter och arbetar med partner inom Patch the Planet för att successivt skicka patchar för resten. Arbetet ingår i vårt bredare åtagande inom Daybreak att stödja projekt med öppen källkod.

I det här avsnittet delar vi lärdomar, reflektioner och ytterligare analyser från forskningen.

Under forskningen såg vi hur Linux projektansvariga snabbt arbetade med att åtgärda sårbarheter och skydda användarna. Skanningen utfördes på den senaste Linux-kärnan i mitten av oktober 2026. När den autonoma skanningen och den manuella analysen var klara efter 10 dagar hade 61 LPE-sårbarheter redan patchats i huvudprojektet, 43 hade patchar under förberedelse och 299 höll på att rapporteras och diskuteras offentligt.

Vi är mycket tacksamma för Linux projektansvariga, som har arbetat skyndsamt med att patcha identifierade problem, och för den bredare säkerhetscommunityn, som också bidrar med sina fynd. Det är den här gemensamma insatsen som behövs för att säkra världens programvara. Den snabba takten i offentliggörandet och patchningen av sårbarheter understryker också hur avgörande det är att användare och företag håller sin programvara uppdaterad.

Lärdom: Automatisk triage bör ta hänsyn till den snabba patchningscykeln. Att validera fynden på nytt mot den senaste koden, inklusive kod som integrerats efter den ursprungliga skanningen, hjälper till att undvika dubbla eller inaktuella rapporter. Det riktar uppmärksamheten mot olösta sårbarheter och ger de projektansvariga underlag att agera på utan att skapa onödigt granskningsarbete.

Medan vi utvecklade pipelinen, i slutet av juli 2026, hittade och utnyttjade GPT‑5.6 Sol 166 unika LPE-sårbarheter till en totalkostnad på 513 690 USD i API-krediter.

Vid den andra skanningen, i mitten av oktober 2026, hittade och utnyttjade den nyare cybermodellen 948 unika LPE-sårbarheter till en totalkostnad på 1 213 430 USD i API-krediter. Vid båda insatserna skannade vi den då senaste versionen av Linux-kärnans master-gren.

Lärdom: Skanna tidigare granskad kod på nytt när modellernas förmåga förbättras. En mer kapabel modell kan upptäcka sårbarheter som tidigare modeller missat, även med samma körmiljö för forskningen.

Vi gjorde ett urval av 166 exploits som agenterna utvecklat och analyserade vilka tekniker som användes i dem. Såvitt vi vet använde agenterna 10 nya tekniker för att utnyttja sårbarheter i de utvalda exploiten. Vi delade teknikerna med externa experter på att utnyttja sårbarheter i kärnan, och de var nya även för dem.

Av de tio teknikerna bygger två på nya beständiga elastiska objekt som modellen använde för att sprida objekt i den angripna kärncachen. Två är nya tekniker för att arrangera minnessidor och göra exploiten mer tillförlitliga. Fem är nya tekniker som enbart manipulerar data för att uppnå privilegieeskalering direkt eller genom en godtycklig skrivning. Den sista tekniken bygger på godtycklig typförväxling. Av säkerhetsskäl delar vi inte de fullständiga tekniska detaljerna om dessa nya tekniker i det här inlägget.

Lärdom: Banbrytande modeller matchar inte bara kända sårbara kodmönster eller använder enbart kända tekniker för att utnyttja sårbarheter – de visar kreativitet och nya angreppssätt.

En viktig del av vårt teams uppdrag är att mäta kostnaden för att hitta och utnyttja sårbarheter och använda det underlaget för att vägleda investeringar i försvar. Vårt mål är att hjälpa försvarare att åtgärda sårbarheter innan angripare kan använda dem, och att göra det för dyrt för angripare att utnyttja programvara. Genom att mäta kostnaderna för att utnyttja sårbarheter kan vi bedöma hur utmaningen förändras när modellernas förmåga förbättras. I det här avsnittet jämför vi kostnaden för vår pipelinekörning med belöningarna i buggbelöningsprogram för de identifierade sårbarheterna.

De virtuella målmaskinerna i vårt experiment körde ett vanligt skrivbordsoperativsystem i standardutförande, inte ett försvagat mål, med samma hotmodell som används i cybersäkerhetstävlingar (t.ex. Pwn2Own⁠(öppnas i ett nytt fönster), TyphoonPWN⁠(öppnas i ett nytt fönster)). Historiskt har Pwn2Own och TyphoonPWN erbjudit buggbelöningar på 20 000 respektive 70 000 USD för exploits för lokal privilegieeskalering i Linux-kärnan. Om dessa historiska belopp tillämpas på de 948 exploiten blir det hypotetiska värdet 18,9–66,3 miljoner USD, ungefär 16 till 55 gånger kostnaden för vår pipeline.

Vi testade också vår pipeline mot Googles sårbarhetsbelöningsprogram kernelCTF⁠(öppnas i ett nytt fönster), där målet är en säkerhetsförstärkt Linux-kärna med minskade attackytor. Vi körde pipelinen på den senaste versionen av Linux-kärnan i kernelCTF:s miljö och tog fram 25 proof of concept-exempel för informationsläckor och 21 exploits för lokal privilegieeskalering. Kärnversionen var inte kompatibel med skyddet SLAB_VIRTUAL i kernelCTF, så vi tog bort det ur konfigurationen. Som jämförelse har kernelCTF i skrivande stund godkänt 26 bekräftade LPE-exploits för nolldagssårbarheter under 2026. Hela insatsen tog totalt 112 timmar och kostade ungefär 32 936 USD i API-krediter, varav sårbarhetssökningen stod för 83,7 % av API-kostnaden. Om de 21 sårbarheterna godkändes av programmet skulle det ge en belöning på cirka 1,5 miljoner USD, ungefär 45 gånger kostnaden.

Lärdom: Utifrån offentliga belöningsbelopp gav vår pipeline för sårbarhetsforskning en nettovinst vid tiden för forskningen, med då tillgängliga modeller med cyberförmåga. Försvarare bör proaktivt analysera sin programvara så att det blir för dyrt för angripare att utnyttja den.

Vid bedömningen av möjligheten till utnyttjande fick ExploitDev-agenter en sårbarhetsrapport och uppdraget att skapa en fullt fungerande exploit. Vår pipeline markerade en sårbarhet som utnyttjad om ett root-skal hade erhållits. Under en tidig körning rapporterade utnyttjandesteget 200 lyckade exploits för lokal privilegieeskalering. Efter mänsklig granskning upptäckte vi dock att 20 av dessa hade uppnått rootbehörigheter genom en annan nolldagssårbarhet än den tilldelade. Det tyder på att även lyckade försök att utnyttja sårbarheter med agenter behöver valideras ordentligt.

Därefter skärpte vi uppgiftens begränsningar och lade till en oberoende kontroll som bekräftade att varje slutlig exploit använde den tilldelade sårbarheten.

Lärdom: Vid autonom säkerhetsforskning behöver både vägen till resultatet och själva resultatet verifieras. Isolering, övervakning och oberoende kontroller är nödvändiga skyddsåtgärder.

Tidigt i forskningen undersökte vi om vi skulle bygga omfattande orkestrering runt agenten för att förbättra dess cyberförmåga. Våra resultat tydde på att starkare modeller kräver mindre orkestrering och vägledning. Den marginella förbättringen motiverar inte heller underhållskostnaden. Därför beslutade vi att ta bort den omfattande orkestreringen.

I experimentet jämfördes GPT‑5.5 Cyber och GPT‑5.6 Cyber. Vi såg att GPT‑5.5 Cyber inte konsekvent kunde avgöra när och hur befintliga tekniker för att utnyttja sårbarheter i Linux-kärnan skulle tillämpas. Vi sammanställde därför 103 tekniker i ett modellanpassat format, gjorde dem tillgängliga i agentens miljö och instruerade agenten att använda dem. För 63 potentiellt utnyttjbara fynd ökade detta andelen lyckade försök från 76,2 % till 88,9 %.

När vi upprepade detta med GPT‑5.6 Cyber var modellen bättre på att själv hitta, välja och tillämpa relevanta tekniker. Vi tog bort orkestreringen av tekniker och färdigheter. Detta GPT‑5.6 Cyber-arbetsflöde med lättare orkestrering överträffade GPT‑5.5 Cyber-arbetsflödet med dess mer omfattande stödstruktur. Att lägga tillbaka det extra tekniklagret för GPT‑5.6 Cyber gav bara en marginell förbättring på 1,5 procentenheter.

Lärdom: Ompröva orkestreringen och körmiljön när basmodellernas förmåga förändras. En stödstruktur som ger en tydlig förbättring för en modellgeneration kan tillföra lite för en starkare modell. Nyttan bör därför vägas mot underhållskostnaden.

När modellen inledningsvis fick en direkt instruktion att generera patchförslag skapade den funktionellt korrekta patchar som stoppade proof of concept-exemplet, men ibland uppstod andra problem: mer kod än nödvändigt, risk för försämrad prestanda eller avvikelser från kodningskonventioner. Ibland undersökte den inte heller relaterad kod efter varianter av samma sårbarhet, vilket ledde till ofullständiga patchar.

Ytterligare instruktioner och iterationer av patchgenereringsprocessen förbättrade patcharnas kvalitet. Det tyder på att AI-genererade säkerhetspatchar med rätt hantering kan vara korrekta, minimala och förenliga med befintliga kodningskonventioner. Detta är ett aktivt forskningsområde, och vi tror att arbetet kommer att bli enklare och effektivare med framtida modeller. I några fall kunde vår forskningsprototyp också identifiera problem i patchar skrivna av mänskliga experter. Problemen åtgärdades sedan innan patcharna integrerades.

Lärdom: Modeller kan påskynda patchningsprocessen, men patchningsfärdigheter och körmiljöer kan behöva förbättras iterativt för att säkerställa att patcharna tillförlitligt uppfyller både funktionella och icke-funktionella krav. Vi rekommenderar dessutom att modeller används för att granska både mänskligt skrivna och AI-genererade patchar ur ett angriparperspektiv. Det kan avslöja exempelvis att en patch går att kringgå eller missar andra angreppsvägar eller varianter.

Under vår kernelCTF-körning hittade och utnyttjade forskningsprototypen även en sårbarhet i QEMU TCG, utöver de 21 exploiten för nolldagssårbarheter i Linux-kärnan. Analysagenten fick i uppgift att analysera ingångskoden för systemanrop. När den skrev program för att experimentera med övergångar mellan behörighetsnivåer stötte den på en oväntad kärnkrasch. Den gjorde en triage av kraschen, spårade problemet till QEMU TCG utan tillgång till QEMU:s källkod och tog med sårbarheten i rapporten. ExploitDev-agenten lyckades därefter utveckla en exploit för lokal privilegieeskalering för denna sårbarhet. Vi upptäckte denna QEMU-sårbarhet när vi analyserade exploiten manuellt och bekräftade att sårbarheten hade åtgärdats i QEMU:s huvudprojekt, men inte i den utgivna version som användes i experimentet.

Lärdom: Banbrytande modeller med cyberförmåga kan hitta sårbarheter i testinfrastruktur. Vi rekommenderar att varje del av infrastrukturen testas innan offensiv sårbarhetsforskning genomförs. Vi har testat vår infrastruktur proaktivt och rapporterat och patchat många sårbarheter i Kata, Moby/Docker, gVisor och andra projekt.

Vårt mål är att omsätta modellernas ökande kapacitet i ett varaktigt försprång för dem som arbetar för ett säkert internet. Den här forskningen visar att banbrytande modellers växande cyberförmåga kan användas för att effektivt söka efter sårbarheter i komplex programvara, som Linux-kärnan. Att stärka säkerheten i kritiska programvaruprojekt som Linux och andra projekt med öppen källkod kan skydda många system och användare som är beroende av dem.

Genom Patch the Planet, ett Daybreak-initiativ, vill vi utvidga den här forskningen till fler kritiska programvaruprojekt och utveckla tillförlitlig automatisk patchning tillsammans med projektansvariga och säkerhetspartner. Vi vill successivt minska angriparnas möjligheter och höja kostnaden för att hitta och utnyttja sårbarheter, tills den förväntade vinsten inte längre motiverar attacken.

Varje generation modeller bör hjälpa oss att bygga programvara som nästa generation får svårare att angripa. Vi fortsätter att arbeta för ett säkert internet där alla kan skapa med glädje.