Direct naar de inhoud
Beveiligingsnieuws

HTTP desync: AI vond Apache zero-day en nieuwe technieken

HTTP desync

PortSwigger meldt dat het HTTP Terminator-onderzoekssysteem, ondersteund door AI, nieuwe manieren heeft gevonden om HTTP desync aanvallen uit te voeren. Daarbij werden duizenden mogelijke aanvalspaden doorzocht, waarna de onderzoekers een set technieken konden genereren én bewijzen. In een tweede, door mensen begeleide ontdekkingstraject werd daarnaast een Apache Traffic Server zero-day gevonden.

De bevindingen zijn relevant voor organisaties die reverse proxies, load balancers of andere HTTP-frontends inzetten. Zulke omgevingen kunnen kwetsbaar worden wanneer front-end en back-end elkaars request- of responsverwachtingen niet meer synchroon verwerken.

Wat is HTTP desync en waarom is het gevaarlijk?

Bij HTTP desync raakt de verwerking van HTTP-verzoeken uit sync tussen componenten in een keten (bijvoorbeeld een proxy vooraan en een applicatieserver achteraan). Daardoor kan de ene component denken dat het de respons bij een bepaald verzoek hoort, terwijl de andere component een ander verzoek als uitgangspunt neemt.

In dit onderzoek draait de aanvalskans vooral om een mechanisme dat kan leiden tot response queue poisoning (RQP). Het idee: een front-end kan de mapping verliezen tussen back-end responsen en de gebruikers die die responsen zouden moeten ontvangen. Daardoor is het theoretisch mogelijk dat informatie uit de ene sessie terechtkomt in de context van een andere gebruiker—met risico’s voor bijvoorbeeld sessiecookies of API-sleutels.

HTTP Terminator: AI die kandidaataanvallen genereert

Volgens PortSwigger werd HTTP Terminator ontwikkeld door James Kettle. Het systeem onderzocht 30.000 kandidaat-aanvalsvectoren door te zoeken in een grote ruimte aan varianten. Dat gebeurde niet willekeurig: Kettle gebruikte een set standaarden als inspiratiebron.

Concreet kreeg het systeem 138 HTTP- en SMTP RFC’s als input. Deze RFC’s werden vervolgens opgedeeld in ongeveer 15.000 kleinere fragmenten. Daarmee kon HTTP Terminator een grote verzameling unieke kandidaatvectoren genereren, die daarna systematisch werden getest.

Nieuw: triggers, dubbele Content-Length en ‘dangling-byte’

De onderzoekers rapporteren drie opvallende ontdekkingen die samen nieuwe HTTP desync-mogelijkheden creëren:

  • Nieuwe desync-triggers die reageren op specifieke patronen in HTTP-verwerking.
  • Een dual-matching Content-Length patroon waarmee requestlengtes op een manier kunnen worden geïnterpreteerd die tot desync kan leiden.
  • Een ‘dangling-byte’ techniek die RQP betrouwbaarder moet maken.

Volgens de toelichting werden in de eerste testfase ongeveer 700 kwetsbare targets gevonden. Daarna volgde diepere validatie en aanvullend onderzoek op basis van RQP.

Hoe werkt ‘dangling-byte’ om RQP betrouwbaarder te maken?

De dangling-byte-aanpak probeert een raceconditie te vermijden die RQP op veel sites onbetrouwbaar maakt. De techniek laat een gesmokkelde request precies één byte kort, waardoor een tweede back-end respons pas wordt geproduceerd wanneer een slachtofferverzoek die ontbrekende byte levert. Daardoor wordt timing minder kritisch.

Bij wie werd kwetsbaarheid gevonden?

De resultaten betroffen een mix van organisaties, zoals banken, infrastructuur van de overheid, beveiligingsproducten en zelfs een luchthaven. PortSwigger vermeldt ook dat één specifieke multipart/byteranges-aanpak in meerdere serverimplementaties werkte en in de testset meer dan 200 websites blootlegde, waaronder een niet bij naam genoemde Amerikaanse bank.

De kernboodschap: HTTP desync is niet alleen een theoretisch concept—AI-gestuurd onderzoek kan patronen vinden die in de praktijk bij uiteenlopende implementaties problemen veroorzaken.

Shared-Parser Confusion: bredere aanvalsklasse

Naast concrete desync-technieken beschrijft PortSwigger ook een breder concept: Shared-Parser Confusion. Het systeem stelde dit concept voor, maar Kettle kon het vervolgens valideren en generaliseren.

Belangrijk detail is dat de ontdekking niet alleen uit autonomie bestond: de onderzoekers geven aan dat de autonomiegrens in het onderzoek niet volledig gelijk loopt met de uiteindelijke validatie. Er werden technieken zelfstandig gegenereerd en bewezen, maar sommige onderdelen vergden een menselijke stap om ze aan te scherpen of te bevestigen.

Apache Traffic Server zero-day via mens-geleide cascade

Naast het AI-gedreven pad was er een aparte mens-geleide ontdekkingstraject. In die route werd een zero-day in Apache Traffic Server blootgelegd. PortSwigger stelt dat het probleem inmiddels is gepatcht en dat het is gevolgd als CVE-2026-63078.

Op basis van een check op 7 augustus meldt The Hacker News dat er toen nog geen publiek record te vinden was voor CVE-2026-63078 in CVE.org of NVD. Ook stond het niet in een Apache advisory met 34 andere kwesties. Daardoor bestond er op dat moment een verificatiegat: verdedigers konden de CVE nog niet koppelen aan een exact gereleased fix-onderdeel.

Dat betekent praktisch: ook al is een patch volgens de onderzoekers beschikbaar, organisaties doen er goed aan om de exacte versies en release notes te controleren zodra die publiek beschikbaar zijn.

Verdediging: wat raden de onderzoekers aan?

De verdediging die PortSwigger aanbeveelt is relatief duidelijk, maar vraagt om discipline in configuratie en aanpak van HTTP-verwerking:

  • Vermijd HTTP/1.1 upstream: PortSwigger adviseert expliciet om upstream geen HTTP/1.1 te gebruiken.
  • Als HTTP/1.1 niet kan verdwijnen: gebruik allow-listing op beide lagen (zowel aan frontend- als back-end zijde).
  • Beperk welke methodes request bodies mogen dragen. Door regels strakker te maken, verklein je de ruimte waarin desync-triggers kunnen werken.

Deze punten sluiten aan op het bredere idee achter HTTP desync: hoe minder ambiguïteit in parsing en forwarding, hoe kleiner de kans dat front-end en back-end verschillende interpretaties hanteren.

Open source tools en onderzoeksmateriaal

PortSwigger heeft HTTP Terminator open-sourced gemaakt. De paper identificeert niet welke exacte model- of versiemix bepaalde autonome ontdekkingen produceerde. In de vrijgegeven implementatie wordt wel vermeld dat Claude wordt gebruikt voor documentextractie en test-case generatie, terwijl de investigator-stap Claude Code vereist.

Daarnaast brachten onderzoekers tools uit om CRLF-gedreven desync beter te bestuderen, waaronder crlf-desyncs en crlf-powered-desync-scanner. Als je in je omgeving werkt met reverse proxies, gateways of HTTP-parsers, kunnen zulke tools helpen bij het beoordelen van blootstelling—mits je alleen test binnen geautoriseerde omgevingen.

Wat betekent dit voor jouw security roadmap?

Deze casus laat zien hoe snel HTTP desync zich kan ontwikkelen wanneer AI grote input-ruimtes doorzoekt. Tegelijkertijd gaat het niet alleen om ‘één bug’: het onderzoek benoemt technieken, patronen en parsingverwarring als terugkerende mechanismen.

Daarom is het slim om je verbeteringen niet te beperken tot patchen alleen. Check ook:

  • Of je HTTP-verkeer tussen lagen consistent wordt geparseerd (en niet afhankelijk is van onderling verschillende defaults).
  • Of je restricties hebt rond methodes die request bodies mogen bevatten.
  • Of je upstream kunt overstappen op infrastructuur waar HTTP/1.1 upstream niet nodig is.

Wil je vergelijkbare aanpakken lezen over desync-gerelateerde of parsing-gedreven aanvallen, dan is het interessant om ook te kijken naar ontwikkelingen rond chain- en component-kwetsbaarheden. Bijvoorbeeld: CI-workflows gehackt via GitHub issues: fix dit gaat over hoe aanvallers misbruik maken van onverwachte routes en validatiepaden binnen softwareketens.

Conclusie

PortSwigger toont met HTTP Terminator aan dat HTTP desync niet alleen met handmatige research te onderzoeken is, maar ook via AI-gestuurde kandidaatgeneratie en validatie. De resultaten omvatten nieuwe desync-triggers, een dual-matching Content-Length patroon en een dangling-byte techniek die RQP betrouwbaarder maakt.

Daarnaast kwam via een mens-geleide route een Apache Traffic Server zero-day naar boven (CVE-2026-63078), die volgens de onderzoekers inmiddels is gepatcht. Voor verdedigers is de belangrijkste les: verminder parsing-ambiguïteit, voorkom HTTP/1.1 upstream waar mogelijk en maak allow-listing en restricties op request bodies concreet in je configuraties.

Bron: https://thehackernews.com/2026/08/ai-assisted-http-terminator-finds-novel.html