CVE-2026-107230 in async-http-client
Summary
by MITRE • 10/08/2026
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. From 2.0.0 until 3.0.14, connection-pool partitioning still omits identity-defining fields for Kerberos, SPNEGO, NTLM, and authenticated proxy connections. Logins without a configured principal, proxy realms, identities sharing a user name, and SOCKS or CONNECT proxy logins can reuse a socket authenticated as a different identity. A later request is then executed under the first identity and can expose that identity's data or authority to another caller. In the affected execution path, SpnegoEngine, NTLM, Kerberos, SPNEGO, SOCKS, and CONNECT control or expose the vulnerable behavior. This issue is fixed in version 3.0.14.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/08/2026
The AsyncHttpClient library serves as a critical component for Java-based applications requiring efficient execution of HTTP requests and asynchronous processing of responses. However, within versions ranging from 2.0.0 through 3.0.14, the implementation of connection-pool partitioning contains a significant logical flaw that compromises identity isolation. The core technical deficiency lies in the failure to include specific identity-defining fields when determining how connections are segregated within the pool. This oversight affects authentication mechanisms such as Kerberos, SPNEGO, and NTLM, as well as scenarios involving authenticated proxies or SOCKS and CONNECT proxy logins. Consequently, the connection manager does not adequately distinguish between sockets based on their security context, leading to a breakdown in access control boundaries.
This architectural flaw results in a severe identity confusion vulnerability where distinct users or services may inadvertently share underlying network connections. Specifically, if login configurations lack a defined principal, involve overlapping proxy realms, utilize identical usernames across different identities, or employ SOCKS and CONNECT proxies without proper isolation, the pool may assign an existing socket to a new request that was authenticated under a completely different identity. This means that a subsequent HTTP request initiated by one user can be routed through a connection previously established and authenticated for another user. The vulnerability is actively triggered in execution paths involving SpnegoEngine, NTLM, Kerberos, SPNEGO, SOCKS, and CONNECT controls, which fail to enforce strict separation of credentials during socket reuse.
The operational impact of this flaw is substantial, as it allows an attacker or a malicious actor within the same application environment to exploit shared connections to access sensitive data belonging to other identities. By reusing a socket authenticated under a privileged account, an unauthorized caller can execute requests that are processed with the authority and permissions of that higher-privilege identity. This effectively bypasses authentication checks for subsequent operations, leading to potential information disclosure where confidential data is exposed, or privilege escalation where actions are performed without proper authorization. The vulnerability aligns closely with CWE-280, which addresses improper handling of insufficiently validated inputs in access control decisions, and maps to the ATT&CK technique T1556, specifically regarding credential hijacking through session manipulation or side-channel attacks on authentication mechanisms.
To mitigate this risk, organizations must upgrade the AsyncHttpClient library to version 3.0.14 or later, where the connection-pool partitioning logic has been corrected to properly account for all identity-defining fields. In environments where immediate upgrading is not feasible, it is imperative to review application configurations to ensure that Kerberos principals are explicitly defined and unique, proxy realms are strictly segregated per user context, and usernames do not overlap across different security identities when using authenticated proxies or SOCKS connections. Additionally, implementing strict connection validation checks before reusing pooled sockets can provide a temporary layer of defense against identity confusion attacks until the underlying library defect is resolved through patching.