CVE-2026-90678 in HAProxy
Resumen
por VulDB • 2026-09-13
Se ha descubierto un problema en HAProxy desde la versión 3.3.0 hasta la 3.4.4, y en las versiones de desarrollo 3.5-dev1 a 3.5-dev5. La explotación requiere un frontend HTTP/3: HAProxy debe estar compilado con soporte QUIC y configurado con un oyente (listener) bind para QUIC, y el tráfico afectado debe llegar al backend mediante HTTP/1.1 utilizando codificación de transferencia por fragmentos (chunked transfer coding) en una conexión reutilizada. Bajo estas condiciones, cuando una solicitud HTTP/3 no incluye la cabecera Content-Length, el multiplexor HTTP/3 acredita a la estimación conocida del payload de entrada del extremo del stream la longitud declarada en la cabecera del frame DATA en el momento en que dicha cabecera se decodifica, antes de que el payload haya sido recibido, y esa longitud declarada se emite literalmente como el tamaño del fragmento (chunk) HTTP/1.1. Un cliente remoto no autenticado que declare un mayor volumen de payload del que entrega y luego finalice el stream provoca que HAProxy anuncie un chunk más grande que los bytes que escribe y devuelva la conexión al pool inactivo en un estado desincronizado. El resultado es una posible HTTP request smuggling (infiltración de solicitudes HTTP) en las conexiones reutilizadas con el backend: un atacante puede colocar una solicitud detrás de una regla del frontend, como una denegación http-request basada en ruta, para que la solicitud infiltrada nunca sea vista por el análisis HTTP de HAProxy, y puede hacer que se consuman como cuerpo de la solicitud del atacante las solicitudes de clientes concurrentes, incluyendo sus líneas de solicitud y cabeceras Authorization, perdiéndose estas últimas. La explotación no es determinista; depende de una condición de carrera (race condition) con el pool de conexiones del backend, teniendo éxito en la mayoría pero no en todas las pruebas durante los ensayos, y puede reintentarse libremente. El mecanismo fue introducido en 3.3-dev10; las versiones 3.2.x y anteriores no se ven afectadas.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.