Search Results (Refine Search)
- Results Type: Overview
- Keyword (text search): cpe:2.3:a:haproxy:haproxy:1.1.6:*:*:*:*:*:*:*
- CPE Name Search: true
Vuln ID | Summary | CVSS Severity |
---|---|---|
CVE-2023-45539 |
HAProxy before 2.8.2 accepts # as part of the URI component, which might allow remote attackers to obtain sensitive information or have unspecified other impact upon misinterpretation of a path_end rule, such as routing index.html#.png to a static server. Published: November 28, 2023; 3:15:07 PM -0500 |
V4.0:(not available) V3.1: 8.2 HIGH V2.0:(not available) |
CVE-2023-40225 |
HAProxy through 2.0.32, 2.1.x and 2.2.x through 2.2.30, 2.3.x and 2.4.x through 2.4.23, 2.5.x and 2.6.x before 2.6.15, 2.7.x before 2.7.10, and 2.8.x before 2.8.2 forwards empty Content-Length headers, violating RFC 9110 section 8.6. In uncommon cases, an HTTP/1 server behind HAProxy may interpret the payload as an extra request. Published: August 10, 2023; 5:15:10 PM -0400 |
V4.0:(not available) V3.1: 7.2 HIGH V2.0:(not available) |
CVE-2023-25725 |
HAProxy before 2.7.3 may allow a bypass of access control because HTTP/1 headers are inadvertently lost in some situations, aka "request smuggling." The HTTP header parsers in HAProxy may accept empty header field names, which could be used to truncate the list of HTTP headers and thus make some headers disappear after being parsed and processed for HTTP/1.0 and HTTP/1.1. For HTTP/2 and HTTP/3, the impact is limited because the headers disappear before being parsed and processed, as if they had not been sent by the client. The fixed versions are 2.7.3, 2.6.9, 2.5.12, 2.4.22, 2.2.29, and 2.0.31. Published: February 14, 2023; 2:15:11 PM -0500 |
V4.0:(not available) V3.1: 9.1 CRITICAL V2.0:(not available) |
CVE-2019-19330 |
The HTTP/2 implementation in HAProxy before 2.0.10 mishandles headers, as demonstrated by carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the zero character (NUL, ASCII 0x0), aka Intermediary Encapsulation Attacks. Published: November 27, 2019; 11:15:11 AM -0500 |
V4.0:(not available) V3.1: 9.8 CRITICAL V2.0: 7.5 HIGH |
CVE-2019-18277 |
A flaw was found in HAProxy before 2.0.6. In legacy mode, messages featuring a transfer-encoding header missing the "chunked" value were not being correctly rejected. The impact was limited but if combined with the "http-reuse always" setting, it could be used to help construct an HTTP request smuggling attack against a vulnerable component employing a lenient parser that would ignore the content-length header as soon as it saw a transfer-encoding one (even if not entirely valid according to the specification). Published: October 23, 2019; 10:15:10 AM -0400 |
V4.0:(not available) V3.1: 7.5 HIGH V2.0: 4.3 MEDIUM |
CVE-2018-20103 |
An issue was discovered in dns.c in HAProxy through 1.8.14. In the case of a compressed pointer, a crafted packet can trigger infinite recursion by making the pointer point to itself, or create a long chain of valid pointers resulting in stack exhaustion. Published: December 12, 2018; 12:29:00 PM -0500 |
V4.0:(not available) V3.0: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2018-20102 |
An out-of-bounds read in dns_validate_dns_response in dns.c was discovered in HAProxy through 1.8.14. Due to a missing check when validating DNS responses, remote attackers might be able read the 16 bytes corresponding to an AAAA record from the non-initialized part of the buffer, possibly accessing anything that was left on the stack, or even past the end of the 8193-byte buffer, depending on the value of accepted_payload_size. Published: December 12, 2018; 12:29:00 PM -0500 |
V4.0:(not available) V3.0: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2018-14645 |
A flaw was discovered in the HPACK decoder of HAProxy, before 1.8.14, that is used for HTTP/2. An out-of-bounds read access in hpack_valid_idx() resulted in a remote crash and denial of service. Published: September 21, 2018; 9:29:00 AM -0400 |
V4.0:(not available) V3.0: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2018-10184 |
An issue was discovered in HAProxy before 1.8.8. The incoming H2 frame length was checked against the max_frame_size setting instead of being checked against the bufsize. The max_frame_size only applies to outgoing traffic and not to incoming, so if a large enough frame size is advertised in the SETTINGS frame, a wrapped frame will be defragmented into a temporary allocated buffer where the second fragment may overflow the heap by up to 16 kB. It is very unlikely that this can be exploited for code execution given that buffers are very short lived and their addresses not realistically predictable in production, but the likelihood of an immediate crash is absolutely certain. Published: May 09, 2018; 3:29:00 AM -0400 |
V4.0:(not available) V3.0: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2012-2942 |
Buffer overflow in the trash buffer in the header capture functionality in HAProxy before 1.4.21, when global.tune.bufsize is set to a value greater than the default and header rewriting is enabled, allows remote attackers to cause a denial of service and possibly execute arbitrary code via unspecified vectors. Published: May 27, 2012; 4:55:05 PM -0400 |
V4.0:(not available) V3.x:(not available) V2.0: 5.1 MEDIUM |