The vulnerable HttpClient releases an underlying network connection only when the response body is successfully decoded. If the server sends a response with an unknown or malformed Content‑Encoding header, the client fails to release that connection back to the manager. This resource leak can accumulate, eventually exhausting the pool of available connections and causing the client application to become unresponsive to new requests. The weakness is a classic resource‑management error (CWE‑772) and has no direct impact on data confidentiality or integrity, but it does degrade availability.

Apache Software Foundation’s HttpComponents Client library, versions 5.0‑alpha1 through 5.6.2, when the classic blocking I/O mode is used. The documented defect is absent from the asynchronous I/O implementation of the library. Applications that embed these specific library versions and depend on the blocking client are therefore vulnerable.

The CVSS score of 5.3 classifies this as a moderate impact vulnerability. The EPSS score of less than 1% indicates a very low likelihood of exploitation in the wild. It is not listed in CISA’s KEV catalog, suggesting no known active exploitation campaigns. An attacker who controls or can influence an upstream HTTP server could send a malicious response containing an unsupported Content‑Encoding header to a client application that uses the vulnerable HttpClient library. Such an attacker would enable remote denial of service by exhausting the client's connection pool. Because the flaw exists only in the blocking I/O variant, applications that use the async version are naturally protected.