De Threat Intelligence Group van Google (GTIG) zegt voor het eerst een dreigingsactor te hebben gezien die een zero-day-exploit gebruikte waarvan zij geloven dat die met hulp van een AI-model is gebouwd. De exploit was een Python-script dat tweefactorauthenticatie omzeilde op een open-source administratietool. Google hield zowel de actor als het product achter om de fix te beschermen.
De kop schrijft zichzelf, maar wijst de verkeerde kant op. De echte verschuiving is niet slimmere phishing of beter geschreven lokmiddelen. Het is het verkorten van de exploitcyclus: AI laat de tijd en vaardigheid ineenstorten die nodig zijn om een kwetsbaarheid te vinden en die om te zetten in een werkende exploit. Voor iets dat zo groot en zo blootgesteld is als een webbrowser verandert dat de rekensom.
Wat Google daadwerkelijk vond
Het rapport van GTIG, gepubliceerd op 2026-05-11, is voorzichtig over wat het beweert. Het zegt niet dat AI de exploit schreef. Het zegt dat Google op basis van de structuur van de code met hoge mate van zekerheid meent dat de actor een AI-model gebruikte om de bug te ontdekken en bruikbaar te maken. De aanwijzingen zaten in de broncode: docstrings als uit een handboek, een vreemd tutorialachtige Pythonic-opmaak en een gehallucineerde CVSS-score die geen menselijke onderzoeker zou verzinnen. Google merkt ook op dat zijn eigen model, Gemini, waarschijnlijk niet het gebruikte model was.
Hetzelfde rapport beschrijft drie andere patronen die de moeite waard zijn om los te koppelen van de hype:
- AI-ondersteunde exploitgeneratie, waarbij modellen het onderzoek en de bewapening versnellen in plaats van de aanvaller te vervangen.
- Meer autonome malware, nog experimenteel, waarbij een payload tijdens de uitvoering een model bevraagt om de systeemstatus uit te lezen en de volgende actie te kiezen in plaats van vaste logica te volgen. Google verwijst naar families in onderzoeksfase zoals PROMPTSPY en PROMPTFLUX.
- Geïndustrialiseerd misbruik van premium modeltoegang, waarbij criminelen middleware en geautomatiseerde aanmeldpijplijnen gebruiken om gebruikslimieten te omzeilen.
Niets hiervan is "AI vervangt hackers." Het is "AI maakt de trage, dure onderdelen sneller." Dat is het deel waar verdedigers rekening mee moeten houden.
De echte verschuiving is het verkorten van de exploitcyclus
Het vinden van een ernstige kwetsbaarheid en het schrijven van een betrouwbare exploit is altijd het dure deel van een aanval geweest. Het vergt zeldzame vaardigheid, tijd en geduld. Phishingtekst was nooit het knelpunt.
Het verkorten valt dat knelpunt aan. Wanneer een model een actor van middenniveau helpt om onbekende broncode te lezen, een zwak codepad te herkennen en een werkende proof of concept op te zetten, wordt de kloof tussen "een bug bestaat" en "een bug wordt op grote schaal misbruikt" kleiner. De zaak van Google is één datapunt. De trendlijn is het verhaal: sneller onderzoek, snellere bewapening, hoger operationeel tempo.
Dat is het belangrijkst voor software die enorm is, snel verandert en overal aanwezig is. De browser is het duidelijkste voorbeeld.
Waarom de browser het grootste doelwit is
Browsers zijn enorme systemen met meerdere componenten
Een moderne browser is niet één programma. Chromium, de engine achter Chrome, Edge, Brave, Opera en vele andere, telt tientallen miljoenen regels code en haalt meer dan 200 third-party libraries binnen. Veel daarvan zijn open source en worden onderhouden door aparte teams:
- V8 voert JavaScript en WebAssembly uit.
- Blink rendert de pagina.
- Skia tekent 2D-graphics.
- ANGLE vertaalt grafische aanroepen voor de GPU.
- libwebp decodeert WebP-afbeeldingen.
- WebRTC verwerkt realtime audio en video.
Elk daarvan is aanvalsoppervlak. Eén geheugenbug in een ervan kan uitlopen op uitvoering van code op afstand. Open source is een sterkte voor review en snelheid, maar het betekent ook dat de exacte code die een aanvaller bestudeert dezelfde code is die naar miljarden apparaten wordt verzonden.
Nieuwe functies komen voortdurend uit, en nieuwe zero-days volgen
Chrome brengt ongeveer elke vier weken een nieuwe mijlpaal uit, en het webplatform blijft groeien: nieuwe API's, nieuwe codecs, nieuwe GPU-paden. Meer functies betekenen meer code, en meer code betekent meer bugs. Het resultaat is constant, niet incidenteel. Google patchte in 2024 rond de negen actief misbruikte Chrome zero-days en in 2025 rond de acht, en die clusteren zich in dezelfde complexe componenten:
- V8 type confusion: CVE-2025-10585 en CVE-2025-13223.
- ANGLE- en GPU-validatie: CVE-2025-6558.
- Skia en V8 opnieuw in 2026: CVE-2026-3909 en CVE-2026-3910, beide in het wild misbruikt.
Zero-days in de browser zijn geen zeldzame gebeurtenissen om je op te schrap te zetten. Het zijn een terugkerende toestand om omheen te ontwerpen.
Eén open-source-component, een explosieradius door het hele ecosysteem
De duidelijkste waarschuwing kwam van libwebp. CVE-2023-4863 was een heap buffer overflow in die ene library voor het decoderen van afbeeldingen, te misbruiken met één geprepareerd WebP-bestand. Het kreeg eerst de score 8.8 als Chrome-bug, en werd opnieuw beoordeeld op 10.0 zodra de reikwijdte werd begrepen, omdat libwebp overal zit. (Een tweede identifier, CVE-2023-5129, werd later als duplicaat samengevoegd.)
Dezelfde bug trof Chrome, Firefox, Signal, 1Password, Telegram en, cruciaal, bijna elke applicatie die op Electron is gebouwd. Eén library, één fout, en de explosieradius besloeg een groot deel van de software die mensen elke dag gebruiken.
Zero-days stoppen niet bij het browsertabblad
Hier wordt het verkorten gevaarlijk. De browser-sandbox bestaat met een reden: een tabblad hoort een vijandige omgeving te zijn, afgeschermd van de rest van je machine. Maar dezelfde engine die je browser aandrijft, zit ook in desktopapps.
Electron bundelt zijn eigen kopie van Chromium zodat webontwikkelaars apps kunnen bouwen die als native aanvoelen. VS Code, Slack, Discord en de desktopapp Claude van Anthropic zijn allemaal Electron-applicaties. Elk draagt zijn eigen Chromium-build, en die builds lopen achter op upstream. Wanneer Google een V8-zero-day patcht, blijft elke Electron-app kwetsbaar totdat die de fix binnenhaalt en een update uitbrengt, wat weken kan duren.
Combineer nu twee feiten. Ten eerste erven deze apps de zero-days van de browser. Ten tweede draaien ze buiten de browser-sandbox, vaak met volledige toegang tot het bestandssysteem, en in het geval van AI-coding-agents met de mogelijkheid om shell-commando's uit te voeren. Een browser-engine-bug die in een tabblad een ingeperkt, gesandboxed probleem zou zijn, wordt veel ernstiger binnen een lokale app die je bestanden kan lezen en code kan uitvoeren. De libwebp-zaak bewees al dat Electron-apps deze fouten erven. Naarmate AI-desktopapps en coding-agents zich verspreiden, blijft de populatie aan software met hoge rechten en Chromium aan boord op machines van ontwikkelaars groeien, en daarmee ook de opbrengst van één browser-engine-zero-day.
Vergiftigde dependencies worden uitgevoerd in dezelfde browser
Het verkorten heeft een tweede front: de supply chain. Dezelfde AI die exploitonderzoek versnelt, versnelt het vinden en misbruiken van zwakke dependencies, en dependency-code draait precies op de plek die je vanaf de server niet kunt zien.
Het npm-ecosysteem maakte dit concreet in 2025. Op 2025-09-08 phishten aanvallers een maintainer en pushten kwaadaardige versies van enorm populaire packages, waaronder chalk en debug. De geïnjecteerde payload was een op de browser gerichte crypto-clipper: het haakte in op window.ethereum en netwerkaanroepen om stilletjes walletadressen in de browser van het slachtoffer te verwisselen. Dagen later compromitteerde de zelfreplicerende worm "Shai-Hulud" honderden packages en stal die inloggegevens van ontwikkelaars terwijl hij zich verspreidde.
Dit is het Magecart-patroon veralgemeniseerd. Kwaadaardige third-party code heeft geen geheugenbug nodig. Die hoeft alleen maar te laden, en zodra dat gebeurt, draait hij in dezelfde context als je pagina, met toegang tot formulieren, tokens en alles wat de gebruiker typt.
Waarom scannen vooraf niet genoeg is
De meeste beveiligingsbudgetten zitten nog vóór de uitrol: statische analyse, dependency-scanning, een reviewpoort, en dan uitbrengen. Die controles zijn noodzakelijk, maar ze delen één blinde vlek. Ze inspecteren een momentopname van code die je al kent, op een moment voordat die draait.
Zero-days zijn per definitie de bugs die nog niemand heeft gecatalogiseerd. Gecompromitteerde dependencies veranderen vaak nadat ze de review zijn gepasseerd, waarbij schone code bij een latere laadbeurt wordt ingeruild voor kwaadaardige code. Third-party scripts werken zichzelf in productie bij zonder te vragen. En het verkorten van de exploitcyclus verkleint het venster tussen het bekend worden van een fout en het gebruik ervan. Het scannen van een momentopname vóór release kan geen payload vangen die pas tijdens de uitvoering verschijnt, in de browser, nadat je pipeline klaar is.
Die kloof is geen tekortkoming van de tooling. Het is een tekortkoming in zicht. Je kunt je niet een weg naar zicht scannen op wat er wordt uitgevoerd in de browsersessie van iemand anders.
Wat je deze week kunt doen
- Inventariseer elk third-party script op je site, inclusief de scripts die door andere scripts worden geladen.
- Monitor scriptgedrag tijdens de uitvoering, niet alleen bij de uitrol: wat er laadt, wat er is veranderd, wat elk script leest en waar het data naartoe stuurt.
- Scherp de patchcadans aan voor browsers en voor de Electron-apps die je team gebruikt. Behandel een Chromium-zero-day als een deadline voor VS Code, Slack en vergelijkbare tools, niet alleen voor de browser.
- Dwing een Content Security Policy af die beperkt vanwaar scripts mogen laden en waarheen data mag worden verzonden.
- Sla alarm bij afwijkingen: een bekend script dat plotseling een nieuw domein benadert, betaalvelden leest of zijn payload wijzigt.
Hoe cside hierin past
cside bewaakt de laag die de rest van je stack niet kan: de live browsersessie. Het geeft je runtime-zicht op elk script dat op je site wordt uitgevoerd, wat het laadt, hoe het is veranderd sinds de vorige versie, welke data het aanraakt en waar die data naartoe gaat.
Dat is van belang in een wereld van verkorte exploitcycli, omdat het niet afhankelijk is van het vooraf kennen van de exploit. Wanneer een vertrouwd script zich anders begint te gedragen, wanneer een dependency na de uitrol nieuwe code inruilt, of wanneer een payload formuliergegevens begint te exfiltreren, is de verandering zichtbaar tijdens de uitvoering, zelfs als de onderliggende kwetsbaarheid splinternieuw is. Scannen vooraf vertelt je over de code die je hebt uitgebracht. cside vertelt je wat er op dit moment daadwerkelijk draait.
Begin met client-side beveiliging voor volledige runtime-monitoring van scripts, of Privacy Watch om precies te zien wat third-party scripts verzamelen en versturen.
Verder lezen over cside
- Supply-chaincompromittering van de AppsFlyer Web SDK
- De grootste Magecart-aanvallen uit de geschiedenis (tot nu toe)
- Supply-chainaanval op het web via getrojaniseerde jQuery
- Hoe gecompromitteerde third-party scripts AI-agents prompt-injecties kunnen toedienen
- Best practices voor het beveiligen van third-party scripts
Per 2026-06-03. De aantallen Chrome zero-days en de GTIG-bevindingen weerspiegelen de rapportage die op die datum beschikbaar was.
Over de auteur
Simon Wijckmans is de oprichter en CEO van cside. Hij schrijft over client-side beveiliging, dreigingen op browserniveau, third-party scripts en het standaardisatiewerk dat nodig is om het web veiliger te maken.
