CVE-2026-85718 in Async Http Client
Summary
by MITRE • 09/17/2026
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 3.0.8 until 3.0.12, a client with maxConnections or maxConnectionsPerHost set above zero leaks one connection permit whenever TLS connection establishment fails before the handshake completes. NettyConnectListener removes the partitionKeyLock permit from NettyResponseFuture before every failure path is bound to the channel closeFuture, so an abort can leave the permit unreleased. Repeated failures can permanently lock out one host under a per-host limit or drain the shared pool under a global limit, blocking later requests even when no connection remains open. The default unlimited connection setting is not affected. This issue is fixed in version 3.0.12.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The AsyncHttpClient library serves as a critical component for Java-based applications requiring efficient execution of HTTP requests and asynchronous processing of responses. Within the specific versions ranging from 3.0.8 to 3.0.12, a significant resource management flaw exists that impacts system stability under conditions of network instability or TLS negotiation failures. This vulnerability is classified as CWE-400, which denotes uncontrolled resource consumption, specifically manifesting here through connection pool exhaustion rather than simple memory leaks. The core technical issue arises from the interaction between the NettyConnectListener and the underlying connection pooling mechanism when establishing Transport Layer Security connections.
When a client attempts to establish a TLS connection with maxConnections or maxConnectionsPerHost set above zero, it acquires a permit from the respective pool to reserve capacity for that specific host or globally shared resource. The vulnerability occurs during the handshake phase if the connection establishment fails before completion. In these failure scenarios, the NettyConnectListener incorrectly removes the partitionKeyLock permit from the NettyResponseFuture object prematurely. This removal happens before the channel close future is properly bound and managed to ensure cleanup on all error paths. Consequently, if an abort or early termination occurs during this window, the connection permit remains unreleased within the pool's accounting logic.
The operational impact of this flaw is severe for applications relying on strict connection limits. Because permits are not returned to the pool upon failed TLS handshakes, repeated failures can lead to a permanent lockout of one host if per-host limits are in place. Alternatively, under global limit configurations, the continuous draining of available connections will eventually exhaust the entire shared pool. This state effectively blocks subsequent legitimate requests from being processed, even when no actual network connections remain open or active on the wire. The application may appear to hang or become unresponsive as it waits indefinitely for a connection that is technically allocated but functionally unusable due to the internal accounting error.
This issue does not affect configurations where default unlimited connection settings are utilized, as there is no finite pool of permits to exhaust in those scenarios. However, most production environments enforce limits to prevent resource exhaustion and ensure fair usage across multiple hosts or services. The vulnerability aligns with MITRE ATT&CK technique T1496, Resource Hijacking, specifically regarding the denial of service through resource consumption by an attacker who can induce repeated TLS failures against a target endpoint. Such attacks could be executed via malicious servers that drop connections during handshake to systematically degrade the availability of the client application.
Mitigation for this vulnerability requires upgrading the AsyncHttpClient library to version 3.0.12 or later, where the connection permit release logic has been corrected to ensure permits are returned in all failure paths. For organizations unable to upgrade immediately, implementing circuit breakers and retry policies with exponential backoff can help mitigate the rate of failed connections that trigger this bug. Additionally, monitoring connection pool utilization metrics and setting up alerts for high rates of TLS handshake failures can provide early detection of potential exploitation attempts or network issues leading to resource exhaustion. Ensuring robust error handling in application code that interacts with HTTP clients is also advisable to gracefully handle transient network errors without triggering cascading failures due to depleted connection pools.