CVE-2026-85718: AsyncHttpClient: Connection permit leak on TLS handshake failure causes per-host denial of service
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
AsyncHttpClientto a version that resolves this vulnerability.Fixed in 3.0.12
Event History
Frequently Asked Questions
Which deployments are affected?
AsyncHttpClient versions from 3.0.8 until 3.0.12 are affected when maxConnections or maxConnectionsPerHost is configured above zero. The default unlimited connection setting is not affected.
What does an attacker or triggering condition need to cause the denial of service?
TLS connection establishment must repeatedly fail before the handshake completes. Each such failure can leak a connection permit, eventually locking out a host under a per-host limit or exhausting the shared pool under a global limit.
What is the impact after permits are exhausted?
Later requests can be blocked even though no connections remain open. With a per-host limit, the lockout can be limited to one host; with a global limit, the shared connection pool can be drained.
How can the issue be remediated or mitigated?
Upgrade to AsyncHttpClient 3.0.12. If upgrading is not immediately possible, avoiding configured positive maxConnections and maxConnectionsPerHost limits avoids the affected permit-leak condition, though this changes connection-limit behavior.