CVE-2026-40490: AsyncHttpClient Information Disclosure

CVE-2026-40490 Overview

The AsyncHttpClient (AHC) library, a widely-used Java library for executing HTTP requests and asynchronously processing HTTP responses, contains a credential leakage vulnerability when redirect following is enabled. When followRedirect(true) is configured, versions prior to 3.0.9 and 2.14.5 forward Authorization and Proxy-Authorization headers along with Realm credentials to arbitrary redirect targets regardless of domain, scheme, or port changes.

This vulnerability allows credentials to leak on cross-domain redirects and HTTPS-to-HTTP downgrades. Even when stripAuthorizationOnRedirect is set to true, the Realm object containing plaintext credentials is still propagated to the redirect request, causing credential re-generation for Basic and Digest authentication schemes via NettyRequestFactory.

Critical Impact

An attacker who controls a redirect target (via open redirect, DNS rebinding, or MITM on HTTP) can capture Bearer tokens, Basic auth credentials, or any other Authorization header value, leading to account compromise and unauthorized access.

Affected Products

• AsyncHttpClient versions prior to 3.0.9
• AsyncHttpClient versions prior to 2.14.5
• Java applications using AHC with redirect following enabled (followRedirect(true))

Discovery Timeline

• 2026-04-18 - CVE CVE-2026-40490 published to NVD
• 2026-04-20 - Last updated in NVD database

Technical Details for CVE-2026-40490

Vulnerability Analysis

This vulnerability is classified as an Information Exposure issue (CWE-200) that affects how AsyncHttpClient handles credential propagation during HTTP redirects. The core issue lies in the Redirect30xInterceptor.java component, which fails to properly validate the target origin before forwarding sensitive authentication data.

When a redirect response (301, 302, 303, 307, or 308) is received, the library constructs a new request to the redirect location. Prior to the fix, this new request blindly inherited the original request's Realm object and Authorization headers, regardless of whether the redirect crossed security boundaries such as different domains, ports, or protocol downgrades from HTTPS to HTTP.

The vulnerability is particularly insidious because even the existing stripAuthorizationOnRedirect configuration option was insufficient—while it could strip the Authorization header, the Realm object containing plaintext credentials was still passed to NettyRequestFactory, which would regenerate the authentication headers for Basic and Digest schemes.

Root Cause

The root cause is improper credential handling in the redirect interception logic. The Redirect30xInterceptor class did not implement origin validation checks before propagating authentication credentials to redirect targets. Specifically:

1. The RequestBuilder unconditionally copied the Realm object from the original request: .setRealm(request.getRealm())
2. No comparison was made between the original request URI and the redirect target URI to detect cross-origin redirects
3. HTTPS-to-HTTP protocol downgrades were not detected, allowing credentials to be sent over unencrypted connections
4. The stripAuthorizationOnRedirect option only partially mitigated the issue by not addressing Realm-based credential regeneration

Attack Vector

The vulnerability requires network access and relies on an attacker being able to control or influence redirect targets. Attack scenarios include:

1. Open Redirect Exploitation: An attacker discovers an open redirect vulnerability on a trusted domain and chains it with this credential leakage to capture authentication tokens
2. DNS Rebinding: An attacker uses DNS rebinding techniques to redirect requests to their controlled server after initial validation passes
3. Man-in-the-Middle on HTTP: For applications making initial requests over HTTP, an attacker on the network can inject redirect responses pointing to their credential-harvesting server
4. Compromised Third-Party Redirects: If an application follows redirects from third-party APIs or services, a compromise of those services could lead to credential theft

The following patch from the security fix demonstrates the proper origin validation:

                         (statusCode == MOVED_PERMANENTLY_301 || statusCode == SEE_OTHER_303 || statusCode == FOUND_302 && !config.isStrict302Handling());
                 boolean keepBody = statusCode == TEMPORARY_REDIRECT_307 || statusCode == PERMANENT_REDIRECT_308 || statusCode == FOUND_302 && config.isStrict302Handling();
 
+                HttpHeaders responseHeaders = response.headers();
+                String location = responseHeaders.get(LOCATION);
+                Uri newUri = Uri.create(future.getUri(), location);
+                LOGGER.debug("Redirecting to {}", newUri);
+
+                boolean sameBase = request.getUri().isSameBase(newUri);
+                boolean schemeDowngrade = request.getUri().isSecured() && !newUri.isSecured();
+                boolean stripAuth = !sameBase || schemeDowngrade || stripAuthorizationOnRedirect;
+
+                if (stripAuth && (request.getRealm() != null || request.getHeaders().contains(AUTHORIZATION))) {
+                    LOGGER.debug("Stripping credentials on redirect to {}", newUri);
+                }
+
                 final RequestBuilder requestBuilder = new RequestBuilder(switchToGet ? GET : originalMethod)
                         .setChannelPoolPartitioning(request.getChannelPoolPartitioning())
                         .setFollowRedirect(true)
                         .setLocalAddress(request.getLocalAddress())
                         .setNameResolver(request.getNameResolver())
                         .setProxyServer(request.getProxyServer())
-                        .setRealm(request.getRealm())
+                        .setRealm(stripAuth ? null : request.getRealm())
                         .setRequestTimeout(request.getRequestTimeout());
 
+                if (stripAuth) {
+                    future.setRealm(null);
+                    future.setProxyRealm(null);
+                }

Source: GitHub Commit 6b2fbb7f8

Detection Methods for CVE-2026-40490

Indicators of Compromise

• Outbound HTTP requests containing Authorization headers being sent to unexpected external domains
• HTTP traffic logs showing authentication headers transmitted over unencrypted HTTP connections following HTTPS requests
• Unusual redirect chains in application logs where authenticated requests follow redirects to third-party domains
• Authentication token reuse or unauthorized access from IP addresses associated with known redirect targets

Detection Strategies

• Implement network monitoring to detect Authorization headers being sent to domains outside your trusted list
• Configure web application firewalls to alert on cross-origin redirects that include authentication headers
• Deploy Java application monitoring to track AsyncHttpClient redirect behavior and flag credential propagation across domain boundaries
• Review application dependencies using software composition analysis (SCA) tools to identify vulnerable AsyncHttpClient versions

Monitoring Recommendations

• Enable debug logging for AsyncHttpClient to track redirect flows and credential handling
• Monitor outbound network traffic for authentication headers sent to unexpected destinations
• Implement alerting for HTTPS-to-HTTP downgrades in application traffic patterns
• Track Maven/Gradle dependency updates and alert when vulnerable library versions are detected in builds

How to Mitigate CVE-2026-40490

Immediate Actions Required

• Upgrade AsyncHttpClient to version 3.0.9 or 2.14.5 immediately to receive the complete security fix
• Audit all applications using AsyncHttpClient to identify those with redirect following enabled
• Review application logs for evidence of credential leakage to unauthorized domains
• Rotate any credentials (Bearer tokens, API keys, Basic auth passwords) that may have been exposed through this vulnerability

Patch Information

The fix is available in AsyncHttpClient versions 3.0.9 and 2.14.5. The patch automatically strips Authorization and Proxy-Authorization headers and clears Realm credentials whenever a redirect crosses origin boundaries (different scheme, host, or port) or downgrades from HTTPS to HTTP.

For Maven projects, update your pom.xml:

<!-- For 3.x branch -->
<dependency>
    <groupId>org.asynchttpclient</groupId>
    <artifactId>async-http-client</artifactId>
    <version>3.0.9</version>
</dependency>

<!-- For 2.x branch -->
<dependency>
    <groupId>org.asynchttpclient</groupId>
    <artifactId>async-http-client</artifactId>
    <version>2.14.5</version>
</dependency>

For detailed patch information, see the GitHub Security Advisory GHSA-cmxv-58fp-fm3g and release notes for version 3.0.9 and version 2.14.5.

Workarounds

• Disable redirect following entirely with followRedirect(false) and implement manual redirect handling with proper origin validation
• Set stripAuthorizationOnRedirect(true) in client configuration AND avoid using Realm-based authentication with redirect following enabled (note: this is insufficient as a complete fix on unpatched versions)
• Implement a custom RedirectInterceptor that validates redirect targets against an allowlist of trusted domains before forwarding credentials
• Use network-level controls to restrict outbound connections from applications to only approved destinations

# Configuration example for disabling automatic redirects
# In your Java application configuration:

# Option 1: Disable redirect following completely
asyncHttpClient = Dsl.asyncHttpClient(
    Dsl.config()
        .setFollowRedirect(false)
)

# Option 2: Partial mitigation (insufficient alone on unpatched versions)
asyncHttpClient = Dsl.asyncHttpClient(
    Dsl.config()
        .setFollowRedirect(true)
        .setStripAuthorizationOnRedirect(true)
)