CVE-2026-90678 in HAProxy
요약
\~에 의해 VulDB • 2026. 09. 13.
HAProxy 3.3.0부터 3.4.4 및 3.5-dev1에서 3.5-dev5까지의 버전에서 문제가 발견되었습니다. 공격을 위해서는 HTTP/3 프론트엔드가 필요합니다: HAProxy는 QUIC 지원으로 빌드되어 있고, QUIC 바인딩 리스너로 구성되어 있으며, 영향받는 트래픽이 재사용된 연결에서 청크 전송 인코딩(chunked transfer coding)을 사용하여 HTTP/1.1 백엔드로 도달해야 합니다. 이러한 조건 하에서 HTTP/3 요청에 Content-Length 헤더가 없으면, HTTP/3 멀티플렉서는 프레임 헤더가 디코드되는 순간 페로드가 수신되기 전에 DATA 프레임 헤더에 선언된 길이를 스트림 엔드포인트의 알려진 입력 페로드 추정치로 크레딧하고, 그 선언된 길이는 그대로 HTTP/1.1 청크 크기로 방출됩니다. 자신이 전달하는 것보다 더 많은 페로드를 선언한 후 스트림을 종료하는 원격 비인증 클라이언트는 HAProxy가 자신들이 작성하는 바이트 수보다 큰 청크를 announce하게 하고 연결을 동기화되지 않은 상태로 대기 풀(idle pool)로 반환하도록 합니다. 그 결과 재사용된 백엔드 연결에서 HTTP 요청 스미싱이 발생할 수 있습니다: 공격자는 경로 기반 http-request deny와 같은 프론트엔드 규칙 뒤에 요청을 배치하여, 스미싱된 요청이 HAProxy의 HTTP 분석에 의해 결코 감지되지 않도록 할 수 있으며, 동시 클라이언트의 요청(요청 라인 및 Authorization 헤더 포함)이 공격자의 요청 본문으로 소비되어 손실되도록 할 수 있습니다. 공격은 결정론적이지 않으며 백엔드 연결 풀링과의 레이스 조건(race condition)에 의존하며, 테스트 중 대부분의 시나리오에서 성공하지만 모든 시도에서 성공하는 것은 아니며 자유롭게 재시도할 수 있습니다. 이 메커니즘은 3.3-dev10에서 도입되었으며, 3.2.x 및 이전 버전의 릴리스는 영향을 받지 않습니다.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.