curl: un'AI ha trovato 6 CVE che i modelli di frontiera no

Il 24 agosto 2026 Daniel Stenberg, fondatore di curl, ha scritto che a nove giorni dalla release successiva il progetto aveva solo tre CVE in attesa di annuncio — due low, una medium — e che gli scanner AI di frontiera puntati sul codice non avevano prodotto nulla. Mythos di Anthropic: niente. Codex security di OpenAI: lista vuota. ZeroPath: niente. Il giorno dopo è arrivato l'aggiornamento che in molti hanno screenshottato: "Mythos: 0. Aisle: 29." Una startup poco nota aveva depositato 29 segnalazioni contro un codice che tre modelli di frontiera avevano appena dichiarato pulito, e sei sono state accettate come CVE reali e corrette in curl 8.22.0 il 2 settembre 2026.

Il risultato conta meno per i sei bug — tutti classificati low — e molto di più per ciò che dice su come l'AI troverà le vulnerabilità d'ora in avanti. curl non è un bersaglio facile. Gira su una stima di 30 miliardi di dispositivi: sistemi operativi, container, runner CI/CD, package manager, SDK, automobili. È uno dei codebase C più letti, più fuzzati e più controllati di internet. Tre dei migliori modelli generalisti sul mercato l'hanno analizzato e non hanno trovato nulla di nuovo. Una pipeline mirata su modelli più economici ne ha trovati sei. Il divario non è la potenza del modello. È il disegno del sistema.

Che cosa ha trovato davvero l'AI vulnerability discovery di AISLE

Le sei CVE accettate, tutte corrette in curl 8.22.0 e segnalate da Stanislav Fort di Aisle Research, si concentrano su una sola parte della libreria — la gestione delle sessioni e delle connessioni TLS:

CVE	Componente	Classe
CVE-2026-80229	provider OpenSSL 3, multi interface	Use-after-free su heap (la connessione TLS in pool sopravvive al suo easy handle)
CVE-2026-80230	certificate pinning OpenSSL	Bypass del pinning
CVE-2026-80231	CA store nativo	Riuso errato della connessione
CVE-2026-80255	gestione cookie	Bypass dell'attributo Secure tramite carattere di tabulazione
CVE-2026-82208	cache CA wolfSSL	Un hit in cache scavalca il callback di verifica
CVE-2026-82209	gestione cookie	Cookie con public-suffix a dominio

Nessuna di queste è un titolone da esecuzione di codice remoto. La CVE-2026-80229, la più interessante del gruppo, è un use-after-free in cui una connessione TLS messa in pool dalla multi interface di libcurl può sopravvivere all'easy handle che l'ha creata, lasciando un puntatore penzolante verso lo stato liberato del provider OpenSSL — raggiungibile solo in configurazioni OpenSSL 3 specifiche, motivo per cui il punteggio è basso. Il punto non è mai stata la gravità. Il punto è che Aisle ha depositato 29 candidate, sei hanno superato il triage diventando CVE, e la stessa finestra ha prodotto zero da tre modelli di frontiera. Greg Kroah-Hartman, manutentore del kernel Linux stable, ha risposto nel thread: "Sto vedendo la stessa cosa anche per Linux. Non ho idea di cosa faccia Aisle di diverso, ma wow."

Perché i modelli di frontiera non hanno trovato niente

La lettura pigra è "modello più grande, più bug". Il risultato su curl è il controesempio. La tesi dichiarata di Aisle è che un sistema specializzato costruito su modelli più economici batte un modello di frontiera usato come scanner, e gira in locale senza spedire il codice del bersaglio a un'API. Stenberg, che ha passato due anni a respingere il diluvio di report AI di bassa qualità sulla coda HackerOne di curl, è stato netto sul perché ha preso sul serio questi: Aisle "dedica vero tempo di ingegneria per assicurarsi che i risultati siano curati e di qualità alta." Ventitré delle 29 segnalazioni non sono diventate CVE — non è un fallimento, è il triage che funziona, esattamente ciò che un modello grezzo che scarica findings in un issue tracker non fa.

La differenza è l'impalcatura attorno al modello, non il modello. Uno scanner di frontiera eseguito una tantum su un file risponde alla domanda "c'è un bug in questa funzione". Una pipeline di discovery mantiene lo stato sull'intero codebase, formula un'ipotesi su una classe di bug e poi va a cercare ogni punto in cui quella classe si ripresenta. È una ricerca fondamentalmente diversa, ed è il motivo per cui la seconda lettura dei risultati su curl è quella che dovrebbe preoccupare i difensori.

L'AI vulnerability discovery trova pattern, non bug isolati

Guardate cosa ha trovato Aisle e poi guardate la storia stessa di curl. La release di giugno 2026 ha corretto CVE-2026-8932, un bypass di autenticazione nel riuso delle connessioni presente fin da curl 7.7 del 22 marzo 2001 — la vulnerabilità di sicurezza più vecchia mai segnalata nel progetto, rimasta nascosta per 25 anni. Non è una classe nuova. curl corregge da un decennio bug di riuso della connessione e use-after-free sulle sessioni TLS:

• CVE-2016-5421 — use-after-free che permette a un attaccante di influenzare quale connessione viene usata.
• CVE-2020-8231 — puntatore penzolante che porta libcurl a usare la connessione sbagliata.
• CVE-2021-22901 — use-after-free quando arriva un session ticket TLS 1.3 su una connessione.
• CVE-2023-27536 — bypass di autenticazione nella funzione di riuso delle connessioni.

I findings del 2026 — 80229, 80231, la 8932 vecchia di 25 anni — sono la stessa famiglia. È questo l'indizio. Una pipeline agentica che ha interiorizzato "libcurl riusa connessioni e sessioni TLS tra handle diversi, e la contabilità del ciclo di vita è fragile" macinerà ogni percorso di riuso nel codice in cerca del prossimo puntatore penzolante. Un fuzzer ha bisogno di un input che riproduca il bug; una scansione LLM una tantum ha bisogno che il bug sia visibile nella finestra che le è stata mostrata. La ricerca guidata dal pattern sull'intero albero sta nel mezzo, ed è esattamente la capacità che ha appena superato tre modelli di frontiera su curl.

"Quindi l'AI non ha inventato un attacco nuovo — ha solo trovato altri sei esemplari di un bug che spediamo da venticinque anni?" "Esatto. È il problema più difficile, ed è quello che scala."

Cosa significa per chi difende

Ne seguono due conclusioni, e nessuna delle due è comoda.

Primo, "molto controllato" non è un traguardo. curl è fuzzato in continuazione da OSS-Fuzz, letto da migliaia di ingegneri e mantenuto da qualcuno che tratta i report di sicurezza come un lavoro a tempo pieno. Eppure ha ceduto sei findings a un sistema che diciotto mesi fa non esisteva. Qualsiasi codebase interno che ha avuto meno attenzione — cioè tutti — ne sta portando di più.

Secondo, questa capacità è indipendente dal modello ed economica. Tutto l'argomento di Aisle è che non serve l'accesso a un modello di frontiera per usarla; serve il sistema giusto attorno a un modello modesto, e gira on-prem. È una buona notizia per i difensori che vogliono usarla in casa e una cattiva notizia perché significa che la stessa discovery guidata dai pattern è a disposizione di chiunque la stia puntando sul vostro codice, sul proprio hardware, senza bolletta API né rate limit. L'asimmetria che proteggeva il software interno oscuro — "nessuno si prenderà la briga di fare reverse engineering di questa roba" — sta uscendo dal mercato.

Remediation

Le sei CVE di curl sono low e già corrette, quindi qui l'azione è meno "emergenza" e più "dimostra di saperlo fare davvero", perché curl è il problema di inventario più difficile che esista: è incorporato, non installato.

1. Sono interessato? — le versioni corrette in 8.22.0 sono curl da 8.14.0 a 8.21.0. Il binario curl visibile è la parte facile:

curl --version | head -1
# trova ogni libcurl su disco, non solo quello su $PATH
find / -name 'libcurl*.so*' 2>/dev/null -exec sh -c 'echo "$1:"; strings "$1" | grep -m1 "^libcurl/"' _ {} \;

La parte difficile sono le copie che non avete installato: linkate staticamente dentro binari di terze parti, cotte dentro le immagini base dei container, spedite dentro runtime di linguaggi e SDK, incise nel firmware di appliance e dispositivi IoT. Tiratela fuori dagli SBOM e dagli scan delle immagini container, non solo dal package manager dell'host: fate grep sull'inventario delle immagini per curl e libcurl e riconciliate con 8.22.0.

2. Patch — versione corretta esatta. Aggiornate curl e libcurl a 8.22.0 o successiva. Per i container, ricostruite da un'immagine base aggiornata; un aggiornamento di curl sull'host non tocca la libcurl linkata staticamente in un'immagine già in esecuzione.

3. Non potete patchare subito? — controlli compensativi. Questi bug vivono nel riuso di connessioni e sessioni TLS. Dove un'applicazione usa la multi interface di libcurl verso endpoint TLS non fidati, disabilitare il riuso della connessione (CURLOPT_FRESH_CONNECT / CURLOPT_FORBID_REUSE) chiude i percorsi di use-after-free e di confusione nel riuso, a un costo di prestazioni. Fate il pinning dei certificati a livello applicativo invece di affidarvi al percorso di pinning colpito.

4. Cercate compromissioni. Non ci sono IOC di rete puliti per un use-after-free locale a bassa gravità — la postura di detection onesta è trattarli per ora come problemi di affidabilità e sorvegliare le conseguenze di un bug di connessione sbagliata: sessioni TLS verso un endpoint con cui il processo non dovrebbe parlare, credenziali o cookie che compaiono su connessioni per cui non erano scopati. Mappate l'abuso su MITRE ATT&CK T1557 (Adversary-in-the-Middle) per i bypass di riuso/pinning e T1552 (Unsecured Credentials) per le classi di scope dei cookie e affini a netrc.

5. Bonificate e verificate. Dopo la patch, confermate che il processo in esecuzione abbia effettivamente caricato la nuova libreria — lsof -p <pid> | grep libcurl su un processo vivo, non solo la versione su disco — perché un servizio a lunga vita tiene mappata la vecchia libcurl finché non viene riavviato. Ricostruite e ridistribuite i container; non fidatevi che una patch sull'host in-place li abbia raggiunti.

Dove si colloca Zero Hunt

Il risultato su curl è, in sordina, la validazione di una scommessa che Zero Hunt ha fatto nella propria architettura. Il riflesso del settore è puntare il più grande modello di frontiera disponibile su un bersaglio e chiedergli di trovare bug. Le sei CVE di Aisle contro tre scanner di frontiera a mani vuote dicono che è la forma sbagliata: ciò che vince è un sistema mirato che mantiene lo stato sull'intero bersaglio, ragiona sulle classi di bug e fa il triage del proprio output — eseguito su modelli che controllate, in locale.

È questo lo swarm a 10 agenti di Zero Hunt. Non è un singolo modello a cui si chiede di "trovare vulnerabilità". Gli agenti Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic e Report sono coordinati da un AI Controller, e ogni exploit è scritto per-bersaglio da un LLM locale sull'appliance — nessun codice esce dalla macchina, nessuna API esterna vede il vostro sorgente o il vostro traffico, esattamente il modello on-prem che Aisle sostiene. La ricerca guidata dal pattern che ha permesso ad Aisle di trovare il sesto bug di riuso della connessione dopo aver trovato il primo è la stessa disciplina dietro l'AI Gym: 142+ skill auto-evolutive, backtestate contro Vulhub, NYU CTF Bench e 314 task black-box basati su CVE prima che una skill tocchi un bersaglio reale, così che una capacità nuova sia dimostrata generalizzare invece che presa sulla fiducia. E poiché ogni finding è firmato ECDSA al momento della scrittura, l'output è una catena di prove, non uno scarico grezzo di 29 candidate da far triaggiare a qualcun altro.

curl ha ricevuto sei bug low e una patch. La lezione duratura è quella che Greg Kroah-Hartman ha segnalato dal lato kernel: la discovery agentica mirata sta già trovando, nel codice più controllato di internet, bug rimasti lì per venticinque anni. L'unica domanda che un difensore dovrebbe porsi è se quella capacità raggiungerà il proprio codice prima dal proprio red team, o prima da quello di qualcun altro.