CVE-2026-107282 in AsyncHttpClient
Summary
by MITRE • 10/08/2026
The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. Prior to 3.0.13 and 2.16.1, cross-host request replay updates the current request but leaves the target request and related proxy context pointing at the original origin. Connection-pool selection, CONNECT handling, realm selection, and TLS setup can consequently send the original host's path, Host header, Authorization credentials, or plaintext request to the replay destination. Documented ResponseFilter failover and retry paths can trigger the replay. This issue is fixed in versions 3.0.13 and 2.16.1.
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. A significant security vulnerability was identified within the request replay mechanism prior to version 3.0.13 and 2.16.1, specifically affecting how cross-host request replays are handled. The core technical flaw lies in the state management during a replay operation initiated by documented ResponseFilter failover or retry paths. When such an event occurs, the library updates the current request object to reflect the new target but fails to properly reset the underlying proxy context and target request pointers. This inconsistency leaves these internal structures pointing at the original origin rather than the intended destination for the replayed traffic.
This architectural flaw leads to a severe information disclosure vulnerability where sensitive data associated with the original host is inadvertently transmitted to an unrelated, potentially malicious or unintended third-party server. Specifically, because the proxy context and target request remain bound to the initial origin, subsequent operations such as connection-pool selection, CONNECT tunnel handling, realm authentication selection, and TLS handshake setup utilize credentials and headers intended for the first host. Consequently, plaintext requests, authorization credentials including Basic Auth tokens or OAuth bearer tokens, and specific path information from the original domain are sent to the replay destination. This represents a classic case of improper state management leading to unauthorized data exposure, aligning with CWE-209 which describes the generation of error messages containing sensitive information that could be utilized by an attacker to gain further access.
From an operational perspective, this vulnerability poses a substantial risk to application security and compliance. Attackers who can manipulate or trigger response filter failovers may exploit this misconfiguration to exfiltrate authentication credentials across domain boundaries. This scenario is particularly dangerous in microservices architectures or applications interacting with multiple external APIs where trust boundaries are strictly defined by hostnames. The leakage of plaintext request data and authorization headers violates the principle of least privilege and confidentiality, potentially leading to account takeover if valid session tokens or API keys are compromised. In environments adhering to strict regulatory frameworks such as PCI-DSS or GDPR, this type of cross-origin credential leakage constitutes a critical failure in protecting personally identifiable information and financial data during transit.
The behavior observed also maps directly to MITRE ATT&CK techniques related to Credential Access via Network Service Discovery or Exfiltration Over Alternative Protocol depending on the specific network context. The vulnerability essentially allows an attacker to pivot trust from one service identity to another without proper re-authentication, bypassing intended security controls that rely on host-based validation. This undermines the integrity of HTTP communication channels and exposes the application to sophisticated phishing-like attacks where sensitive internal or external credentials are harvested by a third party under the guise of normal asynchronous request processing.
To mitigate this risk, organizations must immediately upgrade the AsyncHttpClient library to version 3.0.13 or later for Java 8+ environments, or version 2.16.1 and above for legacy systems supporting older Java versions. These updated releases correct the internal state management logic ensuring that proxy contexts and target requests are fully reset during cross-host replays. In addition to upgrading dependencies, developers should implement strict validation of retry targets within custom ResponseFilters to ensure that replayed requests do not inadvertently traverse untrusted network paths. It is also advisable to review existing asynchronous HTTP client configurations for any reliance on automatic failover mechanisms involving external hosts and consider implementing explicit allow-lists for permitted redirect or replay destinations to further reduce the attack surface associated with this class of state management errors.