Falske CVE-er, AI-genererte rapporter og behovet for verifisering

Det blir stadig billigere å lage overbevisende rapporter om sårbarheter, noe som øker konsekvensene for programvarevedlikeholdere og sikkerhetsteam. I juli 2026 ble det publisert seks Common Vulnerabilities and Exposures (CVE-er) for SQLite, og to av dem fikk alvorlighetsgraden 9,8. Rapportene virket legitime: De beskrev feil knyttet til minnesikkerhet og inneholdt tekniske forklaringer og proof-of-concept-kode.

Men JFrogs forskere oppdaget at noen av funksjonene rapportene viste til, ikke fantes i de berørte versjonene. Dessuten gjenskapte ingen av proof-of-concept-eksemplene (PoC-er) de påståtte sårbarhetene. På CVE-siden til SQLite står det nå at disse seks rapportene ikke gjelder feil; CVE-oppføringene ble senere avvist.

Problemet gjelder mer enn SQLite. Daniel Stenberg, som vedlikeholder curl, anslo i fjor at omtrent 20 % av sikkerhetsrapportene som kom inn, var et resultat av AI-generert sludder. GitHubs CVE Numbering Authority (CNA) mottok nesten 4 000 CVE-forespørsler i mai 2026. Det tilsvarer omtrent en tidobling av volumet fra året før. GitHub ga ikke AI skylden for økningen og viste heller ikke til en nedgang i kvaliteten på innsendingene, men den kraftige volumveksten understreker hvor overbelastet prosessen for offentliggjøring av sårbarheter er.

AI gjør det enklere å lage detaljerte påstander om sårbarheter, men det tar tid å avgjøre om påstandene er legitime. Og når en CVE først er kommet inn i sikkerhetsstrømmer og offentlige databaser, betyr ikke en korrigering av den opprinnelige oppføringen automatisk at alle kopier blir korrigert. Derfor er det stadig viktigere å skille mellom en innrapportert sårbarhet og en som er teknisk verifisert.

Hva er en «falsk» CVE?

Folk bruker ofte uttrykket «falsk CVE» om en CVE som trolig ble rapportert feilaktig. Men «falsk» betyr ikke at rapporten er bevisst villedende. Den kan skyldes statisk analyse som overser en valideringskontroll eller feilaktig tolker inndata som om de kontrolleres av en angriper. En rapport kan beskrive en reell funksjon, men hevde at angrepsveien er gyldig når den ikke er det. En identifikator (CVE-ID) kan tildeles og senere forkastes hvis forholdet som ble rapportert, faktisk ikke var en sårbarhet. Det er noe annet enn en bevisst oppdiktet rapport.

En uenighet er heller ikke en falsk CVE. En leverandør kan bestride en forskers funn om hvorvidt noe kan utnyttes, om trusselgrensene eller om en funksjon var ment å behandle data som ikke er til å stole på. Men en uenighet er ikke bevis på at forskeren tok feil. Og en avvist CVE betyr ikke nødvendigvis at den var oppdiktet; den kan bli avvist fordi den er en duplikat eller av administrative årsaker. Selv om en CVE-identifikator ikke er en uavhengig teknisk verifisering, må bransjen ta reelle rapporter på alvor.

Hvorfor falske CVE-er er et problem

Et av problemene vi ser, er at folk bruker AI til å generere rapporter om sårbarheter uten å kontrollere funnene ordentlig. Rapportene kan inneholde detaljerte tekniske forklaringer, henvisninger til kode og til og med PoC-er, noe som kan få dem til å virke legitime. Men som vi så med CVE-ene for SQLite, fantes noen av funksjonene det ble vist til, ikke engang i de berørte versjonene.

GitHub rapporterte om en betydelig økning i innrapporterte sårbarheter i 2026, men knyttet ikke økningen til AI og meldte heller ikke om dårligere kvalitet på innsendingene. Bekymringen er at når antallet rapporter øker, øker også arbeidsmengden som kreves for å undersøke dem, uansett om funnene er reelle eller ikke.

For dem som har prioritert og vurdert rapporter om sårbarheter, er det lett å se de praktiske utfordringene. En AI-modell kan identifisere et mistenkelig API-kall, raskt skissere et mulig angrepsscenario og lage en rapport som ser profesjonell ut. For å avgjøre om scenarioet lar seg gjennomføre, kan det være nødvendig å kontrollere den nøyaktige versjonen, følge kontrollflyten, finne ut hvordan data når fram til funksjonen, sette opp et testmiljø og kjøre det påståtte angrepet. Prosessen er den samme enten rapporten er riktig eller ikke, og den kan være kostbar.

Falske CVE-er kan også skade omdømmet. En kunngjøring om en sårbarhet kan raskt spres gjennom skannerstrømmer, sikkerhetsdatabaser og søkeresultater. En påfølgende korrigering når imidlertid kanskje ikke like langt. Selv etter at en rapport er blitt bestridt eller avvist, kan leverandører bli nødt til å forsvare seg overfor kunder som har sett den opprinnelige rapporten.

Det er også en risiko for at reelle sårbarheter blir oversett eller forsinket fordi team bruker tid på å undersøke feilaktige rapporter. Når vedlikeholdere og sikkerhetsteam har begrensede ressurser, er hver time brukt på å avkrefte et falskt positivt funn en time som kunne vært brukt på å undersøke et faktisk sikkerhetsproblem.

Slik slår vi tilbake med automatisering

Mange som undersøker sårbarheter, bruker fortsatt manuell triage for å håndtere den nye flommen av rapporter, men dette er ikke bærekraftig. Automatisering viser seg å være til stor hjelp når man skal kontrollere en påstand om en sårbarhet mot den faktiske berørte versjonen og konfigurasjonen. Dette er de fem spørsmålene man bør stille:

• Er forutsetningene for angrepet troverdige, også når det gjelder konfigurasjon og tillatelser?
• Finnes den aktuelle funksjonen i den berørte versjonen?
• Kan en angriper nå den sårbare koden? Avgjør om den relevante koden kan kjøres under de berørte forholdene, og om en angriper kan sende inn data som når fram til den.
• Kan testere gjenskape atferden i en kontrollert test eller med en PoC?
• Har den observerte atferden den sikkerhetsmessige konsekvensen som beskrives i sikkerhetsmeldingen?

Agentbaserte verktøy kan opprette testmiljøer, analysere kodebaner, generere PoC-er og dokumentere kjøreevidens for gjennomgang. De kan ikke automatisk avklare alle påstander. Selv når en sårbarhet er reell, kan en PoC mislykkes hvis miljøet er ufullstendig eller utløseren er feil. Testere kan gjenskape en krasj uten å bevise at sårbarheten kan utnyttes slik det hevdes. Disse forbeholdene er grunnen til at menneskelig skjønn fortsatt er avgjørende. Men slike verktøy kan hjelpe team med å komme nærmere et svar som kan gjenskapes, før en rapport legger beslag på mer tid i utvikling, sårbarhetshåndtering og kundestøtte.

Å håndtere overveldelsen i CVE-økosystemet

Ingen kortfattet retningslinje vil på magisk vis løse problemet med falske CVE-er. Men det ville hjelpe å stille strengere krav til dokumentasjonen som følger med innsendinger, og å gjøre status for reproduksjon tydeligere. Det ville også hjelpe med tydeligere håndtering av omstridte registreringer og raskere korrigering av nedstrømsdata. Forskere bør oppmuntres til å validere AI-assisterte funn før innsending.

Sikkerhetsteam og leverandører må konsentrere seg om å undersøke dokumentasjonen. En kritisk CVE-score sier ikke om en sårbar kodebane kan nås i deres miljø. At en PoC mislykkes, betyr ikke nødvendigvis at alt er i orden. Og det at man får en CVE-ID, fritar ikke teamene fra å utføre det tekniske arbeidet som kreves for å forstå et problem.

AI gjør det lettere å oppdage sårbarheter, men legger også til rette for å lage påstander som ser troverdige ut, men er feilaktige. I en verden med stadig flere rapporter må organisasjoner investere i verifisering. Det innebærer å utforme tester, gjenskape resultater, kontrollere forutsetninger og gjøre det enklere å vurdere dokumentasjonen. Dette er et område der agentbasert sikkerhetstesting kan spille en viktig rolle.