CVE-2026-45300: AsyncHttpClient Cookie Leakage on Cross-Origin Redirects

Technical summary

CVE-2026-45300 is a cookie leakage vulnerability in AsyncHttpClient's `Redirect30xInterceptor.java` class. The `propagatedHeaders()` method, which governs header handling during HTTP 30x redirects, implements a safelist of headers to preserve across origin boundaries. While this safelist correctly excludes `Authorization` and `Proxy-Authorization` headers, it erroneously permits `Cookie` headers to pass through. Because HTTP cookies are inherently bound to a domain/origin pair, forwarding them to a cross-origin redirect target violates the same-origin policy intent and exposes session credentials to external parties. The vulnerability affects AHC 2.x versions before 2.15.0 and 3.x versions before 3.0.10. Exploitation requires user interaction (clicking a link or loading a page) that triggers a redirect chain from a trusted origin to an attacker-controlled endpoint.

Business impact

If your applications use vulnerable versions of AsyncHttpClient, attackers could harvest session cookies and impersonate authenticated users. This directly threatens the confidentiality of user sessions and could enable unauthorized access to sensitive data or actions performed on behalf of compromised users. The vulnerability has no integrity or availability impact, but the confidentiality breach is severe—especially if your systems rely on cookie-based authentication and serve users across untrusted networks or handle high-value transactions. Organizations running microservices or integrations that use AHC for inter-service communication should also assess whether internal service-to-service redirects could be weaponized.

Affected systems

AsyncHttpClient (async-http-client) versions 2.0.0 through 2.14.x (2.x branch) and versions 3.0.0 through 3.0.9 (3.x branch) are vulnerable. Any Java application that includes these libraries as a dependency and makes HTTP requests that may encounter 30x redirects is at risk. This is particularly relevant for applications built with frameworks that use AHC under the hood (e.g., Play Framework, which has historically bundled AHC for HTTP client functionality) or microservices architectures that explicitly depend on AHC for outbound HTTP calls.

Exploitability

Exploitation requires two conditions: (1) the vulnerable application must follow a redirect (a common and often unavoidable behavior), and (2) a user or process must be tricked into visiting or interacting with a URL that initiates the redirect chain. The attack vector is network-based and requires no special privileges or authentication. While the `UI:R` component indicates user interaction is necessary (the user must click a link or load a malicious page), the bar for triggering this interaction is low—a phishing email, malicious ad, or compromised website can serve as the entry point. No exploit code or advanced techniques are needed; the flaw is triggered by standard HTTP behavior.

Remediation

Upgrade AsyncHttpClient to version 2.15.0 or later (if on the 2.x branch) or version 3.0.10 or later (if on the 3.x branch). These versions correctly filter out `Cookie` headers when following redirects to a different origin. For applications unable to upgrade immediately, consider using a custom `RequestInterceptor` or `Redirect30xInterceptor` subclass to strip cookies before redirect processing, though this workaround is temporary and official patching is strongly recommended.

Patch guidance

1. Identify all Java applications and services in your inventory that depend on AsyncHttpClient. Check your build files (pom.xml for Maven, build.gradle for Gradle, etc.) and dependency reports. 2. Test the patched versions (2.15.0 or 3.0.10) in a non-production environment to ensure compatibility with your application and any custom interceptors or request handlers. 3. Deploy patches via your standard change management and deployment pipelines. 4. Verify that the patched version is in use by checking runtime classpath or application logs after deployment. 5. For applications that cannot be updated immediately, implement compensating controls (e.g., network segmentation, additional authentication on redirect targets, cookie attribute restrictions like SameSite) until a full upgrade is feasible.

Detection guidance

Monitor outbound HTTP traffic from applications using vulnerable AHC versions for unexpected cookies being sent to external or unexpected domains. Implement HTTP logging or packet inspection rules that flag `Cookie` headers in redirect responses or requests to cross-origin destinations. Check application logs and framework-level request/response logs for signs of cookie exfiltration. If you have observability tools (APM, network telemetry), create alerts for HTTP 30x responses followed by requests to different origins that include cookie data. Additionally, audit your dependency manifests and use Software Composition Analysis (SCA) tools to automatically flag vulnerable AHC versions in your codebase.

Why prioritize this

Despite the requirement for user interaction, this vulnerability carries a HIGH CVSS score (7.4) due to its high confidentiality impact and ease of exploitation. Session cookies are a critical authentication mechanism, and their leakage can lead directly to unauthorized access. The vulnerability affects a widely-used Java HTTP client library, increasing the likelihood of exposure across many applications. The fix is straightforward (a version bump), making remediation low-friction and urgent. Organizations should prioritize patching within 30 days, especially for internet-facing applications and those handling sensitive user data.

Risk score, explained

The CVSS 3.1 score of 7.4 (HIGH) reflects: (1) network attack vector (AV:N)—no special network access required; (2) low attack complexity (AC:L)—standard HTTP behavior, no special conditions; (3) no privilege requirement (PR:N); (4) user interaction required (UI:R)—user must click a link or load a page; (5) changed scope (S:C)—the vulnerability impacts confidentiality beyond the vulnerable component itself; (6) high confidentiality impact (C:H)—sensitive session cookies are leaked; (7) no integrity or availability impact (I:N, A:N). The 'changed scope' modifier elevates the score because the confidentiality breach extends to user sessions and downstream systems that rely on those cookies.

Frequently asked questions