Httpcomponents Core
Monthly
Denial of service in Apache HttpComponents Core (HttpCore) 5.0-alpha through 5.4.2 and the 5.5 beta line up to 5.5-beta1 allows a remote unauthenticated attacker to exhaust server memory by sending HTTP/1.1 messages containing an excessive number of headers or excessively long headers. The HTTP/1.1 message parser accumulates this header data without enforcing sane bounds, letting a single crafted request drive availability loss (CVSS 7.5, A:H only). There is no public exploit identified at time of analysis, and CISA's SSVC assessment rates exploitation as 'none' with only partial technical impact.
Memory exhaustion denial-of-service in Apache HttpComponents Core's HTTP/2 HPACK decoder allows remote attackers to crash Java services by sending oversized compressed header blocks before the HTTP/2 SETTINGS acknowledgement is processed. The root cause is a timing gap in the connection handshake: the server's configured maximum header list size limit is not enforced until after the SETTINGS ACK exchange completes, leaving a window during which an attacker can flood the decoder with arbitrarily large compressed header data. Affected artifacts are org.apache.httpcomponents.core5:httpcore5-h2 versions 5.4.2 and earlier and 5.5-beta1 and earlier. No public exploit or CISA KEV listing has been identified at time of analysis.
Denial of service in Apache HttpComponents Core (HttpCore) 5.0-alpha through 5.4.2 and the 5.5 beta line up to 5.5-beta1 allows a remote unauthenticated attacker to exhaust server memory by sending HTTP/1.1 messages containing an excessive number of headers or excessively long headers. The HTTP/1.1 message parser accumulates this header data without enforcing sane bounds, letting a single crafted request drive availability loss (CVSS 7.5, A:H only). There is no public exploit identified at time of analysis, and CISA's SSVC assessment rates exploitation as 'none' with only partial technical impact.
Memory exhaustion denial-of-service in Apache HttpComponents Core's HTTP/2 HPACK decoder allows remote attackers to crash Java services by sending oversized compressed header blocks before the HTTP/2 SETTINGS acknowledgement is processed. The root cause is a timing gap in the connection handshake: the server's configured maximum header list size limit is not enforced until after the SETTINGS ACK exchange completes, leaving a window during which an attacker can flood the decoder with arbitrarily large compressed header data. Affected artifacts are org.apache.httpcomponents.core5:httpcore5-h2 versions 5.4.2 and earlier and 5.5-beta1 and earlier. No public exploit or CISA KEV listing has been identified at time of analysis.