Nuovi attacchi ai protocolli espongono HTTP e NAT a desync e hijacking

🛡️ Executive Summary

• HTTP Terminator usa AI e validazione automatica per generare 30.000 vettori desync e scoprire nuove tecniche contro infrastrutture HTTP reali.
• NatJack manipola lo stato delle tabelle NAT per dirottare sessioni TCP, intercettare DNS, individuare porte mappate e provocare denial of service.
• Linux e Windows correggono CVE-2026-63913 e CVE-2026-56181, ma il problema NatJack più ampio richiede segmentazione, cifratura e hardening della rete.

Due ricerche presentate a Black Hat USA 2026 mettono in discussione assunzioni consolidate alla base delle comunicazioni Internet. HTTP Terminator, sviluppato da James Kettle di PortSwigger, usa l’intelligenza artificiale per generare e validare nuove tecniche di HTTP desynchronization, arrivando a colpire configurazioni reali autorizzate e contribuendo alla scoperta di uno zero-day. NatJack, sviluppato da Malcolm Stagg, interviene invece sulle tabelle NAT per dirottare connessioni TCP, manipolare risposte DNS e degradare la disponibilità della rete. I due lavori riguardano livelli differenti dello stack, ma convergono su un problema comune: sistemi progettati sull’ipotesi che componenti intermedi interpretino e gestiscano correttamente lo stato delle connessioni possono fallire quando un attaccante controlla proprio quella ambiguità.

HTTP Terminator usa l’AI per cercare nuovi desync

HTTP Terminator nasce con un obiettivo diverso rispetto ai tradizionali scanner di vulnerabilità: verificare se un sistema assistito dall’AI possa inventare tecniche offensive nuove, anziché limitarsi a riconoscere bug appartenenti a classi già conosciute. James Kettle ha alimentato il sistema con 138 RFC HTTP e SMTP, scomponendole in circa 15.000 micro-frammenti utilizzati come fonti di ispirazione per generare payload anomali. Il risultato, descritto nella ricerca originale di PortSwigger su HTTP Terminator, è stato un insieme di circa 30.000 vettori desync unici dopo la normalizzazione dei duplicati. La fase più importante non è stata però la generazione: le ipotesi sono state sottoposte a verifiche deterministiche attraverso una estensione di Burp Suite contro circa 30.000 siti autorizzati da programmi bug bounty o vulnerability disclosure. Circa 700 target hanno mostrato comportamenti meritevoli di analisi successiva. Il progetto porta su una scala differente l’automazione della ricerca cyber già osservata nelle falle Redis e NodeBB individuate da agenti AI e nelle sperimentazioni in cui GitHub impiega l’intelligenza artificiale per individuare vulnerabilità nel codice, ma mantiene una netta separazione tra generazione probabilistica dell’ipotesi e verifica tecnica del risultato.

Le ambiguità HTTP possono confondere front-end e back-end

Gli attacchi HTTP desync sfruttano una divergenza tra il modo in cui due componenti interpretano il confine tra richieste successive. Quando un front-end e un back-end HTTP/1.1 non concordano sulla lunghezza o sulla terminazione di una request, una parte della richiesta dell’attaccante può essere interpretata dal server come l’inizio di quella appartenente all’utente successivo. HTTP Terminator ha individuato nuovi trigger basati su comportamenti poco esplorati, compreso l’impiego di multipart/byteranges, che da solo ha prodotto risultati su oltre 200 siti del campione. Il sistema ha inoltre sviluppato un nuovo pattern basato sul dual-matching Content-Length e una tecnica denominata dangling-byte, progettata per rendere più affidabile il Response Queue Poisoning. In questo scenario il front-end perde la corrispondenza tra richieste e risposte e può consegnare a un utente una risposta destinata a un altro, con il rischio di esporre cookie di sessione, token API e informazioni riservate. La debolezza dell’isolamento HTTP era già emersa con la vulnerabilità HTTP/2 capace di provocare denial of service sui server web e con HTTP/2 MadeYouReset, mentre le campagne HTTP/2 Bomb monitorate insieme alle vulnerabilità Windows hanno mostrato come dettagli apparentemente marginali dello stato del protocollo possano produrre conseguenze rilevanti sui sistemi intermedi.

L’AI arriva fino alla discovery cascade di PortSwigger

Il risultato più interessante di HTTP Terminator non consiste soltanto nel numero di payload generati. Kettle ha costruito una discovery cascade nella quale ogni comportamento confermato viene trasformato in nuova materia prima per ulteriori ipotesi. Da questa metodologia è emersa Shared-Parser Confusion, concetto secondo cui funzionalità progettate per il parsing delle risposte potrebbero essere raggiungibili anche attraverso le richieste quando un prodotto condivide codice tra i due percorsi. In questo caso l’AI ha proposto il collegamento, mentre il ricercatore lo ha validato e generalizzato, mostrando chiaramente il limite tra autonomia e lavoro umano. Un’altra anomalia ha contribuito alla scoperta di una vulnerabilità desync in Apache Traffic Server, indicata da PortSwigger come CVE-2026-63078 e già corretta dal progetto, anche se al momento della divulgazione pubblica mancava ancora una matrice completa che permettesse di associare l’identificativo a specifiche release. PortSwigger ha inoltre pubblicato il codice di HTTP Terminator su GitHub, rendendo osservabile l’architettura utilizzata per estrazione delle tecniche, generazione, verifica e investigazione. Il problema della sicurezza dei gateway HTTP è particolarmente rilevante dopo le vulnerabilità Kemp LoadMaster e AWS WAF legate alla gestione del traffico HTTP e le falle critiche Apache corrette insieme a prodotti Cisco e Palo Alto, perché front-end, proxy e back-end costituiscono una singola catena di fiducia.

NatJack manipola direttamente lo stato delle tabelle NAT

NatJack si sposta più in basso nello stack e attacca una funzione presente praticamente in ogni rete moderna. Il Network Address Translation mantiene una tabella che associa le connessioni dei sistemi interni agli indirizzi e alle porte utilizzate verso la rete esterna. Il modello tradizionale assume implicitamente che i client collocati dietro lo stesso dispositivo NAT non possano alterare in modo ostile lo stato delle connessioni appartenenti agli altri host. Malcolm Stagg ha dimostrato che questa assunzione non regge in numerose implementazioni indipendenti. La ricerca ufficiale NatJack descrive quattro famiglie principali di attacco: TCP hijacking, manipolazione delle risposte UDP DNS, disclosure delle porte NAT e table exhaustion. Nel caso del TCP hijacking, un sistema controllato dall’attaccante dietro lo stesso NAT può tentare di rimuovere o sostituire il mapping associato alla connessione della vittima, facendo arrivare sul proprio host traffico destinato originariamente a un altro client. La ricerca interessa direttamente un’area già affrontata nella guida alla configurazione NAT su Linux e nei casi in cui APT28 ha utilizzato router SOHO e DNS hijacking per intercettare il traffico, ma NatJack non richiede necessariamente la compromissione amministrativa del router stesso.

TCP e DNS possono essere dirottati da un host dietro lo stesso NAT

Nel percorso di downstream spoofing, l’attaccante agisce dal lato LAN e manipola il connection tracking affinché il traffico della connessione TCP della vittima venga rediretto verso il sistema controllato. Il risultato può consentire di terminare una sessione, intercettarne il traffico, impersonare temporaneamente il client o iniettare dati quando il protocollo applicativo non offre una protezione crittografica sufficiente. Una variante upstream richiede invece anche un server esterno controllato dall’attaccante e la conoscenza della porta effimera assegnata dal NAT. Il meccanismo applicato al DNS può cancellare o sostituire il mapping relativo a una query UDP: la risposta legittima viene deviata verso l’attaccante, che può tentare di inviare alla vittima una risposta DNS contraffatta. Sono scenari che rendono particolarmente importante la cifratura end-to-end, perché HTTPS/TLS rende molto meno utile l’intercettazione del traffico TCP e DNSSEC, DNS over HTTPS e DNS over TLS riducono l’efficacia della manipolazione delle risposte. L’importanza della protezione DNS è già emersa nelle campagne che hanno dirottato il DNS degli hotel per raggiungere account Microsoft 365 e nelle evoluzioni Linux come NetworkManager 1.58 e IPFire 2.29 dedicate anche alla gestione della rete e del DNS. NatJack mostra però che la sicurezza del resolver non basta se può essere manipolato lo stato della connessione che trasporta la risposta.

Linux corregge CVE-2026-63913 nel connection tracking

Una delle vulnerabilità specifiche emerse dalla ricerca è CVE-2026-63913, assegnata al kernel Linux Netfilter conntrack. Il problema permette a una sequenza composta da un SYN costruito dall’attaccante e da un successivo RST con sequence number non valido di spostare prematuramente una voce TCP verso lo stato CLOSE. Il codice assumeva che il reset fosse la risposta a un SYN precedente senza verificare sufficientemente direzione e relazione tra i pacchetti, permettendo quindi di alterare una voce NAT attiva. La documentazione NatJack dedicata alle patch precisa che la modifica del kernel riduce l’efficacia della tecnica ma non costituisce una correzione completa dell’intera classe di attacco. Il fix è stato incorporato nelle release stabili 5.10.259, 5.15.210, 6.1.176, 6.6.143, 6.12.93, 6.18.35, 7.0.12 e 7.1, oltre ai rami successivi. Il rischio assume una rilevanza particolare nelle infrastrutture containerizzate perché Docker e Kubernetes dipendono intensamente da bridge, conntrack e NAT: il problema si sovrappone quindi alla superficie già emersa con TeamPCP contro Docker e Kubernetes e con le vulnerabilità Docker capaci di portare al takeover remoto.

Windows NAT e Hyper-V ricevono una correzione dedicata

Sul fronte Microsoft, CVE-2026-56181 riguarda un errore di origin validation in Windows NAT con punteggio CVSS 8.3, sfruttabile da un attaccante su una rete adiacente per effettuare spoofing. La falla interessa configurazioni nelle quali Windows gestisce NAT anche per ambienti Hyper-V. Microsoft ha corretto il comportamento negli aggiornamenti distribuiti per Windows 11 24H2, 25H2, 26H1 e Windows Server 2025, mentre NatJack include il problema tra le manifestazioni implementation-specific della classe più ampia. Il dato più importante è proprio questa distinzione: patchare CVE-2026-56181 e CVE-2026-63913 elimina vulnerabilità concrete di Windows e Linux, ma non dimostra che ogni possibile manipolazione dello stato NAT sia risolta. La ricerca riferisce che implementazioni differenti, sviluppate indipendentemente, mostrano comportamenti vulnerabili e che sono interessati anche scenari con router, firewall, hypervisor, container e servizi cloud. Il tema dell’isolamento virtuale si collega alle precedenti vulnerabilità KVM e Linux capaci di mettere a rischio guest e host e alle campagne che sfruttano router DrayTek insieme a infrastrutture Kubernetes, perché l’isolamento logico non garantisce protezione quando più workload condividono lo stesso stato di rete.

Cloud, container e VLAN richiedono una segmentazione più rigida

NatJack non rappresenta soprattutto una minaccia per il classico utente domestico: l’attaccante deve generalmente controllare un host privilegiato o comunque sufficientemente capace di generare traffico costruito dietro lo stesso NAT della vittima. Lo scenario diventa molto più realistico in cloud, hosting, laboratori, reti aziendali, Kubernetes e piattaforme che eseguono workload di clienti differenti. La ricerca raccomanda di evitare che sistemi affidabili e non affidabili condividano lo stesso NAT, separare workload attraverso host o nodi distinti, rimuovere la capability NET_RAW dai container che non ne hanno bisogno e applicare IP Source Guard, ACL e segmentazione VLAN. AWS ha dichiarato di avere rafforzato la validazione dello stato per NAT Gateway e Network Load Balancer, mentre eero ha introdotto proprie protezioni. Il tema è coerente con l’evoluzione delle minacce cloud-native osservata con ShadowV2 e le botnet costruite direttamente sulle infrastrutture cloud e con la necessità di proteggere anche i dispositivi perimetrali evidenziata dalle vulnerabilità critiche nei router ASUS.

Due ricerche mettono in crisi la fiducia nello stato delle connessioni

HTTP Terminator e NatJack operano a livelli diversi, ma entrambi sfruttano divergenze nello stato delle comunicazioni. Nel primo caso front-end e back-end possono non concordare su dove termini una richiesta HTTP; nel secondo un dispositivo NAT può accettare pacchetti capaci di modificare uno stato che dovrebbe appartenere esclusivamente alla connessione della vittima. HTTP Terminator aggiunge inoltre un elemento nuovo: l’AI può esplorare sistematicamente migliaia di combinazioni protocollari, mentre sistemi deterministici stabiliscono quali producano davvero una contaminazione cross-request. NatJack mostra invece che assunzioni consolidate da decenni possono restare valide soltanto finché tutti i sistemi posti dietro la stessa infrastruttura vengono considerati cooperativi. In reti moderne con container, macchine virtuali, tenant cloud e workload non affidabili, questa premessa non è più sostenibile. Le difese convergono quindi su pochi principi: ridurre HTTP/1.1 upstream, mantenere aggiornati kernel e sistemi Windows, cifrare il traffico anche internamente, separare workload con livelli di fiducia differenti e non considerare proxy, NAT o firewall come confini automaticamente sicuri soltanto perché si trovano al centro della rete.