Falska CVE:er, AI-genererade rapporter och behovet av verifiering

Det blir allt billigare att skapa övertygande sårbarhetsrapporter, vilket får allt större konsekvenser för programvaruunderhållare och säkerhetsteam. Sex Common Vulnerabilities and Exposures (CVE:er) publicerades för SQLite i juli 2026, och två av dem fick allvarlighetsgraden 9,8. Rapporterna verkade trovärdiga: de beskrev minnessäkerhetsfel och innehöll tekniska förklaringar och proof-of-concept-kod.

Men JFrogs forskare upptäckte att vissa av funktionerna som rapporterna hänvisade till inte fanns i de berörda versionerna. Dessutom återskapade inget av proof-of-concept-exemplen (PoC:erna) de påstådda sårbarheterna. På sin CVE-sida uppger SQLite för närvarande att dessa sex rapporter inte gäller några buggar; CVE-posterna avvisades senare.

Problemet sträcker sig längre än SQLite. Daniel Stenberg, som underhåller curl, uppskattade i fjol att omkring 20 % av de inkommande säkerhetsrapporterna var resultatet av AI-skräp. GitHubs CVE Numbering Authority (CNA) tog emot nästan 4 000 CVE-begäranden i maj 2026, en volymökning på ungefär tio gånger jämfört med året innan. GitHub skyllde inte ökningen på AI och noterade ingen försämring av kvaliteten på rapporterna, men den enorma volymökningen visar hur överbelastad processen för offentliggörande av sårbarheter är.

AI gör det enklare att ta fram detaljerade påståenden om sårbarheter, men det är tidskrävande att avgöra om de stämmer. Och när en CVE väl har kommit in i säkerhetsflöden och offentliga databaser innebär en rättelse av originalposten inte automatiskt att alla kopior också rättas. Därför ökar behovet av att skilja mellan en rapporterad sårbarhet och en som har verifierats tekniskt.

Vad är en ”falsk” CVE?

Man använder ofta uttrycket ”falsk CVE” om en CVE som sannolikt har rapporterats felaktigt. Men ”falsk” betyder inte att rapporten avsiktligt vilseleder. Den kan bygga på en statisk analys som missar en valideringskontroll eller felaktigt tolkar indata som angriparstyrda. En rapport kan beskriva en verklig funktion men hävda att den kan angripas på ett sätt som inte fungerar. Ett ID (CVE-ID) kan tilldelas och senare återkallas om det rapporterade förhållandet i själva verket inte utgör en sårbarhet. Det skiljer sig från en medvetet påhittad rapport.

En tvist innebär inte heller att det rör sig om en falsk CVE. En leverantör kan ifrågasätta en forskares slutsatser om exploaterbarhet, hotgränser eller huruvida en funktion är avsedd att behandla obetrodda indata. Men en tvist bevisar inte att forskaren har gjort fel. Och att en CVE avvisas betyder inte nödvändigtvis att den har hittats på; den kan avvisas som en dubblett eller av administrativa skäl. Även om ett CVE-ID inte är en oberoende teknisk verifiering måste branschen ta verkliga rapporter på allvar.

Varför falska CVE:er är ett problem

Ett av problemen vi ser är att människor använder AI för att skapa sårbarhetsrapporter utan att validera resultaten ordentligt. Rapporterna kan innehålla detaljerade tekniska förklaringar, kodreferenser och till och med PoC:er, vilket kan få dem att verka trovärdiga. Men som vi såg med SQLite-CVE:erna fanns vissa av de funktioner som rapporterna hänvisade till inte ens i de berörda versionerna.

GitHub rapporterade en kraftig ökning av antalet inskickade sårbarhetsrapporter 2026, men tillskrev inte ökningen AI och rapporterade inte heller någon försämring av kvaliteten på rapporterna. Oron är att mer arbete krävs för att undersöka rapporterna när antalet ökar, oavsett om resultaten stämmer eller inte.

Den som har sorterat och bedömt sårbarhetsrapporter känner lätt igen den praktiska utmaningen. En AI-modell kan identifiera ett misstänkt API-anrop, skissa upp ett angreppsscenario och snabbt skapa en professionellt utformad rapport. För att avgöra om scenariot är genomförbart kan man behöva kontrollera den exakta versionen, följa kontrollflödet, ta reda på hur data når funktionen, bygga upp en testmiljö och köra det påstådda angreppet. Processen är densamma oavsett om rapporten stämmer eller inte, och den kan bli kostsam.

Falska CVE:er kan också skada anseendet. Ett sårbarhetsmeddelande kan snabbt spridas via skanningsflöden, säkerhetsdatabaser och sökresultat. En efterföljande rättelse behöver däremot inte få lika stor spridning. Även efter att en rapport har ifrågasatts eller avvisats kan leverantörer behöva försvara sig inför kunder som har sett den ursprungliga rapporten.

Det finns också en risk att verkliga sårbarheter förbises eller utreds senare, eftersom teamen lägger tid på att undersöka felaktiga rapporter. När underhållare och säkerhetsteam har begränsade resurser innebär varje timme som går åt till att motbevisa ett falskt positivt fynd att mindre tid kan läggas på att undersöka ett verkligt säkerhetsproblem.

Automatisering som motdrag

Många utredare använder fortfarande manuell triagering för att hantera den nya floden av rapporter, men det är inte hållbart. Automatisering visar sig vara till stor hjälp när det gäller att verifiera ett påstående om en sårbarhet mot den faktiska berörda versionen och konfigurationen. Här är de fem frågor man bör ställa:

• Är förutsättningarna för angreppet trovärdiga, även vad gäller konfiguration och behörigheter?
• Finns den påstådda funktionen i den berörda versionen?
• Kan en angripare nå den sårbara koden? Ta reda på om den relevanta koden kan köras under de berörda förhållandena och om en angripare kan tillhandahålla indata som når den.
• Kan testare återskapa beteendet i en kontrollerad testmiljö eller med hjälp av en PoC?
• Visar det observerade beteendet den säkerhetspåverkan som beskrivs i säkerhetsmeddelandet?

Agentbaserade verktyg kan skapa testmiljöer, analysera kodvägar, generera PoC:er och dokumentera körningsbevis för granskning. De kan inte automatiskt verifiera alla påståenden. Även om en sårbarhet är verklig kan en PoC misslyckas om miljön är ofullständig eller utlösaren är felaktig. Testare kan återskapa en krasch utan att bevisa den påstådda exploaterbarheten. Det är därför mänskligt omdöme fortfarande är avgörande. Men verktygen kan hjälpa team att komma närmare ett reproducerbart svar innan en rapport tar mer tid från utveckling, sårbarhetshantering och kundsupport.

Att hantera överbelastningen i CVE-ekosystemet

Ingen kortfattad policy kan på magisk väg lösa problemet med falska CVE:er. Men det skulle hjälpa att kräva starkare underlag vid inskickning och tydligare status för reproducering. Det skulle också hjälpa med tydligare hantering av omtvistade poster och snabbare korrigering av data längre ned i kedjan. Forskare bör uppmuntras att validera sina AI-assisterade fynd innan de skickas in.

Säkerhetsteam och leverantörer måste fokusera på att granska underlaget. Ett kritiskt CVE-poängtal visar inte om en sårbar kodväg går att nå i deras miljö. Att en PoC misslyckas betyder inte att allt är som det ska. Och att få ett CVE-ID befriar inte team från det tekniska arbete som krävs för att förstå ett problem.

AI förbättrar förmågan att upptäcka sårbarheter, men gör det också möjligt att skapa påståenden som verkar trovärdiga men är felaktiga. I en värld med allt fler rapporter behöver organisationer investera i verifiering. Det innebär att ta fram tester, återskapa resultat, kontrollera antaganden och göra underlaget lättare att bedöma. Agentbaserad säkerhetstestning skulle kunna spela en viktig roll på det här området.