Eén enkele verkeerde variabele op één regel in XQUIC, de QUIC- en HTTP/3-bibliotheek van Alibaba, zorgt ervoor dat elke externe client de server laat crashen met een korte uitbarsting van volledig legaal verkeer. Er is geen pleister.
FoxIO-onderzoeker Sébastien Féry maakte de fout op 8 juli bekend en noemde het XRING. Hij zegt dat er geen login en geen verkeerd opgemaakte pakketten nodig zijn: ongeveer 260 bytes aan gewoon QPACK-verkeer halen het serverproces plat.
XQUIC is open source, dus het risico ligt niet alleen bij Alibaba: elke server die het insluit en HTTP/3 bedient met de standaard QPACK-instellingen is blootgesteld. Dat geldt ook voor Tengine, de op Nginx gebaseerde webserver van Alibaba, die volgens FoxIO de cloud en CDN van het bedrijf beheert op sites als Taobao en Alipay.
Elke release tot en met v1.9.4, de nieuwste, wordt beïnvloed. Er is geen vaste release en geen CVE vanaf 10 juli. Totdat er een oplossing wordt uitgebracht, kunnen operators SETTINGS_QPACK_MAX_TABLE_CAPACITY op 0 zetten, waardoor de dynamische tabel van QPACK wordt uitgeschakeld, of de HTTP/3-ondersteuning volledig wordt stopgezet.
De bug zit in de manier waarop HTTP/3 headers comprimeert. Om te voorkomen dat dezelfde header (bijvoorbeeld user-agent) keer op keer wordt verzonden, gebruikt HTTP/3 QPACK. Het houdt een gedeelde tabel bij die de client de server laat opbouwen en vergroten of verkleinen via een speciaal besturingskanaal, de encoderstream.
XQUIC slaat de bytes van die tabel op in een ringbuffer, een vast geheugenblok waar gegevens van het einde terug naar het begin lopen zodra deze vol zijn.
Wanneer de klant vraagt om de tabel te laten groeien, wijst XQUIC een grotere buffer toe en kopieert de oude gegevens ernaartoe. Die kopie heeft vier gevallen, afhankelijk van of de gegevens zich in de oude buffer, de nieuwe, beide of geen van beide bevinden. In een daarvan vergelijkt de code de overgebleven staartgegevens met de capaciteit van de nieuwe, grotere buffer in plaats van die van de oude. Het telt slecht.
Laat een tabel van 64 bytes groeien met de schrijfcursor aan het einde, en wijzig het formaat naar 65, en XQUIC besluit dat er 70 staartbytes moeten worden verplaatst terwijl er in werkelijkheid zes zijn.
Dat verkeerde nummer stroomt in een geheugenkopie. De kopielengte wordt bepaald door het overaantal af te trekken van een kleinere waarde. Omdat die lengte een niet-ondertekende size_t is, loopt deze onder en loopt terug naar een bijna maximaal aantal, en de kopie loopt over het einde van het geheugen.
In FoxIO’s release, gebouwd op Ubuntu 26.04, ving glibc’s _FORTIFY_SOURCE=2 de slechte lengte op en beëindigde het proces. Zonder die controle schrijft de kopie buiten het bereik, vanuit de oude buffer tot voorbij het einde van de nieuwe. Féry liet een crash zien, maar testte niet of die corruptie verder kon worden uitgebuit.
Geen van de waarden in de aanval overtreedt de regels van QPACK. XQUIC adverteert standaard met een dynamische tabellimiet van 16 KiB; de payload vraagt om 64 bytes en vervolgens om 65. De client hoeft de tabel alleen maar in de exact verpakte lay-out te sturen die de defecte branch raakt. FoxIO zegt dat de fout in XQUIC zit sinds de eerste publieke release in januari 2022, en dat er een proof of concept openbaar is.
XRING is de laatste in een reeks crashes op afstand in HTTP/2- en HTTP/3-stacks. Drie weken eerder meldde THN een use-after-free in de HTTP/3-module van NGINX (CVE-2026-42530) die een externe, niet-geverifieerde client zou kunnen bereiken via dezelfde QPACK-encoder stream XRING-misbruik, een andere bugklasse op hetzelfde aanvalsoppervlak.
In juni veroorzaakte de HTTP/2-bom in Californië een Denial of Service op afstand tegen Nginx, Apache, IIS en Envoy door misbruik te maken van HPACK, de headercompressie van HTTP/2 en de voorloper van QPACK.
In februari repareerde HAProxy twee QUIC-crashes, waarvan één een integer-underflow tijdens tokenvalidatie, hetzelfde type bug achter XRING, hoewel het een verkeerd ingedeeld pakket nodig had terwijl XRING er geen nodig had. Dat verschil is het punt: juridische invoer, één rekenfoutje, een dode server.
FoxIO demonstreerde een crash, geen code-uitvoering, en rapporteerde geen exploitatie in het wild. Het zegt dat het Alibaba op 7 april een e-mail heeft gestuurd via het beveiligingsbeleid van het project, dat binnen drie werkdagen een antwoord belooft, en vervolgens tot en met 9 mei nog vier keer een e-mail heeft gestuurd zonder antwoord voordat het openbaar werd gemaakt.
The Hacker News heeft Alibaba gevraagd of er een oplossing en een CVE komen, en of de vijf openbaarmakingspogingen van FoxIO het beveiligingsteam hebben bereikt. Het heeft FoxIO gevraagd of de fout in het wild is uitgebuit en of de onderliggende heap-write voorbij een crash kan worden geduwd. Het verhaal wordt bij elke reactie bijgewerkt.
