A generatív mesterséges intelligencia már nemcsak megtévesztő szövegek, képek vagy programkódok előállítására használható: egyre több olyan, hitelesnek tűnő sérülékenységi jelentés is megjelenik, amely mögött valójában nincs reprodukálható biztonsági hiba. A JFrog biztonsági kutatói nemrég hat, kritikus vagy magas súlyosságúnak minősített SQLite CVE-ről állapították meg, hogy technikailag megalapozatlan. Az eset arra világít rá, hogy a jelenlegi CVE-pipelineba megfelelő ellenőrzés nélkül is bekerülhetnek hamis információk.
A kifogásolt bejegyzéseket egy új, kevéssé ismert GitHub repóban tették közzé egy nagyobb CVE csomag részeként. A jelentések elemzése arra utalt, hogy valószínűleg mesterséges intelligenciával generálták őket. Bár az SQLite-ot érintő hat sérülékenységhez 7,5 és 9,8 közötti CVSS-pontszámokat rendeltek, a JFrog egyik hibát sem tudta reprodukálni.
Az egyik bejegyzés például egy állítólagos use-after-free, vagyis felszabadítás utáni memóriahasználati hibát írt le. A Red Hat kezdetben a maximális, 10,0-s CVSS-pontszámot adta a sérülékenységnek, később azonban csökkentette a besorolást. A jelentés egy olyan függvényre hivatkozott, amely az érintett SQLite-verzióban nem is létezett. Egy másik, 9,1-es besorolású bejegyzés olyan forráskódsorokat jelölt meg, amelyek nem kapcsolódtak a feltételezett hibához. A mellékelt proof-of-concept kód futtatásakor csupán egy szabályos adatbázis-lekérdezés hajtódott végre, memóriaszivárgás vagy egyéb hiba nélkül. A további négy vizsgált SQLite CVE hasonlóan hamisnak bizonyult.
A GitHub repó további 49 állítólagos sérülékenységet tartalmazott a RAW képfájlokat feldolgozó libraw könyvtárral, illetve az ESP32-audioI2S hangdekódoló könyvtárral kapcsolatban. Ezeket a JFrog kevésbé részletesen vizsgálta, de a kutatók szerint egy kivétellel mindegyik megalapozatlan volt. Az egyetlen részben valós bejegyzés egy tényleges programhibát tartalmazott, de ellenőrizetlen és félrevezető CVE-metaadatokkal kiegészítve. Az OSS-Security levelezőlistán megjelent információk szerint a MITRE végül a tárolóhoz kapcsolódó teljes CVE-csomagot elutasította.
A probléma egyik oka a CVE-rendszer bizalmi alapú működése. Alan Coopersmith, az Oracle Solaris mérnöke szerint a MITRE és számos más CVE Numbering Authority, vagyis CNA rendszerint feltételezi, hogy a bejelentők már ellenőrizték az általuk megadott adatokat. Ezek a szervezetek sok esetben nem rendelkeznek elegendő idővel, erőforrással vagy technikai lehetőséggel arra, hogy minden bejelentett hibát saját maguk is reprodukáljanak.
Korábban az amerikai NIST által működtetett National Vulnerability Database, az NVD további védelmi réteget biztosított. A NIST szakemberei manuálisan ellenőrizték és kiegészítették a CVE-rekordokat, mielőtt azok széles körben használt adatforrássá váltak. Ez a folyamat azonban 2024-ben jelentősen lelassult a bejelentések számának növekedése és a szervezet működési nehézségei miatt. A feldolgozatlan CVE-k száma 2024 végére meghaladta a 17 ezret, 2025 végére pedig már több mint 27 ezerre nőtt.
A jelenlegi rendszerben tehát nincs olyan kötelező ellenőrzési pont, ahol minden bejelentett sérülékenység reprodukálhatóságát bizonyítani kellene. Emiatt egy szakmailag meggyőzően megfogalmazott, de hamis közlemény bekerülhet a GitHub Security Advisories rendszerébe, az NVD-be, más sérülékenységi adatbázisokba, majd akár vállalati biztonsági ellenőrző és sebezhetőségvizsgáló eszközökbe is.
Ez komoly terhet róhat a biztonsági csapatokra. A hamis riasztások kivizsgálása időt és erőforrást von el a valódi sérülékenységek kezelésétől, miközben szükségtelen frissítésekhez, incidenskezelési folyamatokhoz vagy üzleti fennakadásokhoz vezethet. A JFrog ezért azt javasolja, hogy a szakemberek ne kizárólag a CVE-azonosító vagy a CVSS-pontszám alapján döntsenek.
Gyanúra adhat okot, ha a gyártó vagy a projekt karbantartói nem erősítik meg a sérülékenységet. Szintén figyelmeztető jel, ha a jelentés nem hivatkozik konkrét commitra, javításra vagy pull requestre, ha hiányosak a CPE-termékadatok, illetve ha a megjelölt függvények vagy kódrészletek nem léteznek, vagy nem kapcsolódnak a leírt problémához. Ezek a hibák gyakran arra utalnak, hogy a közlemény MI-hallucináció eredménye.
A generatív MI szinte nullára csökkentette a hitelesnek látszó biztonsági közlemények elkészítéséhez szükséges erőfeszítést. Egy jelentés ellenőrzése azonban továbbra is forráskód-elemzést, az érintett verzió összeállítását és a proof-of-concept reprodukálását igényli. Ez az aránytalanság azt jelenti, hogy még a jól finanszírozott biztonsági csapatok sem tudnak minden beérkező jelentést manuálisan ellenőrizni, így a hamis CVE-k kiszűrése az MI-korszak egyik új, iparági szintű kihívásává válhat.