Datum: 3-11-2026

AI vindt de lekken nu, en je patchvenster is geijkt op een wereld die niet meer bestaat

De slop is sinds het voorjaar voorbij; het volume niet. De helft van de door AI gevonden kwetsbaarheden geeft code-uitvoering op afstand, tegen 26 procent van de rest, en bij een lek dat een AI-agent vond zag Google binnen vier dagen misbruik. Wat dat verandert aan je patchproces, en waarom één op de 431 het cijfer is dat de rest in verhouding zet.

Volg ons op LinkedIn

AI vindt de lekken nu, en je patchvenster is geijkt op een wereld die niet meer bestaat

TL;DR

Oktober was de maand van de bewustwording. In diezelfde maand verschoof er iets anders: AI vindt nu de kwetsbaarheden, en niet meer als rommel. Dat probleem is sinds het voorjaar voorbij. Wat ervoor in de plaats kwam is lastiger, veel meer meldingen, van hogere kwaliteit. De helft van de lekken die volgens Google door AI zijn gevonden geeft code-uitvoering op afstand, tegen 26 procent van de rest. En bij een lek dat een AI-agent zelf vond, zag Google binnen vier dagen na publicatie het eerste misbruik. Dit stuk gaat niet over AI maar over je patchvenster, dat geijkt is op een wereld waarin een mens het lek eerst moest vinden.

Twee kritieke lekken op één dag was geen pech

Vorige week schreef ik over 21 oktober: twee kritieke kwetsbaarheden in PHP en op dezelfde dag een in Node.js, en de crisisoefening die daar ongevraagd uit voortkwam. Ik noemde dat toen een week die niemand had ingepland. Dat was de vriendelijke lezing. De cijfers over dit jaar zeggen iets anders: dat die week geen uitschieter was maar het nieuwe normaal, en dat je er niet vanaf komt met een extra oefening per jaar.

Terwijl de bewustwordingscampagnes liepen, veranderde er iets in de pijplijn waar kwetsbaarheden uit komen. Dat is minder zichtbaar dan een phishingmail in een nieuwsbrief, en het raakt je planning harder.

De rommel is voorbij. Het volume niet.

Wat vrijwel iedereen nog in zijn hoofd heeft, is januari. Het curl-project stopte zijn bug bounty, en curl is een van de meest gebruikte stukjes software ter wereld, waarschijnlijk ook in jouw omgeving. Daniel Stenberg, de beheerder, schreef dat het aandeel meldingen dat een echte kwetsbaarheid bleek in 2025 onder de vijf procent zakte: "Not even one in twenty was real." De reden om de beloning af te schaffen was "an attempt to remove the incentives for submitting made up lies".

Dat beeld is achterhaald. In april schreef hij dat het voorbij was: "The slop situation is not a problem anymore." Het aandeel bevestigde kwetsbaarheden stond weer op vijftien tot zestien procent, het niveau van vóór AI, bij ongeveer het dubbele aantal meldingen. En op 22 oktober, vorige week: "Since spring 2026 the slop reports are practically gone. Our current challenge is much harder: high volume, high quality." Over de meldingen van de afgelopen maanden schreef hij dat er bij elke enkele AI in het spel was.

Dat is niet theoretisch gebleven. Op 14 oktober kreeg curl een kwetsbaarheid van ernst HIGH binnen, CVE-2026-92392, een use-after-free bij HTTP/2-uploads die tot code-uitvoering kan leiden. Gevonden door een scanner van Anthropic. De vorige HIGH in curl was van oktober 2023. Dezelfde dag publiceerde Stenberg de uitkomst van een audit door Aisle, waarvan hij schrijft dat die inmiddels vijfendertig gepubliceerde curl-CVE's heeft opgeleverd, meer dan welke groep of persoon ooit.

De vraag of AI bruikbare bevindingen oplevert, is daarmee niet meer de interessante vraag. De interessante vraag is wat een paar keer zoveel vindcapaciteit doet met iedereen die die software gebruikt. Dat ben jij.

Twee cijfers die je planning raken

Vijftig tegen zesentwintig

Google Threat Intelligence Group publiceerde op 30 september een analyse over kwetsbaarheden in het AI-tijdperk. Eén cijfer eruit: "Exactly 50% of all AI-discovered vulnerabilities result in Remote Code Execution (RCE), compared to just 26% across the broader CVE ecosystem."

Code-uitvoering op afstand is het soort fout waar een aanvaller werkelijk iets aan heeft. Dat de helft van de door AI gevonden lekken in die categorie valt en van de rest een kwart, betekent dat de samenstelling van wat er op je afkomt is verschoven. Je afspraak dat kritieke bevindingen binnen dertig dagen gepatcht zijn, is ooit gemaakt op een mix waarin de meeste bevindingen geen shell opleverden.

Google zet er zelf twee voorbehouden bij, en die horen erbij. Het gaat om kwetsbaarheden die zij "likely AI discovered" konden noemen, toeschrijven gebeurt met de hand, want er is geen veld voor in een CVE. En de post noemt het verschil zelf "an early indicator rather than an established trend", waarbij een deel van de verklaring waarschijnlijk is hoe onderzoeksprogramma's hun scanners richten. Lees het dus als een richting, niet als een getal voor je risicoregister.

Vier dagen

Het tweede cijfer is concreter. CVE-2026-1731 was een kwetsbaarheid in BeyondTrust Privileged Remote Access en Remote Support, waarmee een aanvaller zonder in te loggen commando's kon uitvoeren. Hij werd volgens Google gevonden door een onderzoeksagent die dat zelfstandig deed, Hacktron AI.

Wat erna gebeurde is het punt: "within four days of public disclosure, GTIG observed a threat cluster exploiting this vulnerability, followed by five additional threat clusters within seven days of public disclosure." Vier dagen tot de eerste, een week tot er zes groepen mee bezig waren.

Zet dat naast je eigen afspraken. Een patchvenster van dertig dagen voor kritieke bevindingen is in dat tempo geen venster maar een gat. En het is niet alleen tempo: het aantal gepubliceerde kwetsbaarheden per maand ging volgens dezelfde analyse van 5.045 in januari 2026 naar 10.740 in augustus.

En nu het cijfer dat de rest in verhouding zet

Van alle kwetsbaarheden die in 2026 openbaar werden, zag Google er 0,23 procent daadwerkelijk misbruikt worden. Ongeveer één op de 431. Wie dit stuk tot hier heeft gelezen en nu zijn hele lijst wil afwerken, doet precies het verkeerde.

Google waarschuwt er zelf bij dat de aantallen opgeblazen zijn. Automatische CVE-uitgifte in open source doet veel: kwetsbaarheden met "Linux Kernel" in de beschrijving leverden tussen januari en augustus alleen al zo'n 5.000 CVE's op, zonder dat er één misbruikte zero-day bij zat.

Het risico zit dus niet in het aantal. Het zit in het verschil tussen die stroom en een overzicht dat je niet binnen een uur kunt bevragen. Dat is dezelfde conclusie als op 21 oktober, toen de vraag "draaien wij dit, en in welke versie" voor veel organisaties het struikelblok was en niet het patchen. Welke bevinding je laat liggen is een besluit met een eigenaar, geen achterstand.

Welke van die 431 dan?

Dat is de vraag die overblijft, en er liggen twee openbare lijsten die hem voor een groot deel beantwoorden. CISA houdt de KEV bij: kwetsbaarheden waarvan is vastgesteld dat ze in het wild misbruikt worden. Staat er iets in, dan is het geen inschatting meer. EPSS van FIRST doet het andersom en geeft per CVE een kans dat er binnen dertig dagen misbruik van komt, elke dag opnieuw berekend en gratis op te halen als CSV of via een API.

Allebei hebben ze een gebrek dat je moet kennen voor je erop gaat sturen. KEV loopt per definitie achter: die vertelt je wat er al gebeurd is, en bij vier dagen tot het eerste misbruik kun je daar niet op wachten. EPSS is een kans en geen oordeel, een lage score op iets dat aan het internet staat en code-uitvoering geeft, is geen reden om het te laten liggen.

En geen van beide weet of jij het draait. Daarom vervangen ze de vorige alinea niet maar vullen ze hem aan: samen maken ze van tienduizend bevindingen er een paar tientallen, en daarna moet je nog steeds binnen een uur kunnen zeggen of een daarvan bij jou draait. Dat is waarom dit lijstje korter maken je niet helpt zolang die vraag openstaat.

Je eigen AI-laag staat er nu ook tussen

Een onderdeel van dezelfde analyse dat makkelijk wordt gemist: niet alleen vindt AI kwetsbaarheden, er komen er ook veel in AI-software zelf naar buiten. Google telde 2.076 AI-gerelateerde CVE's tussen januari 2025 en augustus 2026, waarvan meer dan 1.500 in 2026 alleen. De tussenlaag die agenten aan elkaar knoopt is daarin de grootste groep, de helft van alle AI-gerelateerde fouten, met een stijging van 347 procent dit jaar. De post noemt visuele workflowbouwers als Flowise en Langflow met naam.

Heeft iemand bij jou een agent in een proces gezet, dan staat die tussenlaag nu in hetzelfde rijtje als je webservers: software met een versienummer, aan het internet, met rechten in je omgeving. Dat is geen AI-vraagstuk maar gewoon beheer, en het is precies het soort afhankelijkheid dat je niet zelf beheerst.

Eén nuance van Google erbij, omdat hij de andere kant op wijst: misbruik van een zero-day in AI-infrastructuur hebben ze nog niet gezien. Wat ze wel zien is dat verse, gepubliceerde lekken in blootgestelde tussenlagen snel worden opgepakt.

Vijf dingen die je hierop verandert

Hang je drempel aan blootstelling, niet aan een score. Aan het internet en code-uitvoering: uren, niet dagen. De rest naar exposure. Vier dagen tot het eerste misbruik laat geen maandcyclus toe. Reken erop dat er in die uren nog geen patch is; dan is de vraag niet hoe snel je patcht maar wat je dichtzet, de dienst, de functie, of de toegang ernaartoe.
Zorg dat je binnen een uur weet wat je draait, en in welke versie. Niet een jaarlijkse inventarisatie, maar een lijst die iemand om elf uur 's avonds kan bevragen. Dat is op 21 oktober het struikelblok geweest, niet de patch. Begin niet bij alles: begin bij wat van buiten bereikbaar is, want dat is een korte lijst en het is de lijst die telt.
Scheid het besluit van de patch. Leg vast wie een dienst uit de lucht mag halen en bij welke drempel, met een naam en een vervanger, en of dat ook geldt voor het tweede besluit dezelfde dag. Dat is precies de bevoegdheid die je nodig hebt op de dag dat er nog geen patch is.
Neem je AI-tussenlaag in hetzelfde proces op als je webservers. Flowise, Langflow, een eigen agent: versie bijhouden, blootstelling kennen, rechten begrenzen.
Meet niet het aantal CVE's. Eén op de 431 wordt misbruikt; een teller die oploopt zegt dus weinig. Meet van hoeveel van je internet-diensten je de versie weet. Dat getal hoort honderd procent te zijn en is dat bijna nooit.

Waar dit volgens mij naartoe gaat

Dit is mijn verwachting en geen cijfer. Stenberg kondigde op 20 oktober aan dat curl vanaf 26 oktober meldingen van ernst LOW en MEDIUM in het openbaar wil, als gewone GitHub-issues; alleen HIGH en CRITICAL blijven besloten. Dat is wat het eruit ziet als triagecapaciteit opraakt en iemand daar eerlijk over is.

Doen meer beheerders dat, dan komen lichtere bevindingen eerder openbaar te staan. Voor een aanvaller is dat materiaal, en voor jou betekent het dat de periode tussen "het is bekend" en "het wordt gebruikt" verder krimpt. Niet voor de kritieke zaken, die blijven besloten, maar voor de grote middenmoot waar je nu een maand voor uittrekt.

Veelgestelde vragen

Hoe kom ik aan dat overzicht binnen een uur?

Niet met een project van een half jaar, want dan is het er precies op tijd voor de volgende reeks. Begin bij wat van buiten bereikbaar is: welke namen en adressen van jou staan aan het internet, welke software draait daarachter, en in welke versie. Bij de meeste organisaties zijn dat enkele tientallen regels en geen duizenden. Zet er één eigenaar op en een datum waarop het klopte. Een lijst die voor tachtig procent klopt en die je vanavond kunt openen is meer waard dan een volledige inventarisatie die er over een half jaar is.

Moeten we nu een AI-scanner aanschaffen?

Waarschijnlijk niet als eerste. Deze cijfers gaan over het vinden van fouten in software die je gebruikt, niet die je zelf schrijft. Ontwikkel je zelf, dan is zo'n scanner in de pijplijn het overwegen waard, Stenberg schrijft dat de reviews van curl slechter zouden zijn zonder. Maar bij de meeste organisaties zit de rem op het overzicht en op de bevoegdheid, niet op het vinden. Koop in die volgorde.

Geldt dit ook als wij niets met AI doen?

Ja, en dat is de kern. De verandering zit stroomopwaarts, bij wie de lekken vindt in de software die jij draait. Of jij AI gebruikt doet daar niets aan af; het bepaalt alleen of punt vier van het lijstje hierboven ook voor je geldt.

Is dat vijftig procent niet gewoon een meetartefact?

Deels mogelijk, en Google zegt dat zelf: een vroege indicatie, waar de manier waarop onderzoeksprogramma's hun scanners richten in meeweegt. Gebruik het als richting. Het cijfer waar je planning wél op mag draaien is de vier dagen, want dat is waargenomen misbruik en geen toeschrijving.