CVE-2026-90678

HAProxy 3.3.0 ile 3.4.4 arası sürümlerde ve 3.5-dev1 ile 3.5-dev5 arası sürümlerde bir sorun keşfedilmiştir. İstismar için bir HTTP/3 frontend gereklidir: HAProxy, QUIC desteğiyle derlenmiş ve bir QUIC bind dinleyicisi ile yapılandırılmış olmalı ve etkilenen trafik, yeniden kullanılan bir bağlantı üzerinden chunked transfer coding kullanarak HTTP/1.1 aracılığıyla bir backend'e ulaşmalıdır. Bu koşullar altında, bir HTTP/3 isteği Content-Length başlığı taşımadığında, HTTP/3 multiplexer, veri çerçevesi (DATA frame) başlığında beyan edilen uzunluğu, yük henüz alınmadan önce, çerçeve başlığı çözüldüğü anda akış uç noktasının bilinen giriş yükü tahminine ekler ve bu beyan edilen uzunluk olduğu gibi HTTP/1.1 chunk boyutu olarak yayınlanır. Teslim ettiğinden daha fazla yük beyan eden ve ardından akışı sonlandıran uzaktan kimliği doğrulanmamış bir istemci, HAProxy'nin yazdığı baytlardan daha büyük bir chunk duyurmasına ve bağlantıyı senkronize edilmemiş bir durumda boşta havuzuna geri döndürmesine neden olur. Bunun sonucu, yeniden kullanılan backend bağlantıları üzerinde potansiyel HTTP request smuggling riskidir: bir saldırgan, yol tabanlı bir http-request deny gibi bir frontend kuralını aşarak bir istek yerleştirebilir, böylece kaçırılan (smuggled) istek HAProxy'nin HTTP analizinde asla görülmez ve eşzamanlı istemcilerin istek satırları ve Authorization başlıkları dahil olmak üzere isteklerinin, saldırganın istek gövdesi olarak tüketilmesine ve kaybolmasına neden olabilir. İstismar deterministik değildir; backend bağlantı havuzuyla olan bir yarış durumuna (race condition) bağlıdır, testler sırasında denemelerin çoğunda ancak tamamında değil başarılı olmuştur ve serbestçe yeniden denenebilir. Mekanizma 3.3-dev10 sürümünde getirilmiştir; 3.2.x ve önceki sürümler etkilenmemiştir.