Apr 14, 2026·5 min read·3 visits
AsyncHttpClient versions before 3.0.9 leak authentication credentials and Realm data when following cross-origin HTTP 3xx redirects, allowing attackers to capture sensitive tokens.
AsyncHttpClient prior to version 3.0.9 is vulnerable to cross-domain credential leakage during HTTP redirects. The library incorrectly forwards Authorization headers and internal Realm objects to untrusted origins, potentially exposing sensitive tokens to unauthorized network actors.
AsyncHttpClient is a Java library that facilitates asynchronous HTTP request execution and response handling. Applications frequently use this library to interact with external APIs, often passing sensitive authentication tokens such as Bearer tokens or Basic authentication credentials.
In versions prior to 3.0.9, the library exhibits an information exposure vulnerability during HTTP 3xx redirect handling. The vulnerability allows sensitive credentials to be leaked to cross-domain destinations when following a redirect from a trusted origin.
This issue represents a violation of standard HTTP security semantics regarding credential propagation. The defect exposes application secrets to unintended recipients, leading to unauthorized access and potential downstream system compromise.
The vulnerability originates in the Redirect30xInterceptor component of the AsyncHttpClient library. When processing an HTTP 3xx redirection response, the library prepares a new request targeting the URL provided in the Location header.
Prior to the fix, the interceptor lacked adequate security boundary validation. It blindly copied existing request headers, including Authorization and Proxy-Authorization, into the new request state without verifying if the new target origin matched the original origin.
Furthermore, the library contained a secondary vulnerability referred to as a "Realm bypass". Even if developers explicitly enabled the stripAuthorizationOnRedirect(true) configuration flag, the library failed to clear its internal Realm object.
The NettyRequestFactory component subsequently utilized this stale Realm object to reconstruct valid authentication headers. Consequently, the explicit header stripping mechanism was rendered ineffective against credential leakage.
The remediation for this vulnerability was introduced in commit 6b2fbb7f88f322f1a90345d77d8a1ffe36dfa5f4. The patch focuses on strict origin validation and comprehensive credential object nullification.
The fix introduces a same-origin check utilizing the request.getUri().isSameBase(newUri) method. This function validates that the scheme, host, and port of the redirect destination match those of the original request.
Additionally, the patch implements a security downgrade check to prevent credential transmission when a redirect forces an HTTPS connection to downgrade to plaintext HTTP.
The core logic update establishes a composite boolean flag stripAuth to dictate header retention. If the redirect is cross-origin, downgrades the connection security, or matches the explicit strip configuration, the library completely purges the authentication state.
// Logic introduced in the patch
boolean sameBase = request.getUri().isSameBase(newUri);
boolean schemeDowngrade = request.getUri().isSecured() && !newUri.isSecured();
boolean stripAuth = !sameBase || schemeDowngrade || stripAuthorizationOnRedirect;
if (stripAuth) {
requestBuilder.setRealm(null); // Fixes the Realm bypass
future.setRealm(null);
future.setProxyRealm(null);
}This comprehensive state clearance ensures that the NettyRequestFactory cannot reconstruct the Authorization headers, effectively resolving the Realm bypass mechanism.
Exploitation of this vulnerability requires the attacker to manipulate the redirect target of an authenticated request initiated by the victim application. This is typically achieved via three primary attack vectors.
The most direct vector utilizes an open redirect vulnerability on the original trusted domain. The application attempts to authenticate to the trusted domain, which responds with a 3xx redirect pointing to an attacker-controlled server.
Alternatively, an attacker can employ DNS rebinding techniques. After the initial request resolves to a trusted IP address, the attacker updates the DNS record to point to an adversarial IP address before a subsequent redirect occurs.
A Man-in-the-Middle (MITM) attacker can also exploit this issue if the initial connection utilizes unencrypted HTTP or is successfully downgraded. The attacker intercepts the request and injects a malicious 3xx response, capturing the credentials when the client follows the redirect.
> [!NOTE]
> The official test suite RedirectCredentialSecurityTest.java acts as a functional proof-of-concept, verifying the behavior of both same-origin credential retention and cross-origin stripping.
The primary impact of this vulnerability is the exposure of sensitive authentication material to unauthorized third parties. This constitutes a severe breach of confidentiality.
When the leaked tokens are Bearer tokens or Session IDs, an attacker can impersonate the vulnerable application. This allows the adversary to access protected APIs, manipulate data, or pivot further into connected infrastructure.
The severity is classified as Moderate (CVSS 6.8) primarily because the attack complexity is High (AC:H). The attacker must possess the ability to control a redirect on the target domain, perform a MITM attack, or execute a DNS rebinding sequence.
Despite the elevated attack complexity, the confidentiality impact remains High (C:H). Applications utilizing AsyncHttpClient for automated API integrations are particularly susceptible to widespread token compromise if interacting with untrusted or poorly secured endpoints.
The definitive remediation strategy is upgrading the AsyncHttpClient dependency to version 3.0.9 or later. This version contains the comprehensive origin validation and Realm bypass fix.
For environments unable to immediately upgrade, developers can implement a functional workaround by completely disabling automatic redirect following. Setting .setFollowRedirect(false) in the client configuration forces the application to handle 3xx responses manually.
When utilizing this workaround, development teams must implement custom origin validation logic before manually issuing subsequent requests. This ensures the application replicates the security boundaries introduced in the patched library version.
It is critical to note that relying solely on .setStripAuthorizationOnRedirect(true) in unpatched versions is insufficient. The Realm bypass flaw ensures that credentials generated via internal Realm objects will still be transmitted to cross-domain targets.
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N| Product | Affected Versions | Fixed Version |
|---|---|---|
AsyncHttpClient AsyncHttpClient | < 3.0.9 | 3.0.9 |
| Attribute | Detail |
|---|---|
| CWE | CWE-522 |
| CVSS | 6.8 |
| Severity | Moderate |
| Attack Vector | Network |
| Exploit Status | PoC Available |
| Impact | High Confidentiality Loss |
Insufficiently Protected Credentials