Falske CVE’er, AI-genererede rapporter og behovet for verifikation

Det bliver stadig billigere at udarbejde overbevisende sårbarhedsrapporter, og det øger konsekvenserne for softwarevedligeholdere og sikkerhedsteams. Seks Common Vulnerabilities and Exposures (CVE’er) blev offentliggjort for SQLite i juli 2026, og to af dem fik en alvorlighedsscore på 9,8. Rapporterne virkede legitime: De beskrev fejl i hukommelsessikkerheden og indeholdt tekniske forklaringer og proof-of-concept-kode.

Men JFrogs forskere opdagede, at nogle af de funktioner, rapporterne henviste til, ikke fandtes i de berørte versioner. Desuden kunne ingen af proof-of-concept-eksemplerne (PoC’er) genskabe de påståede sårbarheder. På SQLite’s egen CVE-side står der i øjeblikket, at disse seks rapporter ikke beskriver fejl; CVE-registreringerne blev efterfølgende afvist.

Problemet rækker ud over SQLite. Daniel Stenberg, der vedligeholder curl, anslog sidste år, at omkring 20 % af de indkomne sikkerhedsrapporter var resultatet af AI-genereret sludder. GitHubs CVE Numbering Authority (CNA) modtog næsten 4.000 CVE-anmodninger i maj 2026; det svarer til cirka 10 gange så mange som året før. GitHub gav ikke AI skylden for stigningen og nævnte heller ikke et fald i kvaliteten af indsendelserne, men den massive vækst i antallet understreger, hvor overbelastet processen for offentliggørelse af sårbarheder er.

AI gør det lettere at fremsætte detaljerede påstande om sårbarheder, men det er tidskrævende at afgøre, om påstandene er legitime. Og når først en CVE er kommet med i sikkerhedsfeeds og offentlige databaser, betyder en rettelse af den oprindelige registrering ikke automatisk, at alle kopier også bliver rettet. Derfor er der et voksende behov for at skelne mellem en indberettet sårbarhed og en, der er teknisk verificeret.

Hvad er en »falsk« CVE?

Folk bruger ofte udtrykket »falsk CVE« om en CVE, der sandsynligvis er blevet indberettet fejlagtigt. Men »falsk« betyder ikke, at nogen bevidst forsøger at vildlede. Det kan skyldes en statisk analyse, der overser et valideringstjek eller fejlagtigt antager, at en angriber kan kontrollere inputtet. En rapport kan beskrive en reel funktion, men påstå, at den kan udnyttes ad en ugyldig angrebsvej. Der kan tildeles en identifikator (CVE-ID), som senere trækkes tilbage, hvis det indberettede forhold faktisk ikke var en sårbarhed. Det er noget andet end en bevidst opdigtet rapport.

En uenighed er heller ikke ensbetydende med en falsk CVE. En leverandør kan anfægte en forskers konklusioner om muligheden for udnyttelse, trusselsgrænserne eller om en funktion var beregnet til at behandle input fra ikke-betroede kilder. Men en uenighed beviser ikke, at forskeren tog fejl. Og en afvisning af en CVE betyder ikke nødvendigvis, at den var opdigtet; den kan blive afvist som en dublet eller af administrative årsager. Selvom en CVE-identifikator ikke er en uafhængig teknisk verifikation, er branchen nødt til at tage reelle rapporter alvorligt.

Hvorfor falske CVE’er er et problem

Et af de problemer, vi ser, er, at folk bruger AI til at generere sårbarhedsrapporter uden at validere resultaterne ordentligt. Rapporterne kan indeholde detaljerede tekniske forklaringer, henvisninger til kode og endda PoC’er, så de kan virke legitime. Men som vi så med CVE’erne for SQLite, fandtes nogle af de omtalte funktioner slet ikke i de berørte versioner.

GitHub rapporterede om en markant stigning i antallet af indberettede sårbarheder i 2026, men tilskrev ikke stigningen AI og meldte heller ikke om et fald i kvaliteten af indsendelserne. Bekymringen er, at den nødvendige arbejdsindsats for at undersøge rapporterne vokser i takt med antallet, uanset om resultaterne er reelle.

For dem, der har triageret sårbarhedsrapporter, er den praktiske udfordring let at genkende. En AI-model kan identificere et mistænkeligt API-kald, skitsere et muligt angrebsscenarie og hurtigt generere en rapport, der ser professionel ud. For at afgøre, om scenariet kan lade sig gøre, kan det være nødvendigt at kontrollere den præcise udgivelse, følge kontrolflowet, undersøge, hvordan data når frem til funktionen, opbygge et testmiljø og afprøve det påståede angreb. Det er den samme proces, uanset om rapporten er korrekt eller ej, og den kan være dyr.

Falske CVE’er kan også skade omdømmet. En offentliggørelse af en sårbarhed kan hurtigt blive spredt via scannerfeeds, sikkerhedsdatabaser og søgeresultater. En efterfølgende rettelse når dog muligvis ikke lige så langt ud. Selv efter at en rapport er blevet anfægtet eller afvist, kan leverandører komme i defensiven over for kunder, der har set den oprindelige rapport.

Der er også risiko for, at reelle sårbarheder overses eller behandles senere, fordi teams bruger tid på at undersøge fejlagtige rapporter. Når vedligeholdere og sikkerhedsteams har begrænsede ressourcer, er hver time brugt på at afkræfte en falsk positiv en time, der kunne være brugt på at undersøge et reelt sikkerhedsproblem.

Kamp med automatisering

Mange efterforskere bruger stadig manuel triagering til at håndtere den nye strøm af rapporter, men det er ikke holdbart. Automatisering er en stor hjælp til at verificere en påstand om en sårbarhed i forhold til den faktisk berørte udgivelse og konfiguration. Her er de fem spørgsmål, man bør stille:

• Er forudsætningerne for angrebet troværdige, herunder konfiguration og tilladelser?
• Findes den påståede funktion i den berørte version?
• Kan en angriber nå frem til den sårbare kode? Afgør, om den relevante kode kan blive eksekveret under de berørte forhold, og om en angriber kan levere input, der når frem til den.
• Kan testere genskabe adfærden i en kontrolleret test eller med en PoC?
• Viser den observerede adfærd den sikkerhedsmæssige konsekvens, der er beskrevet i sikkerhedsmeddelelsen?

Agentbaserede værktøjer kan oprette testmiljøer, analysere kodeforløb, generere PoC’er og registrere dokumentation for eksekvering til gennemgang. De kan ikke automatisk afklare alle påstande. Selv når en sårbarhed er reel, kan en PoC mislykkes, hvis miljøet er ufuldstændigt, eller udløseren er forkert. Testere kan genskabe et nedbrud uden at bevise den påståede mulighed for at udnytte sårbarheden. Det er derfor, disse forbehold gør menneskelig vurdering afgørende. Men værktøjerne kan hjælpe teams med at komme tættere på et svar, der kan reproduceres, før en rapport sluger mere tid på tværs af udvikling, sårbarhedshåndtering og kundesupport.

Sådan håndteres overvældelsen i CVE-økosystemet

Ingen kortfattet politik kan på magisk vis løse problemet med falske CVE’er. Men det ville hjælpe at kræve stærkere dokumentation ved indsendelse og at gøre status for reproduktion tydeligere. Det ville også hjælpe med en tydeligere håndtering af omstridte registreringer og hurtigere rettelse af efterfølgende data. Forskere bør opfordres til at validere deres AI-assisterede resultater, før de indsendes.

Sikkerhedsteams og leverandører skal fokusere på at undersøge dokumentationen. En kritisk CVE-score afslører ikke, om en sårbar kodevej kan nås i deres miljø. At en PoC mislykkes, betyder ikke, at alt er i orden. Og det fritager ikke teams for det tekniske arbejde, der kræves for at forstå et problem, at de modtager et CVE-id.

AI forbedrer evnen til at opdage sårbarheder og gør det samtidig muligt at fremsætte påstande, der ser overbevisende ud, men er forkerte. I en verden med stadig flere rapporter er organisationer nødt til at investere i verificering. Det indebærer at opbygge tests, genskabe resultater, kontrollere antagelser og gøre dokumentationen lettere at vurdere. Det er et område, hvor agentbaseret sikkerhedstestning kan spille en vigtig rolle.