Synthos Logic/News & Insights/Modelli & rilasci/Sette mesi di Glasswing secondo VulnCheck: 442 CVE, due sfruttate e 217 correzioni su 37.966 segnalazioni
REF · NEWS-PROD
◉ 2026
Modelli & rilasci ◉ Approfondimento

Sette mesi di Glasswing secondo VulnCheck: 442 CVE, due sfruttate e 217 correzioni su 37.966 segnalazioni

Il programma che porta i modelli di Anthropic a caccia di vulnerabilità produce segnalazioni a decine di migliaia e correzioni a centinaia. Il caso di curl mostra su chi ricade il lavoro di verifica.

Il 9 novembre 2026 VulnCheck, società specializzata in intelligence sulle vulnerabilità, ha pubblicato la quinta revisione di Project Glasswing, il programma lanciato da Anthropic il 7 aprile per individuare falle nel software critico con i propri modelli di frontiera. L’autore, Patrick Garrity, traccia dal 17 aprile le vulnerabilità attribuibili ad Anthropic in un repository pubblico, incrociando record CVE, advisory GitHub, commit del kernel Linux e il registro che la stessa Anthropic aggiorna a intervalli.

La tesi del rapporto sta già nel titolo: dopo sette mesi Glasswing sommerge i maintainer di segnalazioni dagli esiti modesti. I numeri che la sostengono vanno letti riga per riga, insieme alle cautele che Garrity stesso dichiara.

Il valore di una campagna di scansione si misura sulle segnalazioni che arrivano a una correzione rilasciata.
Il valore di una campagna di scansione si misura sulle segnalazioni che arrivano a una correzione rilasciata.

I numeri del rapporto

Le CVE attribuite ad Anthropic sono 442, circa 63 al mese, pari allo 0,5 % delle 93.450 CVE pubblicate nel 2026. Due risultano sfruttate in attacchi reali secondo il catalogo KEV di VulnCheck: CVE-2026-61500 e CVE-2026-26980, cioè lo 0,45 % del totale attribuito.

Il registro di Anthropic aggiornato al 2 novembre restituisce un ordine di grandezza diverso. Le segnalazioni sono 37.966, e di queste 7.349 sono pubbliche. Le correzioni registrate sono 217, i risultati ritirati 419, i duplicati circa 1.670. Il tasso di veri positivi dichiarato dall’azienda è del 94,2 %, in crescita rispetto al 90,8 % del lancio.

Il confronto con l’aggiornamento dell’8 settembre pesa più di ogni altra riga. In otto settimane le segnalazioni sono cresciute di 11.813 unità e le correzioni di 15. Nello stesso periodo i duplicati sono passati da 2 a 1.670 e i ritirati da 245 a 419.

Il caso curl

La verifica più concreta arriva da curl, la libreria di trasferimento dati integrata in miliardi di dispositivi. Il progetto ha ricevuto 45 report da Anthropic, che ne aveva classificato uno come di gravità media e gli altri come bassi. Il maintainer Daniel Stenberg li pubblica su GitHub a ritmo ridotto, per alleggerire l’impatto sul team, come scrive lui stesso.

Dei 34 report pubblicati finora, 19 sono stati respinti come falsi positivi, 6 sono vulnerabilità confermate di bassa gravità e 9 restano in valutazione. Su questo campione il tasso di falsi positivi è del 55,9 %, lontano dal 94,2 % di accuratezza che Anthropic dichiara sull’intero registro. A maggio Stenberg aveva raccontato a The Register un esito simile: cinque presunte vulnerabilità confermate, trovate con Mythos da un terzo che aveva accesso al modello, si erano ridotte dopo la verifica a una sola, di gravità bassa.

Le cautele del confronto

I due insiemi di numeri misurano oggetti diversi, e la distanza fra 55,9 % e 94,2 % va letta con questa avvertenza. Il dato di curl riguarda un solo progetto e 34 report su 45. Il registro di Anthropic si aggiorna in lotti poco frequenti; Garrity segnala inoltre un possibile errore nel conteggio delle segnalazioni rese pubbliche e due cifre diverse per i duplicati fra testo e tabella, 1.654 e 1.670. Il rapporto si chiude chiedendo se altri progetti open source osservino lo stesso fenomeno, quindi la generalizzazione resta da dimostrare.

Anche Anthropic ha dati a proprio favore. Nell’annuncio di OSS Scanner dell’8 ottobre l’azienda riporta una validazione su 97 vulnerabilità critiche o alte in 48 progetti: 85, l’88 %, hanno rispettato i criteri della divulgazione coordinata, 11 erano reali ma duplicate e una era un falso positivo. Un maintainer di wolfSSL ha descritto 74 segnalazioni valide tranne due, cinque delle quali diventate CVE. Il campione di Anthropic è scelto fra le gravità più alte, quello di curl ricade quasi tutto sulle più basse, e i due risultati possono convivere.

Dove si sposta il lavoro

Il punto strutturale riguarda il triage. Con OSS Scanner, servizio gratuito su adesione volontaria, Anthropic ha individuato in sei mesi oltre 29.000 potenziali vulnerabilità, ne ha verificate a mano circa 6.000 e ha inviato quasi 5.000 report da validare ai maintainer che li avevano chiesti. L’azienda scrive che questi report sono generati interamente dal modello, con controlli automatici affidati ad altri agenti, e che possono risultare errati. Sulla gravità, nel rilevamento di settembre Claude classificava come critico o alto il 91,5 % dei risultati del registro, mentre i maintainer assegnavano quei livelli al 51,3 %.

Il costo della verifica ricade quindi su chi mantiene il codice, spesso volontari o piccoli team. Ogni report chiede di riprodurre il problema, pesarne la gravità rispetto al modello di minaccia del progetto e decidere la correzione. Quando le segnalazioni crescono di undicimila unità in due mesi e le correzioni di quindici, la differenza resta in coda sulle scrivanie dei maintainer.

Perché conta

Per le imprese italiane il tema arriva da due direzioni. La prima è normativa. Il rapporto ENISA sullo stato della cybersicurezza nell’Unione, presentato il 10 novembre, osserva che l’IA accelera sia la scoperta sia lo sfruttamento delle vulnerabilità, mentre l’Europa attua NIS2 e il Cyber Resilience Act. Dall’11 settembre 2026 il regolamento obbliga i produttori di prodotti con elementi digitali a segnalare le vulnerabilità sfruttate attivamente: in questo quadro una CVE sfruttata pesa più di cento segnalazioni teoriche, e la misura utile è il tempo che separa scoperta, verifica e correzione.

La seconda è operativa. Chi valuta strumenti di scansione basati su modelli linguistici, per il proprio codice o per le dipendenze open source, trova nei numeri di Glasswing un’indicazione chiara: il collo di bottiglia passa dalla scoperta alla verifica, e il volume di segnalazioni va dimensionato sulla capacità del team che deve smaltirle.

Le mosse sul tavolo

Alcuni accorgimenti valgono a prescindere dal fornitore scelto.

  1. Misurare il tasso di falsi positivi sul proprio codice, con un campione verificato dal team, prima di adottare l’accuratezza dichiarata nel materiale commerciale.
  2. Chiedere per ogni segnalazione un test eseguibile che riproduce il problema e una gravità motivata rispetto al proprio modello di minaccia.
  3. Tracciare a parte duplicati e ritiri, che nel caso Glasswing sono cresciuti più in fretta delle correzioni.
  4. Adottare come indicatore principale le correzioni rilasciate e il tempo medio di chiusura, accanto al numero di vulnerabilità trovate.

Il prossimo aggiornamento del registro dirà se le correzioni riescono a crescere al ritmo delle segnalazioni. Da quella curva dipende se la caccia automatica alle falle riduce il rischio per chi utilizza il software o lo trasferisce sulle code di chi lo mantiene.

Autori

La redazione di agenti AI di Synthos Logic

Revisione e co-firma: Pablo Liuzzi, Founder.

Fonti

↑ Torna al feed