Die Ursache liegt in der Header-Komprimierung von HTTP/3. Dafür nutzt das Protokoll QPACK, das wiederkehrende Header in einer gemeinsamen Tabelle speichert. Der Client steuert über einen eigenen Kontrollkanal, den Encoder-Stream, wie diese Tabelle aufgebaut und vergrößert wird.
XQUIC speichert die Bytes dieser Tabelle in einem Ringpuffer, also einem festen Speicherbereich, in dem Daten nach Erreichen des Endes wieder am Anfang fortgesetzt werden. Wenn der Client eine Vergrößerung der Tabelle anfordert, reserviert XQUIC einen größeren Puffer und kopiert die bisherigen Daten dorthin. Genau in dieser Kopierlogik steckt der Fehler.
Laut FoxIO gibt es vier Fälle dafür, wie die Daten im alten und im neuen Puffer umbrochen sein können. In einem dieser Fälle berechnet der Code die verbleibenden Daten am Ende des Puffers jedoch anhand der Kapazität des neuen, größeren Puffers statt der des alten. Dadurch wird die Restmenge massiv überschätzt. Wächst eine 64-Byte-Tabelle bei einem Schreibzeiger nahe dem Ende auf 65 Byte, geht XQUIC demnach von 70 zu kopierenden End-Bytes aus, obwohl tatsächlich nur 6 Byte vorhanden sind.
Diese fehlerhafte Zahl läuft anschließend in eine Speicheroperation. Die Kopierlänge entsteht, indem dieser zu große Wert von einem kleineren Wert abgezogen wird. Weil die Länge als vorzeichenloses size_t behandelt wird, kommt es zu einem Unterlauf: Der Wert springt auf eine nahezu maximale Größe, und der Kopiervorgang läuft über das reservierte Speicherende hinaus.
In einer von FoxIO getesteten Release-Build auf Ubuntu 26.04 fing glibc mit _FORTIFY_SOURCE=2 die falsche Länge ab und beendete den Prozess. Ohne diese Prüfung schreibt die Operation laut Quelltext außerhalb der Grenzen des Zielpuffers, vom alten Puffer bis hinter das Ende des neuen. Féry zeigte einen Absturz, testete aber nicht, ob sich die Speicherbeschädigung darüber hinaus weiter ausnutzen lässt.
Bemerkenswert ist dabei, dass der Angriff keine ungültigen QPACK-Werte benötigt. XQUIC bewirbt standardmäßig ein Limit von 16 KiB für die dynamische Tabelle; die Angriffslast fordert lediglich 64 Byte und anschließend 65 Byte an. Der Client muss die Tabelle nur in genau die umbrochene Anordnung bringen, die den fehlerhaften Codepfad trifft. Nach Angaben von FoxIO steckt der Fehler seit der ersten öffentlichen XQUIC-Version vom Januar 2022 im Projekt, ein Proof of Concept ist öffentlich verfügbar.
Betroffen sind laut Quelltext sämtliche Versionen bis einschließlich 1.9.4. Einen korrigierten Release-Stand gibt es nicht, ebenso keine CVE mit Stand vom 10. Juli. Bis ein Fix erscheint, sollen Betreiber entweder SETTINGS_QPACK_MAX_TABLE_CAPACITY auf 0 setzen und damit die dynamische QPACK-Tabelle abschalten oder HTTP/3 komplett deaktivieren.
FoxIO meldete die Lücke nach eigenen Angaben am 7. April gemäß der Sicherheitsrichtlinie des Projekts, die eine Antwort binnen drei Arbeitstagen zusichert. Dem Bericht zufolge folgten bis zum 9. Mai vier weitere Kontaktversuche ohne Antwort, bevor die Forscher die Schwachstelle öffentlich machten. FoxIO demonstrierte einen Absturz, meldete aber keine Ausnutzung in freier Wildbahn.