L’AI di AISLE trova sei vulnerabilità in curl che OpenAI e Anthropic non avevano viste

C’è un numero che fotografa meglio di qualsiasi analisi il momento che sta attraversando la sicurezza informatica ai tempi dell’intelligenza artificiale: sei a zero. È il punteggio con cui il sistema autonomo di AISLE, una startup che si occupa di scoperta e correzione delle vulnerabilità, ha superato i modelli di frontiera di OpenAI e Anthropic su uno dei terreni più ostici che esistano, il codice sorgente di curl.

curl è letteralmente ovunque. Viene eseguito su oltre venti miliardi di installazioni nel mondo, dagli smartphone alle automobili, dai frigoriferi connessi fino ai veicoli spaziali, ed è considerato uno dei progetti open source più controllati e revisionati di sempre. Scovare nuove falle al suo interno è un’impresa che mette in difficoltà chiunque, esseri umani inclusi.

Eppure è accaduto, e i numeri raccontano una storia netta.

Cosa è successo: sei CVE dove i modelli vedevano il vuoto

La vicenda nasce da un post pubblico. Il 24 agosto 2026 Daniel Stenberg, fondatore e manutentore storico di curl, ha scritto che per la versione successiva del progetto risultavano in sospeso soltanto tre CVE, cioè tre vulnerabilità già note e in attesa di correzione. Aveva appena dato in pasto il codice ai sistemi di sicurezza basati sull’AI dei grandi laboratori, e il responso era stato lapidario: lo strumento Mythos di Anthropic diceva di non riuscire a trovare altro, mentre la lista restituita da Codex Security di OpenAI era semplicemente vuota.

A quel punto è entrata in scena AISLE, che ha puntato il proprio sistema autonomo sullo stesso identico codice.

Il giorno seguente Stenberg ha pubblicato un secondo aggiornamento diventato virale tra gli addetti ai lavori: “Mythos: 0, Aisle: 29”. Ventinove segnalazioni contro zero. Non tutte, com’è ovvio, si sono trasformate in vulnerabilità confermate, ma il team di sicurezza di curl ne ha esaminate sei e le ha ritenute abbastanza serie da meritare l’assegnazione di un CVE pubblico, l’identificativo che certifica ufficialmente una falla di sicurezza. Il resoconto pubblicato da AISLE ricostruisce l’intera vicenda con gli screenshot dei post di Stenberg.

Le sei vulnerabilità sono state corrette tutte nella release curl 8.22.0, appena distribuita, e accreditano come autore della scoperta Stanislav Fort di AISLE. Tre erano state riportate il 24 agosto, due il 26 e una il 27 agosto.

Nel giro di pochi giorni il conto delle CVE in sospeso di curl è salito da tre a dieci, e sei di quelle dieci portavano la firma di AISLE.

Perché curl è un banco di prova così severo

Per cogliere la portata del risultato bisogna capire che cosa significhi cercare bug proprio in curl. Parliamo di una libreria nata nel 1998, mantenuta con cura maniacale, sottoposta a fuzzing continuo, ad analisi statica del codice e a revisioni umane da parte di una comunità che la conosce riga per riga. È il tipo di software in cui le vulnerabilità facili sono state eliminate da anni.

Ciò che resta si annida negli angoli: configurazioni particolari, combinazioni rare di opzioni, interazioni sottili tra componenti diversi. Non a caso tutte e sei le CVE trovate da AISLE sono classificate come gravità bassa. Non è un limite del sistema, ma il riflesso della maturità ingegneristica di curl, perché le falle ancora presenti tendono a manifestarsi solo in scenari stretti, con un impatto pratico contenuto.

Resta il fatto che erano falle reali, sfuggite a tutti fino a quel momento.

Le sei vulnerabilità corrette in curl 8.22.0

Ecco, in sintesi, le sei CVE individuate dal sistema di AISLE e chiuse con l’ultima versione:

• CVE-2026-80229: use-after-free nel provider OpenSSL.
• CVE-2026-80230: aggiramento del pinning dei certificati con OpenSSL.
• CVE-2026-80231: riuso della connessione legato allo store delle CA di sistema.
• CVE-2026-80255: bypass dell’attributo secure tramite un carattere di tabulazione.
• CVE-2026-82208: cache delle CA di wolfSSL che scavalca la callback di verifica.
• CVE-2026-82209: cookie con suffisso pubblico associato a un dominio errato.

Sono dettagli molto tecnici, ma il filo comune è chiaro: quasi tutte toccano il cuore della sicurezza delle connessioni, cioè il modo in cui curl gestisce certificati, cifratura e cookie.

Un confronto pulito, non un benchmark di laboratorio

Il punto più interessante, sul piano del metodo, è come è avvenuto il confronto. Non si è trattato di una gara capture-the-flag né di un benchmark con risposte note, il tipo di test in cui i modelli possono aver già incontrato le soluzioni durante l’addestramento. Qui il sistema ha analizzato codice di produzione reale, e a decidere se ogni segnalazione fosse autentica e se meritasse un CVE sono stati i manutentori di curl, non l’azienda che ha costruito lo strumento.

C’è di più. Poiché Stenberg aveva reso pubblico il risultato a zero dei sistemi di frontiera prima che AISLE entrasse in azione, il confronto ha avuto una proprietà rara, perché la linea di partenza era pubblica e con data certa, fissata prima ancora che il nuovo risultato esistesse.

I CVE non sono una metrica perfetta, ma offrono una validazione esterna molto solida: ognuno rappresenta una falla prima sconosciuta, riprodotta e accettata da esperti del settore, poi corretta per gli utenti reali.

Non solo curl: l’ombra del kernel Linux

Il caso potrebbe non essere isolato. Sotto il post di Stenberg è intervenuto Greg Kroah-Hartman, il manutentore delle versioni stabili del kernel Linux, con un commento che pesa: dice di osservare lo stesso schema anche nel kernel, senza capire che cosa faccia AISLE di diverso, ma restando comunque colpito dai risultati.

Se la tendenza trovasse conferma su una base di codice enorme e critica come quella di Linux, le implicazioni per la sicurezza dell’intero ecosistema open source sarebbero notevoli.

AISLE riassume la propria posizione con una formula, System over Model, il sistema conta più del modello. L’idea è che, per la scoperta di vulnerabilità nel mondo reale, un sistema specializzato e costruito attorno al problema possa competere con i modelli generalisti dei grandi laboratori, e in diversi casi superarli.

Cosa cambia per la sicurezza del software

Il risultato si inserisce in una corsa che hai già visto accelerare in questi mesi. I laboratori di frontiera stanno spingendo l’AI verso la cybersicurezza a ritmo serrato: OpenAI ha appena presentato Astra, il modello che ha superato la soglia critica di cybersicurezza del suo framework, mentre Google ha lanciato una variante dedicata come Gemini 3.8 Flash Cyber, pensata per coding, agenti e sicurezza. Sul versante della correzione automatica, OpenAI aveva già mostrato con Daybreak un’AI che non si limita a trovare le vulnerabilità ma prova a correggerle.

La vicenda curl aggiunge un tassello scomodo a questo quadro: la potenza grezza di un modello, da sola, non basta. Lo stesso Mythos, lo strumento di sicurezza che Anthropic ha aggiornato insieme a Claude Fable 5.1, in questo test non ha prodotto risultati, mentre un sistema più piccolo e mirato ne ha trovati a decine.

Per chi si occupa di sicurezza il messaggio è duplice. Da un lato, strumenti come quello di AISLE possono diventare un moltiplicatore per i team che difendono software critico, portando alla luce falle che sfuggono anche alle revisioni più accurate. Dall’altro, la stessa capacità, se finisse nelle mani sbagliate, accorcerebbe la distanza tra la scoperta e lo sfruttamento di una vulnerabilità.

È la doppia faccia di ogni strumento potente, e la sicurezza informatica lo sa bene.

In conclusione

Il sei a zero su curl non dimostra che i modelli di OpenAI e Anthropic siano deboli, né che AISLE abbia risolto il problema della sicurezza del software. Dimostra però una cosa concreta e verificabile: su un codice reale, controllato all’inverosimile, un sistema specializzato ha trovato ciò che gli strumenti generalisti non avevano visto, e lo ha fatto in modo trasparente, con i manutentori nel ruolo di giudici.

È un promemoria utile mentre l’AI entra sempre più a fondo tanto nella difesa quanto nell’attacco informatico. Se vuoi capire come si muovono i grandi laboratori su questo terreno, continua a seguire i nostri aggiornamenti sull’intelligenza artificiale applicata alla cybersicurezza, perché è qui che si gioca una delle partite più importanti dei prossimi anni.