Skip to content
Fencer Vulns
medium 6.8

CVE-2026-40490 json

AsyncHttpClient leaks authorization credentials to untrusted domains on cross-origin redirects

published 2026-04-14 6 mo ago modified 2026-09-10 1 mo ago also GHSA-cmxv-58fp-fm3g , EUVD-2026-23638

cvss
6.8
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.4%
EPSS 0.4% chance of exploitation in 30 days, percentile 36%
public exploits
0
none known

Summary

The AsyncHttpClient (AHC) library allows Java applications to easily execute HTTP requests and asynchronously process HTTP responses. When redirect following is enabled (followRedirect(true)), versions of AsyncHttpClient 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 leaks credentials on cross-domain redirects and HTTPS-to-HTTP downgrades. Additionally, 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. 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. The fix in versions 3.0.9 and 2.14.5 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 users unable to upgrade, set `(stripAuthorizationOnRedirect(true))` in the client config and avoid using Realm-based authentication with redirect following enabled. Note that `(stripAuthorizationOnRedirect(true))` alone is insufficient on versions prior to 3.0.9 and 2.14.5 because the Realm bypass still re-generates credentials. Alternatively, disable redirect following (`followRedirect(false)`) and handle redirects manually with origin validation.

Patch / fix

  • maven org.asynchttpclient:async-http-client 2.14.5, 3.0.9

Vendor advisories

What the vendors themselves say about their products: affected, fixed or not affected, and what to do.

red hat product security vex CVE-2026-40490 updated cvss 6.8

async-http-client: AsyncHttpClient: Credential leakage via improper handling of authorization headers during redirects

  • Red Hat build of Apache Camel for Spring Boot 4 org.asynchttpclient/async-http-client org.asynchttpclient/async-http-client Red Hat Fuse 7 org.asynchttpclient/async-http-client org.asynchttpclient/async-http-client Red Hat JBoss Enterprise Application Platform 7 org.asynchttpclient/async-http-client org.asynchttpclient/async-http-client Red Hat JBoss Enterprise Application Platform 8 com.ning/async-http-client com.ning/async-http-client, org.asynchttpclient/async-http-client org.asynchttpclient/async-http-client Red Hat JBoss Enterprise Application Platform Expansion Pack com.ning/async-http-client com.ning/async-http-client, org.asynchttpclient/async-http-client org.asynchttpclient/async-http-client
    affected: no fix available “Fix deferred”

Red Hat CSAF VEX © Red Hat, Inc., from https://security.access.redhat.com/data/csaf/v2/vex/; changed: reduced to product statuses and remediations. CC BY 4.0 · csaf

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
6 mo ago

Exploit prediction

0.41% chance of exploitation in the next 30 days, higher than 36% of all scored CVEs (FIRST EPSS, 2026-11-08).

CVSS scores

assigned by version score vector
CNA 3.1 6.8 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N
GitHub 3.1 6.8 CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:N/A:N

Affected packages

ecosystem package affected fixed in
maven org.asynchttpclient:async-http-client
>=3.0.0.Beta1, <3.0.9
>=2.0.0, <2.14.5
3.0.9
2.14.5

Affected products

  • AsyncHttpClient async-http-client

Classification

Weakness
  • CWE-200 Exposure of Sensitive Information to an Unauthorized Actor

References

Sources

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.