Gemini 4 Carbon: als de sterkste lekkenzoekers eerst bij staten terechtkomen

Google heeft Gemini 4 Carbon gepresenteerd, een model dat volgens eigen zeggen bij het vinden en misbruiken van beveiligingslekken duidelijk beter presteert dan zijn voorganger. Eerst krijgen Amerikaanse inlichtingendiensten het, later geselecteerde verdedigers, voor alle anderen is er geen datum. Hier wordt geduid wat aangetoond is, wat alleen een bewering van de fabrikant blijft en wat bedrijven en softwareleveranciers in Europa aan patchcycli en controleprocessen kunnen veranderen.

Op 28 oktober 2026 presenteerde Google Gemini 4 Carbon, slechts vier weken na Gemini 4 Argon. De prestatiecijfers in de aankondiging zijn opgaven van de fabrikant en zijn van buitenaf niet te controleren. Interessanter is de volgorde waarin het model verspreid moet worden: eerst overheidsinstanties, dan geselecteerde verdedigers, een moment voor iedereen ontbreekt. Een dag voor de aankondiging van Google, op 27 oktober 2026, publiceerde Anthropic bovendien een rapport waarin een ongepubliceerd onderzoeksmodel vijf exploitketens gebouwd zou hebben. Alle vijf zijn volgens Anthropic en The Hacker News inmiddels verholpen, waarbij bij het Android-geval een openbare registratie ontbreekt en bij het Windows-geval de toewijzing onduidelijk is.

Eerst komen de benchmarkgegevens en hun grenzen aan bod, dan de fasen van de toegang en de vraag wat deze asymmetrie betekent voor organisaties buiten de VS. Daarna volgen de ketens van Anthropic met hun patchstatus, de gevolgen voor patchcycli en softwareleveranciers en een lijst met praktische stappen, waaronder de controle van een Linux-server. De situatie kan snel veranderen.

Gemini 4 Carbon: wat Google beweert en wat te controleren is

De gegevens over Gemini 4 Carbon komen van Google en de berichtgeving daarover.

Volgens Google haalt Carbon in de benchmark Exploitgym bijna 55 procent; Argon kwam op 42 procent en lag daarmee net achter het concurrerende model GPT-6 Astra. In de benchmark SEC-bench Pro scoort Carbon ruim 88 procent en ligt daarmee volgens het bericht voor op deze concurrent. Bij CWE-bench, een test voor het dichten van beveiligingslekken, wordt 71 procent genoemd. Een benchmark is een gestandaardiseerde set taken waarmee modellen vergelijkbaar worden gemeten. Hoe de drie tests precies zijn opgebouwd, is hier niet onderzocht. Daarom blijft de beschrijving bewust bij wat het bericht zegt.

Ook andere uitspraken komen van Google: tot nu toe zou geen enkele poging tot prompt injection geslaagd zijn, dat wil zeggen manipulatie van het model via binnengesmokkelde instructies. Het model zou bovendien minder hallucineren en vaker om verduidelijking vragen. Onafhankelijke metingen daarvan zijn er niet. Terzijde worden prijzen genoemd van 4 dollar per miljoen invoertokens en 20 dollar per miljoen uitvoertokens, bij de start met 50 procent korting. Naar de huidige maatstaven is dat in vergelijking niet goedkoop, maar – in absolute bedragen – ook niet echt duur.

Benchmarkscores beantwoorden een smalle vraag: hoe goed lost een model voorbereide taken op? Hoe goed het werkt in gegroeide software met uitzonderingen, erfenissen uit het verleden en onduidelijke verantwoordelijkheden, laten ze maar beperkt zien. Voor de duiding volstaat daarom een nuchtere lezing. Als de cijfers van Google kloppen, is de afstand tot de voorganger bij het misbruiken van lekken groot. Of dat in de praktijk ook zo is, blijkt pas wanneer derden het model kunnen testen.

Gefaseerde toegang: eerst inlichtingendiensten, dan Fairwind, later iedereen

Wat echt nieuw is aan Gemini 4 Carbon, is de weg naar de gebruiker. Blijkbaar onderwerpt Google zich aan een instructie van het Witte Huis om nieuwe AI-modellen eerst alleen toegankelijk te maken voor Amerikaanse inlichtingendiensten en geselecteerde gebruikers. Daaruit ontstaan drie fasen.

De eerste fase bestaat uit Amerikaanse inlichtingendiensten en door hen goedgekeurde gebruikers. Of en hoe zij het model inzetten, is niet aangetoond. Aangetoond is alleen de beoogde volgorde. De tweede fase is het programma Fairwind, waarmee geleidelijk geselecteerde cyberverdedigers en andere vertrouwde partners moeten aansluiten. De derde fase is het grote publiek. Google belooft beschikbaarheid „binnenkort”, maar noemt geen datum. Bij Argon zaten er twee weken tussen de presentatie en de vrijgave voor betalende gebruikers.

Hoe Fairwind werkt, beschrijft Google DeepMind op de programmapagina. Er worden meer dan 650 partners genoemd. Deelnemen kunnen overheden en nationale cyberautoriteiten, beheerders van kritieke infrastructuur, centrale technologieplatforms en academische labs. Aanvragers worden gescreend. Vereist zijn onder meer phishingbestendige meervoudige authenticatie, logging en defensief gebruik; doorgeven is verboden. Op de pagina wordt echter Argon als model genoemd, niet Carbon. Of Carbon onder dezelfde voorwaarden valt, is onbekend. Regels voor Europa noemt de pagina niet.

Voor Europese bedrijven ontstaat daardoor een asymmetrie die in eerste instantie een kwestie van tijd is. Staten en grote platforms krijgen krachtige hulpmiddelen eerder dan het mkb en softwareleveranciers. Hoe groot dat gat is, weet niemand. Twee vragen zijn te onderscheiden: wie beslist over de toegang, en wat volgt daaruit voor organisaties die er niet bij horen? Blijkbaar beslist het Witte Huis. Voor organisaties buiten de VS rest het om af te wachten en zich zo in te richten dat de voorsprong van anderen zo weinig mogelijk schade aanricht.

Het tegenargument verdient gewicht. Gefaseerde toegang kan misbruik beperken, en verdedigers met vroege toegang vinden fouten mogelijk vóór aanvallers. Open blijft of aanvallers vergelijkbare mogelijkheden elders krijgen, bijvoorbeeld bij andere aanbieders of met vrij beschikbare modellen. Aangetoond is dat niet, het zou speculatie zijn. Voor de planning volstaat de vaststelling dat aannames over een blijvende voorsprong van de verdedigers riskant zijn.

Organisaties die niet in aanmerking komen, kunnen volgens de Fairwind-pagina de tool CodeMender met openbaar beschikbare modellen gebruiken. Dat is hier niet zelf getest. Het laat wel zien dat er ook zonder toegang tot de hoogste fase wegen zijn naar AI-ondersteund foutzoeken.

Wat Anthropic heeft laten zien: vijf exploitketens en hun patchstatus

Een exploit is een stuk code dat een beveiligingslek misbruikt. Een exploitketen koppelt meerdere lekken, zodat van een kleine fout een volledige aanval wordt. Het Frontier Red Team van Anthropic beschrijft op 27 oktober 2026 dat een ongepubliceerd intern onderzoeksmodel met aanvankelijke instructies en weinig menselijke betrokkenheid werkende ketens zou hebben gebouwd. Het model wordt niet bij naam genoemd en is een ander model dan Carbon. Beide berichten wijzen echter in dezelfde richting.

De vijf gevallen op een rij, telkens volgens de genoemde bronnen:

• Chrome: één paginabezoek is genoeg om code buiten de sandbox uit te voeren. De sandbox is de beschermlaag die webinhoud scheidt van de rest van het systeem. De keten combineert vier lekken, waaronder geheugenfouten in de JavaScript-engine V8, een race condition (een fout die afhangt van de timing van parallelle processen) en een use-after-free (toegang tot geheugen dat al is vrijgegeven). Anthropic meldde 62 CVE's, dus openbaar genummerde kwetsbaarheidsregistraties, allemaal kritiek of hoog, waaronder volgens Anthropic 13 sandbox-uitbraken. De fix zit in Chrome 156.
• Safari: lees- en schrijftoegang tot browsergeheugen, de same-origin policy wordt omzeild. Volgens The Hacker News verholpen in iOS en iPadOS 26.5.2.
• Android: toegang tot gegevens op een vergrendelde, gestolen Pixel 9 via USB. Fysieke toegang is nodig. Volgens Anthropic heeft Google het lek verholpen; een openbare registratie werd volgens The Hacker News niet gevonden.
• Windows: een denial-of-service via HTTP/3. Anthropic beschrijft een lek in de kernel, The Hacker News verwijst naar een CVE waarvan de beschrijving HTTP.sys noemt. De toewijzing is onduidelijk.
• Linux: commando's als root via het netwerk, zonder aanmelding, als er een MPTCP-listener draait. MPTCP (Multipath TCP) stelt een verbinding in staat om meerdere netwerkpaden tegelijk te gebruiken. Volgens Anthropic duurde het omzeilen van KASLR, een bescherming door willekeurige geheugenadressen in de kernel, 48 minuten, daarna waren nog vijf minuten nodig tot de root-shell. Genoemd wordt CVE-2026-98432 met CVSS 9,8, een waarde in het hoogste bereik van de ernstschaal van 0 tot 10. De fix staat volgens de bronnen sinds 15 oktober 2026 in de hoofdtak van Linux.

Bij de Linux-keten zijn kanttekeningen nodig. Anthropic koppelt de keten aan een MPTCP-lek en noemt CVE-2026-98432. De Debian Security Tracker beschrijft dezelfde CVE echter als een fout in de IPv4-TCP-code, namelijk als use-after-free bij de overgang van een request-socket naar de child-socket. De koppeling tussen de CVE en MPTCP komt dus tot nu toe alleen uit het artikel van Anthropic. Mogelijk zijn beschrijvingen onvolledig of raakt de keten meerdere fouten. Aangetoond is het niet.

Bij de duiding horen drie grenzen. Ten eerste is het aandeel menselijk werk niet uitgesplitst. Wat een model alleen presteerde, is van buitenaf niet te controleren; alleen de patches van de fabrikanten zijn zichtbaar. Ten tweede laat een getal als 62 CVE's massa zien, maar niet automatisch misbruik in het wild. Daarvoor zijn er in de gelezen teksten geen aanwijzingen. Ten derde zijn de gegevens over Chrome 156 (20 oktober 2026) en over de Apple-versie alleen via The Hacker News beschikbaar; de primaire bronnen zijn niet geraadpleegd.

Patchcyclus: als lekken sneller gevonden dan uitgerold worden

Het vinden van een lek is maar een deel van de cyclus. Patchen verloopt decentraal: fabrikanten publiceren fixes, distributies verpakken ze, beheerders installeren ze. Elke stap kost tijd. Als modellen meer lekken sneller vinden en uit gepubliceerde correcties sneller exploits afleiden, krimpt het venster tussen fix en misbruik. Dat afleiden uit de fix heet patch diffing: de vergelijking van oude en nieuwe code verraadt waar de fout zat.

Het Duitse federale cyberagentschap (Cyberagentur) ziet aanvallers momenteel in het voordeel. Exploits ontstaan tegenwoordig binnen minuten tot uren. Voor bedrijven zonder eigen Security Operations Center, dus zonder dag en nacht bemande monitoring, betekent dat: meldingen op urgentie indelen en een noodprocedure klaar hebben. Hoe zo'n procedure er in de eerste minuten uit kan zien, staat in het draaiboek voor de eerste 60 minuten bij ransomware.

Uit de gevallen van Anthropic volgen twee gevolgen. Het ene betreft de hoeveelheid: één enkele browserrelease bevatte fixes voor 62 gemelde CVE's. Het andere betreft het tempo: de Linux-correctie stond op 15 oktober 2026 in de hoofdtak, de pakketten van de distributies volgden daarna, en wanneer ze op een server aankomen, hangt af van de beheerder. Hoe snel exploits na een fix ontstaan, werd onlangs ook duidelijk bij het PHP-lek PHP2Shell.

Daaruit zijn de volgende aanbevelingen af te leiden:

• De reguliere cyclus voor besturingssystemen en browsers verkorten, bijvoorbeeld wekelijks in plaats van maandelijks.
• Automatische browserupdates afdwingen in plaats van ze aan de individuele gebruikers over te laten.
• Een tweede spoor voor noodgevallen inrichten dat zonder wijzigingsronde werkt.
• Systemen met internetcontact als eerste behandelen en termijnen in dagen in plaats van weken meten.

Een lek dat een model in een paar uur tot exploit maakt, wacht niet op de volgende Patch Tuesday.

Softwareleveranciers in Europa: wat er verandert bij ontwikkeling en melding

Leveranciers zijn tegelijk ontvanger en doelwit van zulke vondsten. Anthropic gebruikte volgens eigen rapport gecoördineerde openbaarmaking met een termijn van 90 dagen en 45 dagen extra. Dat veronderstelt dat leveranciers meldingen kunnen aannemen, beoordelen en snel verhelpen. Daarbij horen een vindbaar contactpunt voor beveiligingsmeldingen, bijvoorbeeld via een security.txt-bestand, capaciteit voor de beoordeling, correcties ook voor oudere stable-takken en een releaseritme dat kleine fixes toelaat.

Juridisch is de Cyber Resilience Act relevant. Volgens de Europese Commissie gelden de meldplichten voor actief misbruikte kwetsbaarheden vanaf 11 september 2026, de overige hoofdverplichtingen vanaf 11 december 2027. De precieze termijnen in de wettekst zijn hier niet gecontroleerd en worden daarom niet genoemd.

Open is of Europese leveranciers dezelfde toegang tot verdedigingsmodellen krijgen. Voorlopig blijven er alternatieven: programma's van andere aanbieders bekijken, vrij beschikbare tools gebruiken en codescans in de eigen pipeline inbouwen. De eigen conclusie luidt: ga ervan uit dat de software door krachtige modellen wordt doorzocht. Wie zelf als eerste zoekt, vindt de fouten vóór derden.

Wat bedrijven nu kunnen doen: Linux-servers, inventaris, patchtermijnen

De commando's zijn standaardtools en moeten vóór productief gebruik in de eigen omgeving worden getest.

Multipath TCP controleren

Volgens de kerneldocumentatie is MPTCP opt-in: applicaties moeten het aanvragen, via het sockettype IPPROTO_MPTCP. Het kan echter ook van buitenaf worden afgedwongen, bijvoorbeeld met de tool mptcpize. Een voorbeeld: sinds Go 1.24 gebruiken listeners die via net.ListenConfig ontstaan onder Linux standaard MPTCP. Of een server getroffen kan zijn, hangt dus af van de software die erop draait. De schakelaar net.mptcp.enabled geldt per netwerk-namespace en staat standaard op 1.

Controlestappen op een server:

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

Het eerste commando toont de schakelaar, het tweede somt luisterende MPTCP-sockets inclusief proces op (de optie -M toont alleen MPTCP-sockets, procesnamen vereisen rootrechten), het derde de draaiende kernelversie. De laatste twee commando's (voor Debian en daarvan afgeleide systemen) tonen geïnstalleerde kernelpakketten en hun pakketversie. Draait daar een Go-dienst, dan kan die als MPTCP-listener verschijnen. Ontbreekt de sysctl-sleutel net.mptcp.enabled, dan ondersteunt de kernel MPTCP niet.

Vanwege de onduidelijke CVE-toewijzing volstaat het niet om MPTCP uit te schakelen. Doorslaggevend is de kernelstand, preciezer de pakketversie van de geïnstalleerde kernel. De vergelijking verschilt per distributie: distributies backporten fixes vaak naar oudere kernels, zodat de uitvoer van uname -r alleen (bijvoorbeeld 6.1.x) niets zegt over de fixstatus. Bepalend is de pakketversie in het beveiligingsbericht van de betreffende distributie. De Debian Security Tracker noemt als verholpen onder bookworm de versies 6.1.190-1 (security) respectievelijk 6.12.113-1~deb12u1, onder trixie 6.12.113-1 en onder forky 7.2.12-1. Dat is de stand volgens de tracker en moet op de dag van uitvoering opnieuw worden opgevraagd. Voor Ubuntu, Red Hat en SUSE zijn de beveiligingspagina's niet geraadpleegd; die moeten zelf worden gecontroleerd. Na de kernelupdate is een herstart nodig, behalve bij live patching.

Browsers, besturingssystemen, inventaris

• Browsers: Chrome naar versie 156 of hoger, iOS en iPadOS naar 26.5.2 of hoger, Windows-updates installeren. Updatebeleid afdwingen in het apparaatbeheer.
• Termijnen: browsers en besturingssystemen met internetcontact eerst, termijnen in dagen. De getallen zijn een richtlijn.
• Inventaris: zonder inventarislijst weet niemand welke kernel op welke server draait en of er een MPTCP-listener bestaat. De lijst is de basis van elk snel patchen.

AI aan de kant van de verdediger: codescan bij pull requests

Een pull request is een voorstel tot wijziging van de broncode dat vóór overname wordt gecontroleerd. Een codescan bij pull requests laat elke wijziging automatisch ook door een model controleren. Dat vult statische analyse en menselijke review aan, maar vervangt ze niet. Treffers moeten door mensen worden beoordeeld, want valse alarmen zijn gebruikelijk en kosten tijd.

Gangbare instellingen zijn een scan bij elk pull request, blokkeren bij kritieke vondsten en documentatie van uitzonderingen. Privacy en vertrouwelijkheid moeten vooraf worden geregeld: de broncode gaat naar een aanbieder. Het contract en Zero Data Retention, dus de toezegging dat invoer niet wordt opgeslagen, moeten worden gecontroleerd. De Fairwind-pagina noemt deze optie voor Argon bij Gemini Enterprise. Een productaanbeveling wordt hier bewust vermeden.

Blik van buitenaf

Een websitecheck laat zien welke diensten en technieken een website naar buiten prijsgeeft. De security-checks vullen dat aan met zichtbare configuratiefouten. Geen van beide vervangt kernelupdates of codecontrole, maar ze leveren een blik van buitenaf zoals ook een aanvaller die zou hebben.

Conclusie: tijd winnen in plaats van hulpmiddelen achternalopen

De toegang tot de sterkste modellen is ongelijk verdeeld; voor alle anderen komt het effect via meer vondsten en snellere patches. Verdedigers winnen tijd door kortere cycli, een bijgehouden inventaris en automatische controles in de ontwikkeling.

Open blijven de datum voor het grote publiek, de regels voor Europa en de onafhankelijke meting van de gegevens van Google, die verder gevolgd moeten worden.