Un repository GitHub appena creato ha pubblicato una serie di advisory su presunte vulnerabilità critiche in SQLite. NVD ha assegnato punteggi CVSS fino a 9.8, e l’ADP di CISA ha confermato la gravità. Quando i ricercatori di JFrog sono andati a verificare, le funzioni citate non esistevano nelle versioni indicate, i proof-of-concept non provocavano alcun crash, e i presunti patch erano inesistenti. Gli advisory, passati a un rilevatore di contenuto AI, risultano generati da un modello linguistico.

Perché ti riguarda. I sistemi automatici che classificano le vulnerabilità hanno processato questi falsi come se fossero reali. Se la tua pipeline CI/CD include controlli automatici sulle CVE delle dipendenze, potresti aver ricevuto allarmi su bug inesistenti. Le infrastrutture critiche di sicurezza ingeriscono contenuto senza verificarlo, e quel contenuto ora può essere generato da un LLM a costo quasi zero.

Questo riguarda chi usa agenti AI per automatizzare analisi di sicurezza. La stessa facilità con cui un modello scrive un advisory credibile a una prima lettura è quella con cui produce qualsiasi output plausibile ma sbagliato. Un passo di verifica, anche rapido, costa meno di un falso allarme che innesca un piano di risposta a un incidente inesistente.

Nel dettaglio

Il repository programmervuln/cveadvisory- ha pubblicato nei primi giorni di agosto una ventina di advisory su vulnerabilità SQLite, più altre 50 segnalazioni che JFrog ritiene ugualmente generate da un LLM. Il database nazionale delle vulnerabilità (NVD) ha registrato sei di queste CVE con punteggi alti: due a 9.8 (critiche), una a 9.1, tre fra 7.5 e 8.8. L’Automated Decision Plugin (ADP) di CISA ha validato le valutazioni di gravità.

JFrog ha seguito un protocollo rigoroso per verificare ogni segnalazione: clone del repository ufficiale SQLite, checkout delle versioni citate (3.41.0, 3.51.2, 3.51.3), compilazione in container isolati, e test dei proof-of-concept sotto AddressSanitizer per rilevare violazioni di memoria.

I risultati sono inequivocabili. La CVE-2026-51302 (9.8 critica) cita la funzione exprComputeOperands() come sede di un use-after-free, ma quella funzione non esisteva in SQLite 3.41: è stata introdotta nel 2025. La funzione sqlite3ReleaseTempReg() menzionata come causa del dangling pointer non alloca memoria heap: ricicla indici di registro in un array, rendendo un UAF impossibile per costruzione.

La CVE-2026-51303 (9.8 critica) descrive un fix nella versione 3.51.3 che semplicemente non esiste. Il diff fra 3.51.2 e 3.51.3 non mostra alcuna modifica a src/expr.c. Il PoC associato è SQL non valido e viene rigettato dal parser prima di raggiungere la logica di esecuzione.

La CVE-2026-51300 (9.1 critica) cita numeri di riga specifici di expr.c che corrispondono a un commento e a una chiamata di allocazione, senza alcuna relazione con la logica di cancellazione descritta. Il PoC, eseguito come query valida, restituisce l’output atteso senza memory leak.

Due segnali confermano l’origine generativa. JFrog ha passato gli advisory a GPTZero, che li classifica come contenuto AI. E combinando tutti gli advisory in un unico file, i rilevatori di contenuto generato attivano warning immediati. Il repository sembra essere un esperimento, o un attacco coordinato, in cui qualcuno usa un LLM per produrre advisory tecnicamente plausibili a una lettura superficiale e li sottopone ai sistemi di tracking.

Cosa cambia. La pipeline di trust delle vulnerabilità funziona così: qualcuno pubblica un advisory, NVD lo registra, CISA lo valuta, e gli strumenti di dependency scanning lo propagano agli sviluppatori. Finora il collo di bottiglia era la quantità di advisory umani. Con un LLM, il collo di bottiglia sparisce: puoi generare centinaia di CVE credibili a una prima lettura in un pomeriggio.

Red Hat aveva inizialmente assegnato a una di queste CVE un punteggio 10.0, poi abbassato a 7.6. Anche i team di triage professionisti, davanti a un advisory ben costruito, faticano a distinguere il vero dal falso senza andare nel codice.

Cosa resta aperto. Non sappiamo chi sta dietro al repository, né se l’obiettivo era testare i sistemi, creare rumore per coprire altro, o dimostrare che si può fare. JFrog ha analizzato sei CVE in dettaglio: le altre 50+ segnalazioni dello stesso repo restano da verificare una per una. E non sappiamo quanti tool di sicurezza automatici abbiano già allertato sviluppatori su queste CVE false, né quanti team abbiano spostato risorse per rispondere a minacce inesistenti.