NCSC trekt SQLite-advisory in: lek is door een taalmodel verzonnen

Het NCSC heeft zijn advisory over een kritiek lek in SQLite ingetrokken, omdat de kwetsbaarheid zeer waarschijnlijk door een LLM gehallucineerd is. De melding stond sinds 29 juli online met de maximale CVSS-score van 10,0.

SQLite zit in vrijwel elk apparaat en elk pakket dat je bedrijf gebruikt: browsers, telefoons, mobiele apps en als ingebouwde database in software van je leveranciers. Een score van 10,0 op zo'n component betekent een noodronde voor je beheerteam en een reeks vragen die je bij leveranciers moet uitzetten. Die ronde was voor niets. Wat hier verandert is niet de code maar de keten eromheen: de meldstroom waarop je je patchprioriteit baseert, van de CVE-database van Mitre tot het advisory van je eigen nationale toezichthouder, liet een verzinsel ongecontroleerd passeren.

Van CVE-nummer naar noodwaarschuwing en weer terug

De tijdlijn is kort en pijnlijk. Mitre reserveerde het nummer op 7 juni en publiceerde CVE-2026-51302 op 27 juli, met Mitre zelf als toewijzende partij. Twee dagen later nam het NCSC de melding over in advisory NCSC-2026-0268, onder de omschrijving dat er een use-after-free in de expressie-evaluatie van SQLite 3.41 zat waarmee een aanvaller op afstand willekeurige code kon uitvoeren. Het advisory kreeg prioriteit "Normaal", maar de CVE stond er met CVSS 10,0 bij en het NCSC verspreidde de melding ook via een aparte alert met "update onmiddellijk" in de titel. Die alertpagina is inmiddels offline.

Op 31 juli haalde Mitre de CVE weg. In de nationale kwetsbaarhedendatabase van de VS staat de melding nu als REJECTED, met als reden dat nader onderzoek uitwees dat het geen beveiligingsprobleem was. Het NCSC volgde pas vanochtend om 09.25 uur met revisie 1.0.1, waarin de hele omschrijving is doorgestreept en er één regel bij staat: "CVE is ingetrokken, de 'kwetsbaarheid' is zeer waarschijnlijk door een LLM gehallucineerd." Tussen de publicatie van de CVE en de correctie van het Nederlandse advisory zaten zeven dagen.

De code waar het lek in zat, bestond niet

Beveiligingsbedrijf JFrog analyseerde zes SQLite-CVE's uit dezelfde reeks en vond bij CVE-2026-51302 twee harde tegenbewijzen. De functie waarin het lek zou zitten, exprComputeOperands(), bestond helemaal niet in SQLite 3.41, en het mechanisme dat de melding beschreef is door het ontwerp heen onmogelijk: de betrokken code hergebruikt registerindexen in een array, waardoor een use-after-free niet kan optreden. De meldingen kwamen uit één nieuwe GitHub-repository met 55 advisories, waarvan er volgens JFrog 54 volledig verzonnen waren en één een echte bug bevatte met ongecontroleerde CVE-metadata eromheen.

Red Hat, dat SQLite meelevert, is nog stelliger. Het bedrijf schrijft dat de upstream-ontwikkelaars deze CVE als fictief hebben bevestigd, dat er geen patches of errata nodig zijn en dat klanten een treffer van hun scanner veilig als vals positief kunnen behandelen. Dat laatste is precies het punt waar dit soort meldingen jouw organisatie raakt: je scanner rapporteert wat er in de database staat, niet wat er in de werkelijkheid zit.

SQLite-maker Richard Hipp legde de vinger op de zere plek. Hij kreeg op 29 juli mails van beveiligingsanalisten over fictieve CVE's tegen SQLite en schreef op het projectforum dat Mitre een CVE van iedereen op elk moment aanneemt, zonder enige vorm van validatie, terwijl er wel volop bewijs nodig is om er één weer weg te krijgen. Zijn conclusie was net zo droog: zie je een nieuwe CVE tegen SQLite, dan kun je er vermoedelijk van uitgaan dat hij nep is. In dezelfde discussie wijst een forumdeelnemer erop dat curl in 2024, Rust in 2025 en de Linux-kernel in 2026 juist daarom zelf CVE-nummers zijn gaan uitgeven.

Wat dit met je patchprioriteit doet

De Nederlandse vakpers legt de schuld vooral bij Mitre, dat rapportages van externe partijen hoort te controleren voordat ze in de database landen. Het NCSC verifieert die meldingen niet zelf maar publiceert ze pas nadat instanties als Mitre dat hebben gedaan. Wat er misging is niet met zekerheid vastgesteld. Het NCSC houdt het op hallucinatie, maar moedwillige misleiding met AI-gegenereerde rapporten is niet uitgesloten.

Voor wie patchbeslissingen neemt, verschuift daarmee de werklast naar voren. Je filterde al op de onderkant, want van alle in 2025 gepubliceerde CVE's is amper 1 procent daadwerkelijk misbruikt, waardoor triage op misbruik-signaal meer oplevert dan een vaste patchkalender. Nu komt daar de bovenkant bij: ook een score van 10,0 van een gezaghebbende afzender is geen bewijs meer dat er iets bestaat. Drie controles kosten weinig en vangen dit type melding af. Kijk of de CVE bij cve.org nog de status gepubliceerd heeft en niet REJECTED. Kijk of de leverancier van het product zelf iets zegt, want zowel SQLite als Red Hat had de melding al ontkracht voordat het advisory werd bijgewerkt. En kijk of er een proof-of-concept is die iemand heeft kunnen reproduceren, want bij deze reeks lukte dat niemand.

De wrange kant zit in het tempo. Dezelfde dienst die eind juli nog schreef dat de tijd tussen een gevonden lek en actief misbruik door AI van weken naar dagen naar minuten is gegaan, deed er na de intrekking door Mitre nog drie dagen over om de melding uit zijn eigen kanaal te halen. Snelheid aan de aanvalskant en zorgvuldigheid aan de meldkant trekken aan hetzelfde touw, en dat conflict wordt niet opgelost door harder te patchen.

Het patroon eronder is inmiddels bekend. Verzonnen bronnen kostten KPMG een ingetrokken rapport, en modellen worden getraind op een manier die zelfverzekerd raden beloont boven toegeven dat je het niet weet. Nieuw is waar het verzinsel nu landt: niet in een adviesrapport dat iemand nog naleest, maar in een formeel meldproces waarop duizenden organisaties hun prioriteiten baseren, met een scanner en een patchvenster eraan vast. Dat maakt de vraag welke verificatiestap er tussen "er is een melding" en "de patchronde start" zit, geen theoretische kwestie meer.