Gemini 4 Carbon: när de starkaste sårbarhetsjägarna hamnar hos stater först

Google har presenterat Gemini 4 Carbon, en modell som enligt företagets egna uppgifter är klart bättre än föregångaren på att hitta och utnyttja säkerhetsluckor. Först får amerikanska underrättelsetjänster tillgång, senare utvalda försvarare, och för alla andra finns inget datum. Här reds ut vad som är belagt, vad som bara är tillverkarens uppgifter och vad företag och tillverkare i Europa kan ändra i sina patchcykler och granskningsprocesser.

Den 28 oktober 2026 presenterade Google Gemini 4 Carbon, bara fyra veckor efter Gemini 4 Argon. Prestandasiffrorna i tillkännagivandet är tillverkarens egna uppgifter och kan inte kontrolleras utifrån. Mer intressant är i vilken ordning modellen ska distribueras: först statliga myndigheter, sedan utvalda försvarare, och någon tidpunkt för alla saknas. Dagen före Googles tillkännagivande, den 27 oktober 2026, publicerade dessutom Anthropic en rapport där en opublicerad forskningsmodell ska ha byggt fem exploit-kedjor. Enligt Anthropic och The Hacker News är alla fem numera åtgärdade, men för Android-fallet saknas en offentlig post och för Windows-fallet är kopplingen oklar.

Först beskrivs benchmarkuppgifterna och deras begränsningar, sedan stegen i tillgången och frågan om vad denna asymmetri betyder för organisationer utanför USA. Därefter följer Anthropics kedjor med patchstatus, konsekvenserna för patchcykler och programvarutillverkare samt en lista med praktiska åtgärder, bland annat hur man kontrollerar en Linuxserver. Läget kan förändras snabbt.

Gemini 4 Carbon: vad Google uppger och vad som går att kontrollera

Uppgifterna om Gemini 4 Carbon kommer från Google och rapporteringen kring det.

Enligt Google når Carbon knappt 55 procent i benchmarken Exploitgym. Argon kom upp i 42 procent och låg därmed strax efter konkurrentmodellen GPT-6 Astra. I benchmarken SEC-bench Pro ligger Carbon på drygt 88 procent och enligt uppgifterna därmed före denna konkurrent. För CWE-bench, ett test i att täppa till säkerhetsluckor, anges 71 procent. En benchmark är en standardiserad uppsättning uppgifter som modeller mäts mot på ett jämförbart sätt. Exakt hur de tre testerna är uppbyggda har inte kontrollerats här. Därför håller sig beskrivningen medvetet till vad tillkännagivandet säger.

Även andra påståenden kommer från Google: hittills ska inget försök till prompt injection ha lyckats, alltså en manipulation av modellen genom insmugglade instruktioner. Modellen ska dessutom hallucinera mindre och oftare ställa motfrågor. Oberoende mätningar av detta saknas. I förbigående nämns priser på 4 US-dollar per miljon inmatningstoken och 20 US-dollar per miljon utmatningstoken, med 50 procents rabatt vid lanseringen. Med dagens mått är det inte billigt i jämförelse, men – sett till de absoluta beloppen – inte heller särskilt dyrt.

Benchmarkvärden besvarar en snäv fråga: hur väl löser en modell förberedda uppgifter? Hur väl den klarar sig i framvuxen programvara med specialfall, gammal kod och oklara ansvarsområden visar de bara i begränsad grad. För bedömningen räcker därför en nykter läsning. Om Googles siffror stämmer är avståndet till föregångaren stort när det gäller att utnyttja luckor. Om det gäller även i praktiken visar sig först när tredje part kan testa modellen.

Tillgång i steg: först underrättelsetjänster, sedan Fairwind, senare alla

Det verkligt nya med Gemini 4 Carbon är vägen till användaren. Google följer tydligen en anvisning från Vita huset om att nya AI-modeller till en början bara ska göras tillgängliga för amerikanska underrättelsetjänster och utvalda användare. Av det följer tre steg.

Det första steget utgörs av amerikanska underrättelsetjänster och användare som de godkänt. Om och hur de använder modellen är inte belagt. Belagt är bara den planerade ordningen. Det andra steget är programmet Fairwind, genom vilket utvalda cyberförsvarare och andra betrodda partner gradvis ska tillkomma. Det tredje steget är allmänheten. Google utlovar tillgänglighet ”snart” men anger inget datum. För Argon gick det två veckor från presentationen till att betalande användare fick tillgång.

Hur Fairwind fungerar beskriver Google DeepMind på programsidan. Där nämns fler än 650 partner. Deltagare kan vara regeringar och nationella cybermyndigheter, operatörer av kritisk infrastruktur, centrala teknikplattformar och akademiska labb. Sökande granskas. Krav är bland annat nätfiskeresistent flerfaktorsinloggning, loggning och defensiv användning, och vidareförmedling är förbjuden. På sidan nämns dock Argon som modell, inte Carbon. Om Carbon omfattas av samma villkor är oklart. Regler för Europa nämns inte på sidan.

För europeiska företag uppstår därmed en asymmetri som i första hand är en tidsfråga. Stater och stora plattformar får kraftfulla verktyg tidigare än små och medelstora företag och tillverkare. Hur lång den luckan blir vet ingen. Två frågor kan hållas isär: vem bestämmer över tillgången, och vad följer av det för organisationer som inte ingår? Tydligen är det Vita huset som bestämmer. För organisationer utanför USA återstår att vänta och rusta sig så att andras försprång gör så liten skada som möjligt.

Motargumentet förtjänar att tas på allvar. En tillgång i steg kan begränsa missbruk, och försvarare med tidig tillgång kan hitta fel före angriparna. Oklart är om angripare får jämförbara förmågor på annat håll, till exempel hos andra leverantörer eller med fritt tillgängliga modeller. Det är inte belagt utan vore spekulation. För planeringen räcker konstaterandet att antaganden om ett bestående försprång för försvararna är riskabla.

Organisationer som inte är behöriga kan enligt Fairwind-sidan använda verktyget CodeMender med offentligt tillgängliga modeller. Det har inte testats här. Men det visar att det finns vägar till AI-stödd felsökning även utan tillgång till det högsta steget.

Vad Anthropic har visat: fem exploit-kedjor och deras patchstatus

En exploit är en kodsnutt som utnyttjar en säkerhetslucka. En exploit-kedja kopplar ihop flera luckor så att ett litet fel blir en fullständig attack. Anthropics Frontier Red Team beskriver den 27 oktober 2026 att en opublicerad intern forskningsmodell med inledande instruktioner och lite mänsklig medverkan har byggt fungerande kedjor. Modellen namnges inte och är en annan än Carbon. Båda tillkännagivandena pekar dock åt samma håll.

De fem fallen i översikt, i samtliga fall enligt de angivna källorna:

• Chrome: Det räcker att öppna en sida för att köra kod utanför sandlådan. Sandlådan är det skyddslager som skiljer webbinnehåll från resten av systemet. Kedjan kombinerar fyra luckor, bland annat minnesfel i JavaScript-motorn V8, ett race condition (ett fel som beror på tidsordningen mellan parallella förlopp) och ett use-after-free (åtkomst till minne som redan frigjorts). Anthropic rapporterade 62 CVE:er, alltså offentligt numrerade sårbarhetsposter, samtliga kritiska eller höga, varav enligt Anthropic 13 sandlådeutbrott. Rättningen finns i Chrome 156.
• Safari: Läs- och skrivåtkomst till webbläsarens minne, och same-origin policy sätts ur spel. Enligt The Hacker News åtgärdat i iOS och iPadOS 26.5.2.
• Android: Åtkomst till data på en låst, stulen Pixel 9 via USB. Fysisk åtkomst krävs. Enligt Anthropic har Google åtgärdat luckan, men någon offentlig post hittades inte enligt The Hacker News.
• Windows: en överbelastningsattack (denial of service) via HTTP/3. Anthropic beskriver en lucka i kärnan, medan The Hacker News hänvisar till en CVE vars beskrivning nämner HTTP.sys. Kopplingen är oklar.
• Linux: Kommandon som root över nätverket, utan inloggning, om en MPTCP-lyssnare körs. MPTCP (Multipath TCP) låter en anslutning använda flera nätvägar samtidigt. Enligt Anthropic tog det 48 minuter att kringgå KASLR, ett skydd genom slumpmässiga minnesadresser i kärnan, och därefter ytterligare fem minuter till ett root-skal. Det som nämns är CVE-2026-98432 med CVSS 9,8, ett värde i den översta delen av allvarlighetsskalan från 0 till 10. Enligt källorna finns rättningen sedan den 15 oktober 2026 i Linux huvudgren.

Linuxkedjan kräver vissa förbehåll. Anthropic kopplar kedjan till en MPTCP-lucka och anger CVE-2026-98432. Debian Security Tracker beskriver dock samma CVE som ett fel i IPv4-TCP-koden, närmare bestämt som ett use-after-free vid övergången från en förfrågningssocket till barnsocketen. Kopplingen mellan CVE:n och MPTCP kommer alltså hittills bara från Anthropics text. Det är möjligt att beskrivningarna är ofullständiga eller att kedjan berör flera fel. Belagt är det inte.

Till bedömningen hör tre begränsningar. För det första är andelen mänskligt arbete inte redovisad. Vad en modell klarade på egen hand kan inte kontrolleras utifrån, bara tillverkarnas patchar är synliga. För det andra visar en siffra som 62 CVE:er volym, men inte automatiskt att luckorna utnyttjats i det fria. Det finns inga tecken på det i de lästa texterna. För det tredje finns datumen för Chrome 156 (20 oktober 2026) och för Apple-versionen bara via The Hacker News, primärkällorna har inte hämtats.

Patchcykeln: när luckor hittas snabbare än de distribueras

Att hitta en lucka är bara en del av cykeln. Patchning sker decentraliserat: tillverkare publicerar rättningar, distributioner paketerar dem och driftansvariga installerar dem. Varje steg tar tid. Om modeller hittar fler luckor snabbare och snabbare tar fram exploits ur publicerade rättningar krymper fönstret mellan rättning och utnyttjande. Att härleda en exploit ur rättningen kallas patch-diffing: jämförelsen mellan gammal och ny kod avslöjar var felet låg.

Den tyska förbundsstatens cyberbyrå (Cyberagentur des Bundes) ser för närvarande angriparna i ett övertag. Exploits tas i dag fram på minuter till timmar. För verksamheter utan eget Security Operations Center, alltså utan bevakning dygnet runt, innebär det att larm måste prioriteras efter brådska och att en nödrutin ska finnas redo. Hur ett sådant förlopp kan se ut de första minuterna beskrivs i handlingsplanen för de första 60 minuterna vid ransomware.

Av Anthropic-fallen följer två konsekvenser. Den ena gäller mängden: en enda webbläsarversion innehöll rättningar för 62 rapporterade CVE:er. Den andra gäller tempot: Linuxrättningen fanns i huvudgrenen den 15 oktober 2026, distributionernas paket följde därefter, och när de når en server beror på den driftansvarige. Hur snabbt exploits tas fram efter en rättning blev nyligen tydligt även vid PHP-luckan PHP2Shell.

Av detta kan följande rekommendationer härledas:

• Förkorta den ordinarie cykeln för operativsystem och webbläsare, till exempel varje vecka i stället för varje månad.
• Tvinga fram automatiska webbläsaruppdateringar i stället för att lämna dem åt enskilda användare.
• Inrätta ett andra spår för nödfall som klarar sig utan ändringsrunda.
• Hantera system med internetkontakt först och mät tidsfristerna i dagar i stället för veckor.

En lucka som en modell gör om till en exploit på några timmar väntar inte på nästa Patch Tuesday.

Programvarutillverkare i Europa: vad som ändras i utveckling och rapportering

Tillverkare är både mottagare och mål för sådana fynd. Enligt sin egen rapport använde Anthropic samordnat offentliggörande med 90 dagars frist och 45 dagars tillägg. Det förutsätter att tillverkare kan ta emot rapporter, bedöma dem och snabbt åtgärda dem. Till det hör en kontakt för säkerhetsrapporter som går att hitta, till exempel via en security.txt-fil, kapacitet för bedömningen, rättningar även för äldre stabila grenar och en releaserytm som tillåter små rättningar.

Rättsligt är Cyber Resilience Act relevant. Enligt EU-kommissionen gäller rapporteringsskyldigheterna för aktivt utnyttjade sårbarheter från den 11 september 2026 och de övriga huvudskyldigheterna från den 11 december 2027. De exakta fristerna i lagtexten har inte kontrollerats här och nämns därför inte.

Det är oklart om europeiska tillverkare får samma tillgång till försvarsmodeller. För tillfället finns alternativ: granska andra leverantörers program, använda fritt tillgängliga verktyg och bygga in kodskanningar i den egna pipelinen. Slutsatsen här är att utgå från att programvaran genomsöks av kraftfulla modeller. Den som själv söker först hittar felen före tredje part.

Vad företag kan göra nu: Linuxserver, inventering, patchfrister

Kommandona är standardverktyg och bör testas i den egna miljön innan de används i produktion.

Kontrollera Multipath TCP

Enligt kärndokumentationen är MPTCP opt-in: applikationer måste begära det via sockettypen IPPROTO_MPTCP. Det kan dock också tvingas fram utifrån, till exempel med verktyget mptcpize. Ett exempel: sedan Go 1.24 använder lyssnare som skapas via net.ListenConfig MPTCP som standard under Linux. Om en server kan vara drabbad beror alltså på den programvara som körs. Inställningen net.mptcp.enabled gäller per nätverksnamnrymd och står som standard på 1.

Kontrollsteg på en server:

sysctl net.mptcp.enabled
ss -Mlnp
uname -r
dpkg -l 'linux-image*'
apt policy linux-image-amd64

Det första kommandot visar inställningen, det andra listar lyssnande MPTCP-socketar med process (flaggan -M visar bara MPTCP-socketar, processnamn kräver root-behörighet) och det tredje den körande kärnversionen. De två sista kommandona (för Debian och system som härletts från det) visar installerade kärnpaket och deras paketversion. Körs en Go-tjänst där kan den dyka upp som MPTCP-lyssnare. Saknas sysctl-nyckeln net.mptcp.enabled stöder kärnan inte MPTCP.

På grund av den oklara CVE-kopplingen räcker det inte att stänga av MPTCP. Det avgörande är kärnans status, närmare bestämt paketversionen av den installerade kärnan. Avstämningen ser olika ut för olika distributioner: distributioner bakåtporterar ofta rättningar till äldre kärnor, så utdata från uname -r ensamt (till exempel 6.1.x) säger ingenting om rättningsstatus. Det som gäller är paketversionen i respektive distributions säkerhetsmeddelande. Debian Security Tracker anger som åtgärdade under bookworm versionerna 6.1.190-1 (security) respektive 6.12.113-1~deb12u1, under trixie 6.12.113-1 och under forky 7.2.12-1. Det är läget enligt trackern och bör hämtas på nytt samma dag som åtgärden genomförs. För Ubuntu, Red Hat och SUSE har säkerhetssidorna inte hämtats och måste kontrolleras på egen hand. Efter kärnuppdateringen krävs en omstart, utom vid live-patchning.

Webbläsare, operativsystem, inventering

• Webbläsare: Chrome till version 156 eller senare, iOS och iPadOS till 26.5.2 eller senare, installera Windows-uppdateringar. Tvinga fram uppdateringsregler i enhetshanteringen.
• Frister: webbläsare och operativsystem med internetkontakt först, frister i dagar. Siffrorna är vägledande.
• Inventering: Utan en inventarielista vet ingen vilken kärna som körs på vilken server eller om det finns en MPTCP-lyssnare. Listan är grunden för all snabb patchning.

AI på försvararsidan: kodskanning vid pull requests

En pull request är ett förslag till ändring i källkoden som granskas innan det tas in. Med kodskanning vid pull requests granskas varje ändring automatiskt även av en modell. Det kompletterar statisk analys och mänsklig granskning men ersätter dem inte. Träffar måste bedömas av människor, eftersom falsklarm är vanliga och kostar tid.

Typiska inställningar är en skanning vid varje pull request, blockering vid kritiska fynd och dokumentation av undantag. Dataskydd och sekretess måste klargöras i förväg: källkoden skickas till en leverantör. Avtal och Zero Data Retention, alltså löftet att indata inte sparas, bör granskas. Fairwind-sidan nämner det alternativet för Argon i Gemini Enterprise. En produktrekommendation undviks här medvetet.

Utifrån sett

En webbplatskontroll visar vilka tjänster och tekniker en webbplats avslöjar utåt. Säkerhetskontrollerna kompletterar det med synliga konfigurationsbrister. Inget av dem ersätter kärnuppdateringar eller kodgranskning, men de ger en bild utifrån av det slag som även en angripare skulle ha.

Slutsats: vinna tid i stället för att jaga verktyg

Tillgången till de kraftfullaste modellerna är ojämnt fördelad, och för alla andra märks effekten genom fler fynd och snabbare patchar. Försvarare vinner tid genom kortare cykler, en välskött inventering och automatiska granskningar i utvecklingen.

Fortfarande öppet är datumet för allmänheten, reglerna för Europa och den oberoende mätningen av Googles uppgifter, och det bör följas vidare.