HTTP Terminator usa l’IA per scoprire nuove tecniche di desincronizzazione HTTP

30.000 vettori testati su siti autorizzati

PortSwigger ha presentato HTTP Terminator, un sistema di ricerca assistito dall’intelligenza artificiale sviluppato da James Kettle per generare e validare tecniche di HTTP desynchronization.

Il progetto ha suddiviso 138 RFC HTTP e SMTP in circa 15.000 frammenti, utilizzati per produrre 30.000 vettori candidati. Gli stessi vettori sono stati verificati su 30.000 siti, tutti sottoposti a test con autorizzazione ottenuta tramite programmi bug bounty o di vulnerability disclosure.

Circa 700 obiettivi hanno mostrato segnali di vulnerabilità prima delle verifiche più approfondite. Tra i bersagli figuravano banche, infrastrutture governative, prodotti di sicurezza e un aeroporto.

Una tecnica basata sull’header Content-Type: multipart/byteranges ha funzionato su diverse implementazioni server e ha coinvolto oltre 200 siti, compresa una banca statunitense non identificata.

Nuovi attacchi contro il parsing delle richieste

HTTP Terminator ha prodotto diversi schemi, tra cui un pattern con doppio Content-Length e la tecnica dangling-byte. Quest’ultima mira a rendere più affidabile la Response Queue Poisoning, o RQP.

Nella RQP, il frontend può perdere l’associazione corretta tra le richieste degli utenti e le risposte generate dal backend. Il risultato può essere la consegna a un utente della risposta destinata a un altro, con possibile esposizione di cookie di sessione o chiavi API.

La tecnica dangling-byte lascia una richiesta smuggled priva di un byte. La seconda risposta del backend resta quindi in attesa, fino a quando una richiesta della vittima non fornisce il dato mancante. Questo riduce la race condition tipica degli attacchi RQP.

Il sistema ha valutato autonomamente 16 idee per migliorare la RQP, ma soltanto dangling-byte ha superato la fase di validazione.

È emerso anche il concetto di Shared-Parser Confusion: un server che riutilizza la stessa logica di parsing può applicare impropriamente alle richieste regole pensate per elaborare le risposte. HTTP Terminator ha proposto il concetto, mentre Kettle ne ha curato la verifica e la generalizzazione.

Il caso Apache Traffic Server e CVE-2026-63078

Durante una fase investigativa guidata da un ricercatore, una richiesta malformata ha portato all’identificazione di uno zero-day in Apache Traffic Server, associato a CVE-2026-63078.

Il 7 agosto, una verifica pubblica non ha trovato il relativo record né su CVE.org né sul NVD. Inoltre, l’advisory Apache di luglio, dedicato a 34 vulnerabilità, non includeva questo identificativo.

Secondo i ricercatori, il problema è stato corretto, ma non è ancora noto quale release di Apache Traffic Server corrisponda pubblicamente alla versione risolta. Non sono disponibili neppure CVSS, vettore di attacco o l’elenco preciso delle versioni vulnerabili.

La distinzione è rilevante: alcune tecniche sono state generate e dimostrate autonomamente dal sistema, mentre la vulnerabilità Apache e Shared-Parser Confusion hanno richiesto l’intervento umano.

Come ridurre il rischio

Quando possibile, gli amministratori dovrebbero evitare l’uso di HTTP/1.1 verso i server upstream. Se non è possibile rimuoverlo, è opportuno:

• applicare una allow-list dei metodi HTTP a entrambi i livelli della catena;
• limitare i metodi autorizzati a trasportare un request body;
• verificare gli advisory Apache e le release correttive disponibili per Traffic Server;
• eseguire test mirati contro desincronizzazione HTTP, RQP, parsing condiviso e tecniche CRLF.

Per le verifiche sono disponibili anche gli strumenti crlf-desyncs e crlf-powered-desync-scanner, pubblicati da ricercatori specializzati negli attacchi desync basati su CRLF.