Hoe vinden AI-agents op grote schaal zero-days?

In maart en april 2026 beschreven beheerders van de Linux-kernel en curl dezelfde verandering: veel meer van de beveiligingsmeldingen die mensen met AI-tools maakten, wezen nu op echte bugs. Willy Tarreau schreef op LWN dat de beveiligingslijst van de kernel zo'n twee jaar eerder 2 of 3 meldingen per week kreeg, en sinds begin 2026 5 tot 10 per dag, de meeste terecht. Beveiligingsonderzoeker Thomas Ptacek legt uit waarom: "Je kunt voor een LLM-agent geen beter probleem bedenken dan exploitonderzoek."

Wat veranderde er begin 2026?

Vanaf de tweede helft van 2024 kregen open-sourceprojecten steeds meer "AI-slop" binnen: met AI-tools geschreven meldingen over bugs die niet bestonden. curl stopte met zijn bugbounty, die mensen betaalde voor gemelde kwetsbaarheden, op 31 januari 2026. Hoofdontwikkelaar Daniel Stenberg schreef dat in eerdere jaren ruim 15% van de meldingen een echte kwetsbaarheid bleek, en dat dat aandeel in 2025 onder de 5% zakte. Naast zwakkere meldingen van mensen wees hij "een explosie van AI-slop" aan als oorzaak.

Enkele weken later was het beeld omgeslagen. Linux-kernelbeheerder Greg Kroah-Hartman zei op 26 maart 2026 tegen The Register: "Er gebeurde een maand geleden iets, en de wereld sloeg om. Nu krijgen we echte meldingen." Volgens hem zien alle beveiligingsteams van open-sourceprojecten dezelfde omslag, en weet niemand waardoor: "Of veel meer tools zijn een stuk beter geworden, of mensen dachten: laten we hier eens naar gaan kijken."

Op 2 april schreef Stenberg op Mastodon dat de "tsunami van AI-slop" was overgegaan in "eerder een ... gewone tsunami van beveiligingsmeldingen", met "veel echt goede" ertussen.

Waarom zijn AI-agents zo goed in het vinden van kwetsbaarheden?

Ptacek, die 15 jaar lang zijn brood verdiende met het vinden en misbruiken van kwetsbaarheden, zette zijn argument op 30 maart 2026 uiteen in "Vulnerability Research Is Cooked". Hij verwacht dat veel van het belangrijke werk zal bestaan uit het richten van een AI-agent op de broncode, met de vraag om zero-days te zoeken: lekken die de makers nog niet kennen, zodat ze nul dagen hebben gehad om ze te dichten.

Zijn redenering begint bij wat een groot taalmodel al weet. Nog voordat het één token van jouw code ziet, bevat het verbanden uit grote hoeveelheden broncode: het weet of de KVM-hypervisor van Linux verbonden is met het hrtimer-subsysteem, workqueue of perf_event. In de gewichten van het model zitten ook de gedocumenteerde bugklassen waarop exploitontwikkeling voortbouwt, zoals stale pointers, verkeerd afgehandelde integers, type confusion en allocator grooming.

Kwetsbaarheden vinden komt volgens Ptacek neer op "patroonherkenning van bugklassen en het oplossen van voorwaarden voor bereikbaarheid en misbruik": komt hier een bekend soort bug voor, en kan een aanvaller die bereiken en misbruiken? Of een exploit werkt, is een simpele test die slaagt of faalt. En "een agent verveelt zich nooit en zoekt eeuwig door als je dat vraagt".

Software werd tot nu toe deels beschermd doordat de aandacht van topexperts schaars is, vindt hij. Ervaren onderzoekers richten zich op waardevolle doelwitten zoals browsers, terwijl veel onopvallende software "nog nooit een fuzzer heeft gezien", een tool die een programma bestookt met willekeurige invoer. Agents maken die aandacht goedkoop.

Hoe eenvoudig kan de methode zijn?

Ptacek beschrijft de aanpak van Nicholas Carlini van het Frontier Red Team van Anthropic. Carlini draait een kort script dat Claude Code voor elk bronbestand in een repository dezelfde prompt geeft: zoek een misbruikbare kwetsbaarheid, begin bij dit bestand, schrijf een rapport. Daarna geeft hij elk rapport terug aan Claude Code, met de vraag te controleren of de bug echt te misbruiken is. Volgens Ptacek is het slagingspercentage van die pijplijn "bijna 100%". Gericht op het contentmanagementsysteem Ghost vond de methode een breed misbruikbare SQL-injectie.

Het Frontier Red Team van Anthropic meldde op 5 februari 2026 dat Claude Opus 4.6 meer dan 500 ernstige kwetsbaarheden in open-sourcesoftware had gevonden en gevalideerd. Het model werkte in een virtuele machine met standaardtools zoals debuggers en fuzzers, zonder speciale instructies en zonder eigen harness, de extra software die het model specialistische kennis had kunnen geven. Om niet bij te dragen aan de slop controleerden de eigen beveiligingsonderzoekers van Anthropic, en later ook externe onderzoekers, elke bug voordat die werd gemeld.

Wat betekent dit voor beheerders?

Op de kernellijst moest het team volgens Tarreau extra beheerders inschakelen. Hij zag ook dagelijks iets wat nooit eerder was gebeurd: dubbele meldingen, dezelfde bug gevonden door twee mensen met net iets andere tools. Stenberg schreef dat hij er "uren per dag" mee bezig was. Kroah-Hartman zei dat de kernel met zijn grote, verspreide team de toename aankon, en dat alle open-sourceprojecten er hulp bij nodig hadden. De bugs zelf noemde hij "kleine dingen, niets groots".

De kernel zet ook aan de ontvangende kant AI in. Volgens Kroah-Hartman draaide Sashiko, een reviewtool die Google bouwde en aan de Linux Foundation schonk, in maart 2026 op bijna alle kernelpatches. Hij voegde eraan toe dat de tool niet alles vindt, en dat sommige opmerkingen ervan niet kloppen.

Ptacek ziet het grotere risico buiten de projecten met veel geld. Als bugs vinden bijna niets meer kost, hoeven aanvallers hun doelwitten niet meer te kiezen: besturingssystemen, databases, routers en printers worden allemaal het bekijken waard. Zulke systemen draaien "in elke regionale bank en ziekenhuisketen in Noord-Amerika", en om ze te patchen moet er soms iemand naartoe rijden en op een fysieke knop drukken.

Is dit een blijvende verandering?

Ptacek vindt de uitkomst al vastgelegd ("locked in") en verwacht dat agents full-chain exploits gaan maken: meerdere bugs die samen één complete aanval vormen. Geen van de ervaren onderzoekers die hij raadpleegde, betwistte de richting. Een vriend bij een grote leverancier betwijfelde of het zo makkelijk zou gaan, omdat verdediging in lagen, zoals geharde allocators, sandboxes, de scheiding tussen gebruiker en kernel, en virtualisatie, exploits moeilijk te bouwen houdt, ook als agents kwetsbaarheden makkelijk vinden. Een andere onderzoeker wijst erop dat modellen gedocumenteerde technieken herhalen, en dat veel technieken nooit zijn opgeschreven.

Tarreau wist niet hoe lang het tempo zou aanhouden. Hij vermoedde dat bugs sneller werden gemeld dan ze werden geschreven, zodat de vloed deels een lange achterstand zou kunnen zijn die wordt weggewerkt. Kroah-Hartman zei dat de toename "niet afneemt".

Wat moeten beheerders en ontwikkelaars doen?

• Scan je eigen code voordat een ander het doet. Volgens Ptacek laten sommige onderzoekers al eenvoudige agent-loops over oude doelwitten lopen, en vinden ze zo ernstige bugs die ze eerder hadden gemist.
• Geef melders een duidelijk, besloten kanaal. Sinds het einde van de bugbounty neemt curl beveiligingsmeldingen aan via de private vulnerability reporting van GitHub, en betaalt het er niets meer voor.
• Laat AI meelezen met wat binnenkomt, zoals de kernel met Sashiko doet, en laat een mens controleren wat de tool aanwijst.
• Update vaker. Tarreau verwacht dat embargo's, de afgesproken wachttijd voordat een bug openbaar wordt, verdwijnen, en noemt regelmatig updaten "de enige verstandige manier om veilig te blijven".
• Reken op onderhoud. Software die wordt uitgebracht en daarna aan zijn lot wordt overgelaten, zal volgens Tarreau moeten veranderen, omdat elk stuk software een doelwit wordt.