curl 8.23 corregge una falla HTTP/2 che può diventare RCE sul client

🛡️ Executive Summary

• CVE-2026-92392 colpisce curl e libcurl dalla versione 8.12.0 alla 8.22.0 durante specifici upload HTTP/2 verso un server controllato dall’attaccante.
• La use-after-free è stata trasformata in una RCE dimostrativa, ma l’exploit richiede una conoscenza molto precisa di versione, architettura, heap, librerie e timing; un crash resta l’esito più probabile.
• curl 8.23.0 corregge il problema. Chi non può aggiornare deve applicare la patch oppure evitare temporaneamente HTTP/2 nei workload interessati.

curl 8.23.0 corregge una delle vulnerabilità più serie emerse recentemente nel progetto: un server HTTP/2 malevolo può provocare una use-after-free nel client durante un upload e, in condizioni rigidamente controllate, trasformarla in esecuzione di codice sulla macchina che sta inviando i dati. CVE-2026-92392 riguarda sia il comando curl sia libcurl, quindi il perimetro non coincide con i sistemi nei quali un amministratore esegue manualmente il tool da terminale. La libreria è incorporata in applicazioni, agenti, utility, processi di automazione e software backend e può risultare presente senza essere immediatamente visibile nell’inventario. Il progetto classifica la falla come High, ma distingue chiaramente la possibilità tecnica di ottenere RCE dalla probabilità operativa di riuscirci contro un target non perfettamente conosciuto.

Un server HTTP/2 può lasciare curl con un puntatore verso memoria già liberata

L’advisory ufficiale di curl per CVE-2026-92392 individua il problema nella gestione di un RST_STREAM HTTP/2 durante un upload. Quando il server restituisce il reset con motivazione HTTP_1_1_REQUIRED oppure REFUSED_STREAM, curl può entrare in un percorso nel quale un oggetto struct Curl_easy viene liberato mentre il livello HTTP/2 conserva ancora un riferimento utilizzabile. È la classica condizione use-after-free: il programma considera una zona di memoria non più appartenente all’oggetto originale, ma una parte del codice continua ad accedervi attraverso un puntatore rimasto valido soltanto formalmente. Nel caso dimostrato dal ricercatore, il server controllato dall’attaccante riesce a influenzare ciò che viene allocato successivamente in quella memoria, trasformando la corruzione in una primitiva sfruttabile. Il contesto è diverso dagli attacchi HTTP/2 MadeYouReset già analizzati come problema di gestione dello stato e denial of service: questa volta il confine compromesso è sul client che effettua l’upload.

Leggi anche: Nuovi attacchi ai protocolli espongono HTTP e NAT a desync e hijacking

La RCE è reale ma non significa che ogni curl vulnerabile possa essere preso da remoto

La dimostrazione di code execution rende CVE-2026-92392 importante, ma descriverla genericamente come una RCE remota immediatamente sfruttabile sarebbe scorretto. L’attaccante deve innanzitutto controllare il server verso il quale la vittima sta effettuando un upload HTTP/2 e deve riuscire a far accettare normalmente la connessione. Per trasformare la use-after-free in esecuzione affidabile deve inoltre conoscere la precisa versione di curl e il layout delle strutture, l’architettura del sistema, il comportamento dell’allocator libc, la disposizione dell’heap, le interazioni di nghttp2 e OpenSSL/TLS 1.3, gli effetti delle allocazioni generate dai session ticket e altri elementi che modificano la geometria della memoria. Il PoC richiede inoltre due trasferimenti paralleli sincronizzati correttamente, offset calibrati per la libc e dispone di uno spazio limitato per il comando finale, nell’ordine di poche decine di byte. Il rischio non è teorico, ma l’affidabilità dell’exploit dipende da una conoscenza del target molto superiore a quella disponibile in un normale attacco opportunistico.

Il problema reale di libcurl è sapere dove sia stato incorporato

Le versioni vulnerabili vanno da curl 8.12.0 fino alla 8.22.0 compresa, mentre 8.23.0 contiene la correzione. Il dato operativo più importante è però che libcurl viene utilizzata come dipendenza da software che non necessariamente la espone nel nome del prodotto o nell’interfaccia. Un controllo limitato all’esecuzione di curl --version sull’host può quindi non fotografare l’intero perimetro, perché applicazioni differenti possono incorporare o collegare build proprie della libreria. Questo problema di visibilità era già evidente nella point release Debian 13.6, dove curl compariva tra le librerie di comunicazione aggiornate insieme a OpenSSL, GnuTLS e altri componenti condivisi. Nei container, nelle appliance e nelle pipeline CI/CD l’inventario deve comprendere immagini, SBOM e dipendenze runtime, soprattutto quando i workload eseguono upload automatici verso endpoint esterni.

La scoperta assistita da Claude riapre il tema dell’AI nella vulnerability research

L’advisory attribuisce la segnalazione a “Luna with Claude, Anthropic”, formulazione che rende rilevante anche il modo in cui la vulnerabilità è arrivata al progetto. Non basta però trasformare automaticamente il credito in una dichiarazione secondo cui un modello avrebbe scoperto e sfruttato autonomamente curl: la fonte ufficiale certifica il contributo di Luna e Claude, non una catena completamente autonoma priva di intervento umano. Il dato interessante è piuttosto la qualità del risultato prodotto: una condizione di memoria complessa è stata accompagnata da una dimostrazione capace di portarla fino alla RCE e di obbligare il progetto a trattarla con severità High. Il precedente delle falle Redis e NodeBB individuate attraverso sistemi di vulnerability research basati sull’intelligenza artificiale mostra la stessa evoluzione: l’AI diventa utile quando la generazione dell’ipotesi viene seguita da riproduzione, analisi deterministica e validazione tecnica.

Continua con:

HTTP/2 espone i server web a nuove condizioni di denial of service

curl 8.23 va trattato come aggiornamento di dipendenza e non solo come nuova utility

La remediation indicata dal progetto è netta: aggiornare curl e libcurl alla versione 8.23.0, applicare direttamente la patch se la distribuzione mantiene una versione precedente oppure, come mitigazione temporanea, non utilizzare HTTP/2 nei percorsi interessati. Per gli amministratori la priorità dovrebbe andare ai sistemi che combinano una versione vulnerabile, supporto HTTP/2 e upload automatici verso server esterni o controllabili da terzi: agenti di deployment, backup, strumenti DevOps, integrazioni API, applicazioni backend e pipeline CI/CD sono più interessanti del semplice client utilizzato occasionalmente da una shell. Non risultano dall’advisory campagne di sfruttamento attivo. CVE-2026-92392 va quindi patchata rapidamente senza trasformarla in una RCE universale: il PoC dimostra che il confine tra crash e code execution può essere superato, mentre la complessità dell’exploit mostra quanto sia ancora ampio il divario tra una vulnerabilità tecnicamente sfruttabile e una tecnica pronta per attacchi di massa.