Nep-CVE’s, AI-gegenereerde rapporten en de noodzaak van verificatie

Het wordt steeds goedkoper om overtuigende kwetsbaarheidsrapporten op te stellen, met grotere gevolgen voor softwareonderhouders en beveiligingsteams. In juli 2026 werden zes Common Vulnerabilities and Exposures (CVE’s) voor SQLite gepubliceerd. Twee daarvan kregen een ernstscore van 9,8. De rapporten leken legitiem: ze beschreven fouten in de geheugenveiligheid en bevatten technische toelichtingen en proof-of-conceptcode.

Maar onderzoekers van JFrog ontdekten dat sommige functies waarnaar in de rapporten werd verwezen, niet voorkwamen in de getroffen versies. Bovendien reproduceerde geen van de proof-of-concepts (PoC’s) de vermeende kwetsbaarheden. Op de eigen CVE-pagina van SQLite staat momenteel dat deze zes meldingen geen bugs betreffen; de CVE-registraties werden later afgewezen.

Het probleem beperkt zich niet tot SQLite. Daniel Stenberg, de man die curl onderhoudt, schatte vorig jaar dat ongeveer 20% van de binnenkomende beveiligingsmeldingen het resultaat was van AI-rommel. De CVE Numbering Authority (CNA) van GitHub ontving in mei 2026 bijna 4.000 CVE-aanvragen; dat is ongeveer een vertienvoudiging van het volume ten opzichte van het voorgaande jaar. GitHub schreef deze toename niet toe aan AI en meldde ook geen daling van de kwaliteit van inzendingen, maar de enorme volumegroei onderstreept hoe zwaar het proces voor het melden van kwetsbaarheden wordt belast.

AI maakt het eenvoudiger om gedetailleerde claims over kwetsbaarheden op te stellen, maar het kost tijd om vast te stellen of die claims legitiem zijn. En zodra een CVE in beveiligingsfeeds en openbare databases terechtkomt, betekent een correctie van de oorspronkelijke registratie niet automatisch dat ook elke kopie wordt aangepast. Daardoor wordt het steeds belangrijker om onderscheid te maken tussen een gemelde kwetsbaarheid en een technisch geverifieerde kwetsbaarheid.

Wat is een ‘nep-CVE’?

Mensen gebruiken de term ‘nep-CVE’ geregeld voor een CVE die waarschijnlijk onjuist is gemeld. Maar ‘nep’ betekent niet dat iemand opzettelijk misleidt. De melding kan bijvoorbeeld voortkomen uit statische analyse die een validatiecontrole over het hoofd ziet of invoer ten onrechte interpreteert als iets waar een aanvaller controle over heeft. Een rapport kan een bestaande functie in detail beschrijven, maar een ongeldig aanvalspad aanvoeren. Er kan een identificatienummer (CVE-ID) worden toegewezen dat later weer wordt ingetrokken als de gemelde situatie in werkelijkheid geen kwetsbaarheid blijkt te zijn. Dat is iets anders dan een bewust verzonnen rapport.

Een geschil is evenmin een nep-CVE. Een leverancier kan de bevindingen van een onderzoeker over de misbruikbaarheid, de grenzen van de dreiging of de vraag of een functie bedoeld was om niet-vertrouwde invoer te verwerken, betwisten. Maar een geschil bewijst niet dat de onderzoeker zich heeft vergist. En een afgewezen CVE betekent niet per se dat de melding verzonnen was; de afwijzing kan bijvoorbeeld komen doordat het om een duplicaat gaat of om administratieve redenen. Een CVE-ID is geen onafhankelijke technische verificatie, maar de sector moet echte meldingen serieus nemen.

Waarom nep-CVE’s een probleem zijn

Een van de problemen die we zien, is dat mensen AI gebruiken om kwetsbaarheidsrapporten te genereren zonder de bevindingen goed te controleren. Zulke rapporten kunnen gedetailleerde technische toelichtingen, verwijzingen naar code en zelfs PoC’s bevatten, waardoor ze legitiem kunnen lijken. Maar zoals we zagen bij de SQLite-CVE’s, bestonden sommige van de genoemde functies niet eens in de getroffen versies.

GitHub meldde in 2026 een aanzienlijke toename van het aantal meldingen van kwetsbaarheden, maar schreef die toename niet toe aan AI en meldde evenmin een daling van de kwaliteit van de inzendingen. De zorg is dat meer meldingen ook meer onderzoek vergen, ongeacht of de bevindingen terecht zijn.

Wie kwetsbaarheidsmeldingen heeft getrieerd, herkent de praktische moeilijkheid meteen. Een AI-model kan een verdachte API-aanroep identificeren, een mogelijk aanvalsscenario schetsen en snel een professioneel ogend rapport opstellen. Om vast te stellen of dat scenario uitvoerbaar is, kan het nodig zijn de exacte release te controleren, de control flow te volgen, na te gaan hoe gegevens de functie bereiken, een testomgeving op te zetten en de vermeende exploit uit te voeren. Dat proces is hetzelfde, of de melding nu klopt of niet, en kan kostbaar zijn.

Nep-CVE’s kunnen ook reputatieschade veroorzaken. Een aankondiging van een kwetsbaarheid kan zich snel verspreiden via scannerfeeds, beveiligingsdatabases en zoekresultaten. Een daaropvolgende correctie bereikt echter mogelijk niet hetzelfde publiek. Zelfs nadat een melding is betwist of afgewezen, kunnen leveranciers zich moeten verantwoorden tegenover klanten die het oorspronkelijke bericht hebben gezien.

Ook bestaat het risico dat echte kwetsbaarheden over het hoofd worden gezien of later worden onderzocht, omdat teams tijd besteden aan het onderzoeken van onjuiste meldingen. Wanneer onderhouders en beveiligingsteams over beperkte middelen beschikken, is elk uur dat wordt besteed aan het weerleggen van een vals-positieve melding een uur dat aan het onderzoeken van een echt beveiligingsprobleem had kunnen worden besteed.

De strijd aangaan met automatisering

Veel onderzoekers behandelen de nieuwe stortvloed aan meldingen nog steeds handmatig, maar dat is niet vol te houden. Automatisering blijkt een grote hulp bij het controleren van claims over kwetsbaarheden aan de hand van de daadwerkelijk getroffen release en configuratie. Dit zijn de vijf vragen die je moet stellen:

• Zijn de voorwaarden voor een aanval geloofwaardig, met inbegrip van de configuratie en machtigingen?
• Bestaat de vermeende functie in de getroffen versie?
• Kan een aanvaller de kwetsbare code bereiken? Bepaal of de relevante code onder de getroffen omstandigheden kan worden uitgevoerd en of een aanvaller invoer kan aanleveren die de code bereikt.
• Kunnen testers het gedrag reproduceren in een gecontroleerde test of met een PoC?
• Heeft het waargenomen gedrag de beveiligingsimpact die in het advies wordt beschreven?

Tools met AI-agents kunnen testomgevingen opzetten, codepaden analyseren, PoC’s genereren en bewijs van uitvoering vastleggen ter beoordeling. Ze kunnen niet automatisch elke claim beoordelen. Zelfs als een kwetsbaarheid echt is, kan een PoC mislukken als de omgeving onvolledig is of de trigger niet klopt. Testers kunnen een crash reproduceren zonder de beweerde exploiteerbaarheid aan te tonen. Daarom blijft menselijk beoordelingsvermogen van cruciaal belang. Deze tools kunnen teams echter dichter bij een reproduceerbaar antwoord brengen voordat een melding nog meer tijd opslokt bij engineering, kwetsbaarheidsbeheer en klantenondersteuning.

De overvloed aan meldingen in het CVE-ecosysteem aanpakken

Geen enkel beknopt beleid zal het probleem van nep-CVE’s zomaar oplossen. Het zou wel helpen om sterker bewijs bij meldingen te eisen en de status van reproduceerbaarheid duidelijker aan te geven. Ook zou het helpen om betwiste registraties duidelijker te behandelen en gegevens verderop in de keten sneller te corrigeren. Onderzoekers moeten worden aangemoedigd om hun met AI ondersteunde bevindingen vóór indiening te valideren.

Beveiligingsteams en leveranciers moeten zich richten op het onderzoeken van het bewijs. Een kritieke CVE-score zegt niet of een kwetsbaar codepad in hun omgeving bereikbaar is. Het feit dat een PoC mislukt, betekent niet dat alles in orde is. En de toekenning van een CVE-ID ontslaat teams niet van het technische werk dat nodig is om een probleem te begrijpen.

AI vergroot het vermogen om kwetsbaarheden te ontdekken, maar maakt het ook mogelijk om overtuigend ogende, maar onjuiste claims te formuleren. In een wereld waarin het aantal meldingen blijft toenemen, moeten organisaties investeren in verificatie. Dat houdt in dat ze tests opzetten, resultaten reproduceren, aannames controleren en bewijs gemakkelijker te beoordelen maken. Beveiligingstests met AI-agents kunnen hierbij een belangrijke rol spelen.