GPT-6 Cyber: Vad hundratals kärnkorrigeringar betyder för uppdateringar i små och medelstora företag

OpenAI presenterade GPT-6 Cyber i november 2026, en modell för att hitta säkerhetsluckor. Det nya är inte så mycket tekniken som skalan: i den aktuella Linuxkärnan hittade agenter ca 1 700 bekräftade fel, och varje fynd har en prislapp. För företag utan egen utveckling avgörs läget av hur snabbt korrigeringarna når enheterna.

I våras rapporterade Anthropic om en opublicerad modell som ska ha hittat tusentals tidigare okända sårbarheter i operativsystem och webbläsare. Strax därefter kom Googles Gemini 4 Carbon med klart bättre resultat i exploit-benchmarks. Med OpenAIs tillkännagivande går det att sätta siffror på kostnader och resultat för en genomkörning av en hel kärna.

Den som hittar fel så billigt skapar oundvikligen många korrigeringar. Servrar, brandväggar, NAS-system och kameror kör nästan alla Linux, och i de flesta företag är det någon annan som underhåller kärnan.

GPT-6 Cyber i korthet

GPT-6 Cyber är en specialvariant av GPT-6 Astra för auktoriserat säkerhetsarbete. Modellen letar efter sårbarheter, bygger passande exploits och föreslår korrigeringar. I sitt Model Card placerar OpenAI cyberförmågorna i den högsta nivån i sitt eget Preparedness Framework. I exploit-benchmarken ExploitGym löser den ca 48 % av uppgifterna, basmodellen ca 42 %.

Äldre benchmarks kan vara uppblåsta av träningsdata, det är fortfarande svårt att tillförlitligt utnyttja nyligen publicerade luckor, och helt härdade mål stod emot. Modellen visar en tydlig riktning, men knäcker inte varje mål.

Tillgången är till en början begränsad till utvalda, granskade kunder. Åtkomst sker via API och Codex, med identitetskontroll, flerfaktorsinloggning och godkända IP-adresser. OpenAI rekommenderar att modellen körs isolerat och under mänsklig tillsyn. En stegvis utvidgning har aviserats, men något datum för allmänheten finns inte.

Kärnfel i stor skala

Kärnan i det hela är en genomkörning av den aktuella Linuxkärnan. Först avgränsade agenter de säkerhetsrelevanta delarna, ca 7 % av koden. Andra agenter markerade där ca 2 300 misstänkta ställen, och i isolerade virtuella maskiner kunde ca 1 700 av dem bekräftas. Testerna gjordes på ett oförändrat skrivbords-Linux med de vanliga skyddsmekanismerna som ska hindra angripare från att gissa minnesadresser.

Av de bekräftade felen blev ca 1 200 fungerande lokala rättighetseskaleringar, där ett vanligt konto blir administratör. Bakom dem står ca 950 separata patchar. Hundratals fynd leder alltså till hundratals korrigeringar. Kärnans maintainers reagerade snabbt: inom tio dagar var över 100 rättighetseskaleringar patchade eller hade patchar på gång, och ca 300 till diskuterades offentligt.

Även priset är nytt. Genomkörningen kostade ca 1,2 miljoner US-dollar i API-avgifter, grovt räknat 1 300 US-dollar per resultat. En föregångare i somras landade på ca 170 rättighetseskaleringar för drygt 500 000 US-dollar, den nya körningen ger flera gånger fler fynd till ungefär dubbla kostnaden. Sårbarhetssökning blir därmed en planerbar kostnadspost, jämförbar med datorkraft i molnet. I Firefox hittade modellen dessutom ca 80 tidigare okända allvarliga luckor, som Mozilla har åtgärdat.

Hundratals korrigeringar och uppdateringscyklerna

Ett fynd i sig skyddar ingen. Först korrigeringen i kärnan och sedan installationen på enheten förändrar läget. Antalet CVE-beteckningar per kärnversion ökar kraftigt, med ca 40 miljoner rader kod. Många av dem gäller fel med låg prioritet, men takten i underhållsuppdateringarna ökar märkbart.

Det kritiska är tiden mellan publicerad korrigering och installerad uppdatering. Så snart en patch är offentlig visar den angripare var felet satt. En öppen modell omvandlade kända men ännu inte levererade Firefox-korrigeringar till fungerande attacker för ca 1 000 US-dollar per version, om än bara för att läsa filer på ett standard-Ubuntu. Varje offentlig korrigering blir därmed en ritning för angripare.

En lokal rättighetseskalering kräver en första åtkomst, till exempel ett stulet lösenord, ett webbskal eller ett utbrott ur en container. Den som har det tar sig med en sådan lucka ända till root. Därför spelar lokala kärnfel roll även på servrar som bara nås via webben. Inte varje fynd går att utnyttja, och inte varje server är i fara. Men det andra hindret efter det första intrånget blir tunnare.

I vardagen innebär det att uppdateringar inte längre bör hanteras som ett kvartalsprojekt. En fast rytm med korta omstartsfönster, till exempel månadsvis och omedelbart vid kritiska luckor, tar udden av det enskilda larmet. Den som ändå startar om regelbundet behöver inte först leta fram godkännande, tidsfönster och ansvariga vid en kärnkorrigering.

Tillverkarnas kärnpatchar

En kärnkorrigering har en lång väg att gå. Den hamnar först i huvudgrenen, förs över till långtidsgrenarna och når distributionskärnorna. För enheter tillkommer tillverkarens kärna, firmware-bygge, godkännande och leverans. Först därefter kan företaget installera den.

Beroende på enhetsgrupp ser det mycket olika ut. Standardservrar med en underhållen distribution får kärnuppdateringar oftast inom dagar till veckor. Med livepatchning går tidsfönstret att korta ytterligare vid kritiska luckor, men en omstart är fortfarande det säkraste sättet.

För appliances som brandväggar, NAS-system och routrar är det tillverkaren som styr takten. Uppdateringsfönstret är en del av produktvården, och företaget kan knappt påverka det. Sämst ser det ut för inbyggda system och IoT-enheter. Där körs ofta tillverkarkärnor som ligger många månader eller flera versioner efter huvudgrenen, och vissa produkter får aldrig några kärnkorrigeringar.

Tre frågor till tillverkare och leverantörer skapar klarhet. Hur många dagar efter upstream-korrigeringen kommer en uppdatering? Vilken kärnlinje sitter i enheten? Och hur länge gäller supporten?

Vad små och medelstora företag gör vid försenade patchar

Allt börjar med en enkel inventering. Linux finns inte bara i servrar, utan också i routrar, NAS, kameror, skrivare, brandväggar och styrsystem. Per enhet räcker kärn- och firmwareversion samt tillverkarens namn.

Därefter prioriteras. Vad går att nå från internet, vad hanterar inloggningsuppgifter, vad erbjuder administrativ åtkomst? Enheter med flera ja-svar kommer först. En saknad korrigering kan delvis kompenseras genom avskärmning:

• Gör administrationsgränssnitt otillgängliga från internet, åtkomst endast via VPN med flerfaktorsinloggning.
• Placera enheter i egna nätsegment, så att en övertagen enhet inte öppnar hela nätverket.
• Håll rättigheterna små: inga delade administratörskonton, separata tjänstekonton, containrar med begränsade rättigheter.
• Bevaka loggar, så att ovanliga inloggningar och rättighetsbyten upptäcks.

OpenAI rekommenderar själv flerskiktat försvar och isolering vid hanteringen av modellen, till exempel med Firecracker eller gVisor. Det passar alla företag: ett fel i kärnan ska inte automatiskt öppna allt annat.

En andra hävstång finns i avtalet. Patchfrister och supportens slut hör hemma i leverans- och underhållsavtal, och omstartsfönster kan avtalas i förväg. Den som omfattas av NIS2 bör också utvidga sårbarhetshanteringen till leverantörerna. Kritiska korrigeringar ska ut på enheterna inom några dagar, inte först nästa kvartal.

Även den egna webbplatsen hör till inventeringen, eftersom det är den del som angripare ser först. En webbplatskontroll, inklusive de säkerhetskontroller som sedan en tid automatiskt körs i tillägg, visar vad som syns utifrån och var säkerhetsluckor finns.

Benchmarks varje vecka

Kurvan för toppmodellerna stiger snabbt. Gemini 4 Carbon kom ungefär fyra veckor efter föregångaren Argon och når ca 55 % i ExploitGym, jämfört med ca 42 % för Argon. Anthropic höll i våras tillbaka sin modell eftersom den inte skulle bli allmänt tillgänglig. Linjen är likartad hos alla stora leverantörer: den starkaste modellen stannar till en början i en liten krets.

Benchmarks är inte detsamma som verkligheten. För planeringen räknas riktning och tempo, inte den enskilda procentsiffran. Att avstånden mellan modellgenerationer krymper till veckor eller månader är den egentliga nyheten. Det som i våras med tusentals hittade luckor fortfarande var ett undantag, ser i dag ut som ett förebud.

Öppen källkods-AI och destillering

Inom AI vandrar kunskap nedåt. Vid destillering genererar en stor modell, läraren, svar och lösningsvägar, och en mindre modell, eleven, lär sig av dem. Resultatet är ofta betydligt mindre och billigare utan att alla förmågor går förlorade. För små och medelstora företag är detta den avgörande punkten: det som i dag körs i datacenter hamnar inom några månader på hårdvara som ryms i ett serverskåp.

Öppna modeller som GLM-5.2 och DeepSeek V4-Pro ligger 4 till 7 månader efter de bästa slutna modellerna i cyberförmågor. 2025 var det fortfarande 6 till 10 månader. I genomsnitt över alla förmågor ligger avståndet på ca 4 månader.

För modeller med begränsad åtkomst som GPT-6 Cyber innebär det att åtkomstskyddet ger försvararna ett tidsbegränsat försprång. Öppna vikter kan efter publiceringen varken dras tillbaka eller övervakas. Månaderna fram till att de öppna modellerna kommit ikapp är därför fönstret för grundskydd, ordentliga uppdateringar och AI-stött försvar. Samtidigt gynnar öppna modeller även forskare och försvarare, eftersom granskningsverktyg inte bara uppstår på angriparsidan.

Lokal AI som svar

Toppmodellerna har begränsad åtkomst, är granskade och övervakade. Den som använder dem för säkerhetsarbete lämnar källkod, konfigurationer och loggar till en leverantör som observerar åtgärderna. Skyddad behandling utan insyn från leverantören finns bara för kunder med Zero Data Retention. För de flesta små och medelstora företag är det inget realistiskt alternativ.

Ett tydligt alternativ är lokal AI med öppna modeller på egen hårdvara. Data stannar i huset, och det finns inget beroende av priser, åtkomstregler eller en avstängning. Det är samtidigt en strategisk fördel, eftersom den som håller kunskap och verktyg i det egna företaget tar enskilda leverantörers tillkännagivanden med större ro. Typiska uppgifter är analys av loggar, genomgång av egna konfigurationer, sammanfattning av säkerhetsmeddelanden och dokumentation.

Lokalt körbara modeller ligger visserligen klart efter de bästa molnmodellerna, och vid jakt på zero-days i stor skala är det en nackdel. För vardagen i företaget räcker de ofta, och det är just där datasäkerheten avgörs.

Även lokala installationer kräver disciplin. Gränssnitt hör inte hemma på internet, modellerna kommer från betrodda källor, och agenternas rättigheter förblir begränsade, så att främmande innehåll inte kan smyga in kommandon. Den som sätter sig in i offline-AI hittar en bra startpunkt för detta.

Slutsats

Felsökning med agenter är billig, snabb och skalbar. Handlingsutrymmet ligger därför inte i att hitta, utan i att installera. Den som känner sina enheter, avtalar frister och förbereder avskärmning blir inte överkörd av hundratals kärnkorrigeringar. Och den som håller data och verktyg i det egna huset förblir handlingskraftig även när nästa modeller blir ännu snabbare.