NCSC trekt waarschuwing in: SQLite-bug vermoedelijk verzonnen door llm

Het Nederlandse Nationaal Cyber Security Centrum (NCSC) heeft een waarschuwing over een kwetsbaarheid in SQLite ingetrokken omdat die 'door een llm gehallucineerd' was. De use-after-freebug blijkt niet te bestaan, maar is door CVE Numbering Authorities zoals Mitre wel geaccepteerd als kwetsbaarheid.

Het NCSC heeft een advisory bijgewerkt over CVE-2026-51302. Die werd vorige week toegewezen door Mitre, een organisatie die kwetsbaarheden registreert. Het NCSC nam de advisory toen ook over op zijn eigen website, maar heeft die nu bijgewerkt.

"CVE is ingetrokken, de 'kwetsbaarheid' is zeer waarschijnlijk door een llm gehallucineerd", schrijft het NCSC.

Wat is een CVE?

CVE staat voor Common Vulnerabilities and Exposures. Het is een standaard waarmee softwarekwetsbaarheden worden gemeld. In de standaard staat beschreven hoe een bug moet worden beschreven en wat de status daarvan is. CVE's hebben een trackingnummer waarmee ze kunnen worden gevolgd.

The Mitre Corporation beheert de database met CVE's. Andere bedrijven en instanties kunnen zelf CVE's aanmelden en mogen die een nummer geven. In Nederland mag DIVD dat doen, maar ook het NCSC. Deze CVE werd niet door het NCSC toegekend.

Niet reproduceerbaar

Het NCSC verwijst naar een verklaring van de ontwikkelaars op het forum van SQLite. Daar staat dat de gemelde kwetsbaarheid helemaal geen bug blijkt te zijn. Een andere beveiligingsonderzoeker zegt dat de proof-of-concept in de bug niet gereproduceerd kan worden. De broncode van SQLite is ook anders dan wat er in de bugmelding gemeld wordt.

Ook andere ontwikkelaars achter software waarin SQLite zit, zoals Red Hat, zeggen dat de bug niet echt is. De bug is 'fictief', zegt Red Hat. Volgens JFrog Security, dat de bug analyseerde, heeft de 'ontdekker' van de bug die in een GitHub-repo gezet waarin 55 andere fictieve bugs lijken te staan.

Het is niet duidelijk wat er precies fout is gegaan. Het NCSC heeft het over hallucinaties, maar het is niet uit te sluiten dat het gaat om moedwillige misleiding.

Het ingetrokken advies van het NCSC

Mitre faalde

Daardoor moeten autoriteiten als Mitre en het NCSC hun adviezen nu terugtrekken. Vooral van Mitre is dat kwalijk. Hoewel het NCSC CVE's mag toekennen, beheert The Mitre Corporation de database met CVE's. Mitre hoort bugs te verifiëren voordat het die opneemt in de database, of op zijn minst de rapportages van externe partijen (de CNA's) te controleren. Dat is hier niet gebeurd.

Het NCSC mag zelf CVE's toekennen, maar doet dat doorgaans alleen bij bugs die het zelf ontdekt of van Nederlandse beveiligingsonderzoekers doorkrijgt. Het NCSC geeft ook advisory's uit over andere CVE's zoals deze, maar dat doet het als waarschuwing. Bedrijven die de getroffen software dan gebruiken, kunnen via het NCSC op de hoogte blijven van bugs daarin. Het NCSC verifieert die bugs echter niet, maar publiceert ze pas nadat instanties als Mitre dat hebben gedaan.

Geen geld meer

The Mitre Corporation kwam vorig jaar in het nieuws toen bleek dat het geen subsidie van de Amerikaanse overheid meer kreeg. Enkele weken later bleek het toch weer subsidie te krijgen. Het onderstreepte opnieuw dat veel software afhankelijk is van Amerikaanse autoriteiten. Het Europese cybersecurityagentschap Enisa besloot daarom een eigen database met kwetsbaarheden bij te houden, vergelijkbaar met die van Mitre.

Bron: Getty Images (Beeld ter illustratie)

Reacties (42)

[elmuerte]

Er zijn nog wel meer CVEs van dezelfde bron die ingetrokken zijn:

• https://nvd.nist.gov/vuln/detail/CVE-2026-51304
• https://nvd.nist.gov/vuln/detail/CVE-2026-51303
• https://nvd.nist.gov/vuln/detail/CVE-2026-51302 (waar dit artikel over gaat)
• https://nvd.nist.gov/vuln/detail/CVE-2026-51300
• https://nvd.nist.gov/vuln/detail/CVE-2026-51299
• https://nvd.nist.gov/vuln/detail/CVE-2026-51298
• https://nvd.nist.gov/vuln/detail/CVE-2026-51297
• https://nvd.nist.gov/vuln/detail/CVE-2026-51296
• https://nvd.nist.gov/vuln/detail/CVE-2026-51295
• https://nvd.nist.gov/vuln/detail/CVE-2026-51294
• https://nvd.nist.gov/vuln/detail/CVE-2026-51293
• https://nvd.nist.gov/vuln/detail/CVE-2026-51292
• https://nvd.nist.gov/vuln/detail/CVE-2026-51291
• https://nvd.nist.gov/vuln/detail/CVE-2026-51290
• https://nvd.nist.gov/vuln/detail/CVE-2026-51289
• https://nvd.nist.gov/vuln/detail/CVE-2026-51288
• https://nvd.nist.gov/vuln/detail/CVE-2026-51287
• etc.

[RoestVrijStaal]

Wie is het eigenlijk? Is het account van die stoorzender al gedeactiveerd?

Want waarom zou je die persoon nog kunnen vertrouwen dat die wel correcte CVE's aanlevert?

[John Doos]

Best kwalijk, maar dit gaan we natuurlijk vaker zien de komende tijd.

Je zou verwachten dat de kwetsbaarheid + uitbuiting eerst in een sandbox gereproduceerd word voordat die gepubliceert word.

[Jimmy_]

Is natuurlijk bizar om als security instantie niet een procedure te hebben waarbij verificatie een vereiste stap is.

Echter niet geheel onvoorstelbaar; de trend om AI te gebruiken om gezond denk- en handwerk te 'delegeren' zie ik overal groeien.

[Blokker_1999]

verificatie kan natuurlijk niet altijd. Bij FOSS is het relatief eenvoudig om dat gerealiseerd te krijgen omdat broncode inzichtelijk hebben in combinatie met change logs en de omschrijving van een CVE vaak voldoende zijn om te bepalen hoe iets misbruikt kan worden.

Maar als morgen een bug in Windows een label krijgt en die bug is zo erg dat je je POC liever niet in het wild wenst zien te verschijnen wordt het moeilijk om aan de ene kant de ernst door te te geven met behulp van een CVE registratie en aan de andere kant de manier van uitbuiting geheim te houden wanneer je die verplicht gaat moeten delen met externe organisaties.

Zoveel in de IT wereld draait nu eenmaal op vertrouwen en reputatie.

[Fourtrain]

Echter niet geheel onvoorstelbaar; de trend om AI te gebruiken om gezond denk- en handwerk te 'delegeren' zie ik overal groeien.

Ja... maar toch verwacht ik persoonlijk van de grote cybersecurity organisaties eigenlijk dat ze net iets strikter zijn de gemiddelde software boer en niet zonder te kijken maar gewoon shit uit chatgpt/claude/etc kopiëren&plakken. Met dit soort acties kom je als NCSC een beetje prutserig over.

[Reactie gewijzigd door Fourtrain op 3 augustus 2026 13:52]

[demianmonteverd]

Die kennis is niet in voldoende mate aanwezig gezien de hoeveelheid CVE's. Soms is de kennis helemaal niet in zo'n organisatie beschikbaar en soms is deze tijdelijk niet beschikaar (vakanties, etc.). Het is onwerkbaar te verwachten dat een partij als ncsc dit kan opvangen op het nivo dat hier gevraagd wordt. (mijn mening).

[edwinjm]

Bij NCSC weken echt wel slimme mensen met verstand van zaken. Ik ben bang dat hier productie-/geldingsdrang teveel prioriteit kreeg.

[demianmonteverd]

Er werken er vast niet genoeg en ze kunnen vakantie hebben, de hoeveelheid CVE's is toegenomen, werken aan andere projecten, etc. Dat er een paar goede mensen zitten is fijn om te horen in elk geval.

Deze problemen zijn niet nieuw, iedereen die bijv. debian een beetje volgt kent de problemen al. Het zijn dezelfde problemen maar nu bij ncsc. Ze zijn er bij freebsd, debian, overal.

[lecrab]

Het NCSC controleert alleen maar of procedures worden gevolgd. Het informeren is een belangrijke taak, maar ze doet verder niets met de inhoud, zover mijn kennis rijkt. En ja, heb ik ook een mening over :-).

[PdeBie]

Aan de ene kant is reproduceren natuurlijk belangrijk, maar als de aard van een bug dermate ernstig is dat hij momenteel volop misbruikt wordt en wereldwijde economische schade kan veroorzaken dan wil je die ook zo snel mogelijk gepubliceerd hebben.

Liever een false positive dan een lek waardoor er wereld economieën omvallen.

[wiseger]

Teveel vals alarm meldingen leidt to het 'cry wolf' syndroom. En dat is zeer kwalijk.

In het verleden heeft dit al tot vliegrampen geleidt. Piloten die te vaak een valse alarm melding kregen, namen die melding na een tijdje niet meer serieus. Totdat de melding wel serieus was en genegeerd werd, met alle gevolgen van dien.

Hier is dat net zo. Als meer en meer CVE meldingen vals alarm blijken te zijn, dan gaan mensen CVE meldingen minder serieus nemen. 'We hoeven niets te doen, volgende week trekken ze de melding wel weer in' krijg je dan.

[PdeBie]

Ik zeg ook niet dat je elke CVE gelijk moet publiceren, maar vanaf een bepaald risico level zou je kunnen zeggen van: we publiceren hem alvast, maar met de tekst "nog niet geverifieerd". Dan is het aan de gebruikers om te kiezen van "we wachten de verificatie af of we nemen actie".

[demianmonteverd]

Inderdaad. Je wilt het zo snel mogelijk melden, een mitre zou immers al hebben gekeken naar de bug en hebben al een CVE uitgegeven, daarna moet een partij als ncsc snel handelen. Want laten liggen kan gevolgen hebben. De partijen die groot genoeg zijn voor een eigen security met inhoudelijke kennis pakken het daarna wel op, de rest, kan het beste afgaan op wat leveranciers doen qua patching en dankzij de waarschuwing van ncsc zou die laatste groep dus kunnen gaan kijken wat de leverancier er over te vertellen heeft.

Het is sowieso niet zo vreemd om voornamelijk naar de leveranciers te kijken, die hebben immers ook de meeste kennis van hun eigen software. Bij open source ligt het soms wat genuanceerder, zie de discussies rondom de CVE stortvloed vanuit de linux kernel, etc..

[Scriptkid]

momenteel volop misbruikt wordt

Dan is hij dus al getest en werkend bevonden

[Luminair]

Best kwalijk, maar dit gaan we natuurlijk vaker zien de komende tijd.

Misschien wat semantisch gezever van mijn kant, maar bedoelen we niet "best kwalijk, en dit gaan we natuurlijk vaker zien"? Dat dit soort meldingen door middel LLMs komen maakt het volgens mij niet minder kwalijk.

[SunnieNL]

Dat zouden we helemaal niet vaker moeten zien. Normaal proces is dat de CVE afgesloten komt te staan. Dat gebeurd al dan niet met informatie, zoals de lijst advisories op the Zero Day Initiative ( Upcoming Advisories - TrendAI™ Zero Day Initiative™ (ZDI) ).

Dan wordt hij normaal eerst geverifeerd door de vendor / beheerders / CNA. Als die hem goedkeuren dan wordt er een nummer aan de CVE toegekend en wordt de keuze gemaakt hem al volledig openbaar te maken of niet. Het laatste geval wordt vaak gedaan op het moment dat de vendor een patch maakt en zijn klanten eerst informeerd. Dan krijgt de NCSC vaak ook een non-public melding die zij al dan niet door mogen zetten.

Zie ook The CVE Process: How to Identify, Respond to, and Mitigate Vulnerabilities

In dit hele proces lijkt stap 3 volledig overgeslagen hier. Was onze NCSC de CNA hier of was dat een andere partij?

[Reactie gewijzigd door SunnieNL op 3 augustus 2026 14:29]

[demianmonteverd]

mitre

[Navi]

Ik lees het ook meer en meer van beheerders van open source projecten, ze worden overspoelt met AI slop bug fixes, features en andere pull requests. Zoveel dat het een dagtaak wordt om er doorheen te komen.

Kan me voorstellen dat zoiets als dit ook zo'n oorzaak zou kunnen hebben.

[Reactie gewijzigd door Navi op 3 augustus 2026 12:32]

[Snow_King]

Ik werk met een groot open source project, het is echt ondoenlijk aan het worden. Aantal bugs wat gemeld wordt is enorm en soms bestaan ze inderdaad ook echt niet.

[PolarBear]

Tegelijkertijd kan je toch niet volhouden dat AI/LLMs geen plek hebben in development? Kijk AI slop en niet bestaande bugs melden is een enorm probleem voor projecten (of ze nu wel of niet open-source zijn). Maar je zou toch ook een eerste triage door AI moeten kunnen doen?

[Snow_King]

AI en LLMs zijn geweldig! Ik gebruik Claude Fable ook veel voor coding en het werkt echt goed. Wat er met bugreports echter gebeurd is dat het over het hek wordt gesmeten en daarna wordt het project succes gewenst er mee.

Vervolgens beginnen deze researchers continue druk te zetten of er al naar hun report gekeken en is en te dreigen met publiek maken als er niet snel een CVE komt + een patch, vooral wel hun naam vermelden bij het bugreport.

Supergaaf dat we met AI sneller bugs kunnen vinden, maar help dan aub ook met oplossen er van. Open source projecten draaien veel op vrijwilligers en kunnen ook niet even tokens en tijd gaan spenderen aan alles.

[RoestVrijStaal]

Wat je kunt doen, is een video en/of gedetailleerde screenshots vereisen voor bug reports.
Anders block & ban.

[kaas-schaaf]

Het is een van de redenen dat sommige OS organisaties een no-ai policy opnemen. Alle naar LLM ruikende pull-request en bugreports worden gereject. Sommige gaan nog een stap verder en willen ook geen assistentie van LLMs toelaten, maar de wat mildere varianten laten wat hulp toe (zolang de pull request geschreven is en code geen LLM luchtje heeft).

Ik zou er ook gek van worden, ik heb in het verleden voor wat tools wel van die "typo fix" pull requests gekregen. Die gaan ook meteen de prullenbak in aangezien het geen noemenswaardige bijdrage is en enkel bedoelt voor bots en mensen om accepted pull requests te krijgen (mogelijk als cv boost). Dit hele LLM verhaal tegenwoordig maakt dat veel erger.

[SuperDre]

Dus je wilt dan zeggen dat he typis niet fixed?

[The Zep Man]

De betrokken instanties moeten hiermee voorzichtig zijn. Anders neemt straks niemand meer een gerapporteerde kwetsbaarheid serieus totdat er een publieke, makkelijk te testen PoC wordt vrijgegeven. Je kan zonder brand maar een beperkt aantal keer "brand" roepen voordat niemand meer naar je luistert.

[Reactie gewijzigd door The Zep Man op 3 augustus 2026 12:42]

[LootersV]

Stel je een echte bug voor maar de LLM hallucineert dat het gehallucineerde juist gehallucineerd is.. dan zit het Nederlandse Nationaal Cyber Security Centrum met een probleem lijkt mij?

[Mizgala28]

Kwestie van tijd voor we dat zien gebeuren.

Als het niet al gebeurd.

[morphje]

Dit is simpelweg ook een probleem/uitdaging van de CVE database.

Grote cooperaties beheren zelf hun eigen CVE's en hebben eerste publicatierecht en mogen ook CVE's weren. Met dat systeem van de zelfkeurende slager krijg je dus onderrapportage. En dan heb je opensource, die heeft geen eigen CVE beheer, dus iedereen en z'n LLM kan lukraak een CVE inschieten en hopen dat het blijft plakken. Dan krijg je overrapportage.

Ja, het NCSC mag CVE's zelf toekennen, maar als dat binnen het domein van bijvoorbeeld Microsoft is, dan moet het via MS, omdat zij primaire (en enige) beheerder zijn. Dit recht op CVE beheer is daarom eigenlijk alleen van toepassing op niet-beheerde of toegewezen software, zoals bijvoorbeeld SQLite dus.

Ja er is ook een appeal proces om buiten de grote software bedrijven om te publiceren, maar ook dat is een hoop gedoe en een hoop politiek.

[Exodai]

Dit is best interessant. Bij een klant van ons is AI sinds een tijdje leidende. Werkelijk alles wat AI verzint wordt voor waar aangenomen. Ze kampen momenteel met een low conversion rate, AI zegt dat het design van de website kut is dus moet wel waar zijn. AI zegt dat API langzaam is dus moet wel waar zijn, AI zegt dat hun bedrijfsidee revolutionair is, dus hun idee is revolutionair.

Vorige week kregen we ook een bug report waar AI beweerde dat PSQL database geen wachtwoord behoefde. En klant dan nog stug volhouden dat al hun data niet veilig is bij ons want AI zegt het.

Het is echt heel vermoeiend.

[edwinjm]

Sommige klanten waren ook voor AI vermoeiend.

Maar als ze een andere website en snellere API willen, dan kan dat toch? Dat levert toch weer inkomsten op?

[Exodai]

Ja maar ik ga geen tijd en resources toewijzen aan de verzinsels van een of andere LLM. Ik ben meer geïnteresseerd in wat mensen zeggen en wat mensen doen. Ik hecht weinig waarde aan de "mening" van een verzameling van algoritmes. Wij gebruiken intern bijvoorbeeld Qwen veelvuldig maar wij nemen echt niks van de modellen zomaar aan als waarheid.

[Rukapul]

AI produceert slop, maar die advisories van NCSC bieden ook praktisch geen meerwaarde boven de bestaande CVEs. Lijkt wel pure werkverschaffing.

[Sebast1aan]

Dit is te verwachten.

Er is enorm bezuinigd door de Trump regering op de cyber security organisaties die CVE's managen (MITRE, CISA).

[Mizgala28]

Dus ze vertrouwden (blind?) wat de AI claimde, klinkt bekend in de oren...

Kunnen we AI afschaffen?

PLEASE???

Mensen kunnen AI gewoon niet gebruiken, of ze vertrouwen er blind op, of ze laten het andere bedrijven (per ongeluk) hacken en zeggen "oopsie" alsof het niks is, of mensen misbruiken AI (voor deepfakes, wraak porno en ga zo door).... mensen kunnen gewoon niet omgaan ermee, en de mens zelf is het probleem en dat gaat niet veranderen.

En zelfs als jij zelf het niet gebruikt bestaat er een kans dat iemand in je familie, oude foto's door ChatGPT laat oppoetsen of aanpassen... wordt je privacy alsnog geschonden.

Gaat mij trouwens niet alleen om privacy, AI is te uitgebreid en de meeste mensen zijn te dom om ermee om te gaan, simpel.

En eerlijk is eerlijk, mensen kunnen prima zonder, scheelt ook alle extra ellende dat het veroorzaakt, die te veel mensen maar al te graag onder de tapijt vegen.

[Reactie gewijzigd door Mizgala28 op 3 augustus 2026 12:50]

[SuperDre]

Tja, we kunnen ook goed zonder internet, en we kunnen ook goed zonder fabrieken, en we kunnen ook goed zonder...... AI doet echt wonderbaarlijke dingen al, maar net als de mens ook een hoop troep.

[Myri]

Tot het eens HEEL erg fout gaat, dendert die AI sneltrein gewoon aan een rotvaart verder.

De mensheid heeft een nieuw religie gevonden die ons door techbros door de strot wordt geramd. AI weet wat het beste voor je is. Reflectie over nut en noodzaak wordt veelal smalend bekeken. Of iets op een betere kosten/baten manier kan gebeuren is irrelevant. Het kan met AI, dus het moet met AI en anders ben je niet goed bezig. Fast forward nog wat en op een bepaald moment zitten we dan op het punt dat al onze informatie via AI gevoed wordt en dat het in systemen wordt bekeken als onfeilbaar. Mensen worden gestuurd en vrije keuze was leuk zolang het duurde.

Een bedrijf is niet je vriend, een AI is niet je vriend. Beide hebben er baat bij je te binden, verslaafd te maken aan "iets" waardoor je op een bepaald moment niet meer zonder kan.

Dystopian?, ja. Vergezocht?, hopelijk. Zijn we nog in controle?, twijfelachtig

[edwinjm]

De meeste mensen (ontwikkelaars) laten zich geen oor aannaaien. Als het geen voordeel biedt, is het zo weer gedeïnstalleerd.

Maar blijkbaar biedt het wel degelijk voordelen. Niet omdat het een religie is of de techbros erop hameren, maar omdat het helpt bij het ontwikkelen.

[DigitalExorcist]

Het probleem zijn mensen, niet de AI. AI is sowieso veruit superieur.