CVE-2026-90678 in HAProxy
Zusammenfassung
von VulDB • 13.09.2026
Es wurde ein Problem in HAProxy ab Version 3.3.0 bis 3.4.4 sowie in den Entwicklungsversionen 3.5-dev1 bis 3.5-dev5 entdeckt. Die Ausnutzung (Exploitation) erfordert eine HTTP/3-Frontend-Konfiguration: HAProxy muss mit QUIC-Unterstützung kompiliert und so konfiguriert sein, dass ein QUIC-Bind-Listener verwendet wird, und der betroffene Traffic muss über HTTP/1.1 unter Verwendung von chunked Transfer Coding auf einer wiederverwendeten Verbindung an einen Backend-Server geleitet werden. Unter diesen Bedingungen, wenn eine HTTP/3-Anfrage keinen Content-Length-Header enthält, gutschreibt das HTTP/3-Multiplexer die in einem DATA-Frame-Header deklarierte Länge der bekannten Eingabe-Payload-Schätzung des Stream-Endpunkts im Moment der Dekodierung des Frame-Headers, bevor die Payload empfangen wurde, und diese deklarierte Länge wird unverändert als HTTP/1.1-Chunk-Größe ausgegeben. Ein entfernter, nicht authentifizierter Client, der mehr Payload deklariert, als er tatsächlich liefert, und dann den Stream beendet, veranlasst HAProxy dazu, einen Chunk anzukündigen, der größer ist als die von ihm geschriebenen Bytes, und gibt die Verbindung in einem desynchronisierten Zustand an den Idle-Pool zurück. Die Folge ist potenzielles HTTP-Request-Smuggling auf wiederverwendeten Backend-Verbindungen: Ein Angreifer kann eine Anfrage hinter einer Frontend-Regel wie einer pfadbasierten http-request deny-Anweisung platzieren, sodass die geschmuggelte Anfrage von der HTTP-Analyse von HAProxy nie gesehen wird, und er kann dazu führen, dass Anfragen gleichzeitiger Clients, einschließlich ihrer Request-Lines und Authorization-Headers, als Körper des Angreifer-Requests verbraucht und verloren gehen. Die Ausnutzung ist nicht deterministisch; sie hängt vom Race mit dem Backend-Verbindungspooling ab, gelingt in den meisten, aber nicht allen Testversuchen, und kann beliebig wiederholt werden. Der Mechanismus wurde in 3.3-dev10 eingeführt; die Versionen 3.2.x und älter sind nicht betroffen.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.