AI Verzon een Kritiek Lek, en de CVE-Databank Geloofde Het

Begin augustus 2026 dook er een “kritiek” beveiligingslek op in SQLite, de databasesoftware die in miljoenen apps en apparaten zit. Onderzoekers van JFrog ontdekten dat het lek niet bestond: het was verzonnen door een AI-model. Niet alleen dat ene lek. Van de 55 kwetsbaarheidsrapporten die één GitHub-account in vier dagen tijd publiceerde, waren er 54 compleet fictief. Toch haalden meerdere van die nep-lekken de officiële CVE-databank, het systeem dat bedrijven wereldwijd gebruiken om te bepalen welke patches prioriteit krijgen. Voor elke KMO die vertrouwt op automatische scans en patch-adviezen is dat geen technisch detail, maar een reden om even stil te staan.

Wat is er precies gebeurd?

Een nieuw, onopvallend GitHub-account met de naam “programmervuln” publiceerde tussen eind juli en begin augustus 2026 in slechts vier dagen tijd 55 kwetsbaarheidsrapporten. Zes daarvan gingen over SQLite, met CVSS-scores tussen 7,5 en 9,8, wat neerkomt op “hoog” tot “kritiek”. De rapporten beschreven zogenaamde use-after-free bugs, een type geheugenfout die aanvallers kan laten binnendringen.

Beveiligingsonderzoekers van JFrog gingen de rapporten na en vonden telkens dezelfde problemen: functies die in de genoemde SQLite-versie helemaal niet bestonden, regelnummers die niet konden kloppen, en proof-of-concepts die bij testen geen enkele crash veroorzaakten. Geen van de zes stond op de officiële beveiligingspagina van SQLite zelf, meldt JFrog Research. Ook SQLite-ontwikkelaars en Red Hat konden de lekken niet reproduceren.

Toen JFrog de andere 49 rapporten van hetzelfde account bekeek, bleek het patroon breder: ze gingen over de beeldbewerkingsbibliotheek libraw en de audiobibliotheek ESP32-audioI2S. Van alle 55 rapporten samen bleek er uiteindelijk maar één een echte bug te beschrijven, verpakt in ongeverifieerde CVE-metadata. De andere 54 waren pure verzinsels, schrijft The Register.

Hoe kwam dit door de mazen van het net?

Het antwoord is ongemakkelijk simpel: er is geen verplichte controle. MITRE en de meeste andere organisaties die CVE-nummers uitdelen, werken op een “honor system”. Wie een kwetsbaarheid meldt, wordt vertrouwd op zijn woord. Er is geen standaardstap waarbij iemand de proof-of-concept effectief moet uitvoeren voor een CVE-nummer wordt toegekend.

Zo kreeg CVE-2026-51302, het meest besproken van de zes SQLite-rapporten, gewoon een CVE-nummer van MITRE op 27 juli. Pas na onderzoek van JFrog, SQLite-ontwikkelaars en Red Hat werd het op 31 juli ingetrokken en kreeg het de status “REJECTED” in de NVD. Het Nederlandse NCSC had intussen al een eigen waarschuwing gepubliceerd op basis van dat nummer, en moest die op 3 augustus intrekken met de vermelding dat het lek “vermoedelijk door een llm gehallucineerd” was, meldt Security.nl op basis van de bijgewerkte NCSC-advisory.

MITRE erkent zelf dat 2026 een moeilijk jaar is geworden voor iedereen die kwetsbaarheidsdata maakt of gebruikt, precies door de opmars van AI-tools die overtuigende maar valse rapporten kunnen produceren. Het team achter het CVE-programma zegt samen te werken met andere partijen om dit op te lossen, maar een kant-en-klare oplossing is er nog niet.

Zes lekken, één patroon

Wat betekent dit voor jou als KMO?

Vraag: Moet ik nu twijfelen aan elke patch-melding die ik krijg? Nee, paniek is niet nodig. De grote, gevestigde bronnen zoals patch-meldingen van Microsoft, je besturingssysteem of je antivirusleverancier blijven betrouwbaar. Wees vooral kritisch bij losse CVE-nummers of “kritieke lekken” die je alleen via social media of een onbekende bron ziet opduiken, zonder bevestiging van de softwaremaker zelf.

Vraag: Gebruikt mijn IT-partner of scanner deze data? Waarschijnlijk wel, want vrijwel elke vulnerability scanner en elk patch-managementsysteem trekt gegevens uit de NVD of vergelijkbare feeds. Vraag je IT-partner gerust hoe zij omgaan met CVE’s die nog niet bevestigd zijn door de softwaremaker zelf, en of ze effectief testen voor ze aan de alarmbel trekken.

Onze mening

Dit is precies het soort verhaal dat het vertrouwen in AI als hulpmiddel schaadt, terwijl AI zelf niet eens het echte probleem is. Het probleem is dat een systeem dat wereldwijd bedrijven vertelt wat ze dringend moeten patchen, draait op een erewoord-systeem uit een tijd waarin niemand in vier dagen tijd 55 overtuigende rapporten kon fabriceren. Dat kan nu wel, met een paar prompts.

Wij vinden het knap werk van JFrog dat dit boven water kwam, en het is goed dat MITRE en NCSC snel handelden om de foute meldingen in te trekken. Maar het toont een structureel probleem: hoe makkelijker het wordt om overtuigende onzin te produceren, hoe belangrijker het wordt dat instanties zoals MITRE en NVD een verificatiestap inbouwen voor ze een CVE-nummer uitdelen. Tot dat gebeurt, is gezond wantrouwen bij elke onbevestigde kwetsbaarheidsmelding geen overdreven voorzichtigheid, maar gewoon nodig.

---

Bronnen

• SQLite Critical CVEs or LLM Slop? - JFrog Research, augustus 2026
• AI slop pollutes the CVE pipeline with fake vulns - The Register, 3 augustus 2026
• NCSC-2026-0268: kwetsbaarheid in SQLite - Nationaal Cyber Security Centrum, bijgewerkt 3 augustus 2026
• ‘Kritiek beveiligingslek’ in SQLite blijkt door AI gehallucineerd te zijn - Security.NL, augustus 2026

Beeldverantwoording

Voor dit onderwerp bestaat geen bruikbaar persbeeld: er is geen productfoto, geen incidentfoto en logo’s van SQLite, GitHub, JFrog of NCSC mogen we niet gebruiken buiten hun officiële merkkit. Daarom kozen we, net als bij eerdere AI-artikels, voor eigen SVG-illustraties in de CyberNinja huisstijl in plaats van een risico op auteursrecht.

• hero-cve-fabriek.svg - CyberNinja.be, eigen werk
• inline-cijfers-slop.svg - CyberNinja.be, eigen werk
• inline-tijdlijn-cve.svg - CyberNinja.be, eigen werk
• inline-vertrouwensketen.svg - CyberNinja.be, eigen werk