CVE-2026-40490: When Your HTTP Client Ships Your Credentials to Strangers

On April 23, 2026, security researchers dropped a vulnerability that should make every Java backend engineer check their HTTP client configuration. CVE-2026-40490 is an information disclosure flaw in AsyncHttpClient (AHC)—one of the most widely used asynchronous HTTP libraries in the Java ecosystem—that silently forwards Authorization headers, Proxy-Authorization headers, and plaintext Realm credentials to arbitrary redirect targets. Different domain? Sure. HTTPS downgraded to HTTP? Absolutely. Attacker-controlled infrastructure? Here are your Bearer tokens, have a nice day.

The timing is almost poetic. One week later, Instructure disclosed that attackers had compromised its Canvas LMS platform, exposing 240–275 million records across 15,000 institutions. The initial entry point? API key abuse. When your HTTP client leaks credentials on redirects and your API keys grant broad access, the chain from "minor configuration oversight" to "front-page breach" gets very short, very fast.

This vulnerability doesn't require an exotic exploit chain. It requires an attacker who controls a redirect destination—via an open redirect on a legitimate site, DNS rebinding, or a simple man-in-the-middle position on an HTTP endpoint. That's a low bar in 2026.

AsyncHttpClient's followRedirect(true) feature is supposed to be helpful. You make a request, the server responds with a 302, and AHC automatically follows the Location header to complete the operation. The problem is what AHC takes with it on that journey.

In versions prior to 3.0.9 and 2.14.5, AHC forwards:

• Authorization headers
• Proxy-Authorization headers
• Realm objects containing plaintext credentials

To any redirect target. It doesn't matter if the redirect crosses from api.yourservice.com to evil.tld, from https:// to http://, or from port 443 to port 8080. The headers go along for the ride. An attacker who receives that redirected request now has your Bearer token, your Basic auth credentials, or your Digest authentication hash.

Here's where it gets worse: even if you set stripAuthorizationOnRedirect(true), the Realm object—containing your plaintext username and password—is still propagated to the redirect request. AHC's NettyRequestFactory cheerfully regenerates Basic and Digest authentication headers from that Realm data. So the explicit "strip" flag doesn't actually strip the thing that matters most.

The fix in 3.0.9 and 2.14.5 finally does what users expected all along: it strips Authorization and Proxy-Authorization headers and clears Realm credentials whenever a redirect crosses origin boundaries or downgrades from HTTPS to HTTP. You know, the sane behavior.

Open Redirect on a Trusted Domain. Your API calls https://api.partner.com/data, which has an open redirect vulnerability. The partner's server responds with 302 Location: https://attacker.com/collect. AHC follows the redirect and delivers your Authorization: Bearer eyJhbG... straight to the attacker's server.

DNS Rebinding. An attacker tricks your application into resolving a trusted hostname to their IP address. When AHC follows the redirect, it thinks it's still talking to the same origin because the hostname matches. The credentials fly out anyway.

HTTPS-to-HTTP Downgrade. Your request starts on HTTPS, but the redirect points to HTTP. Without transport encryption, any MITM attacker on the network path can read the redirected request. AHC was happily downgrading and shipping credentials over plaintext until the patch.

// VULNERABLE: AsyncHttpClient < 3.0.9 or < 2.14.5
AsyncHttpClient client = Dsl.asyncHttpClient(
    Dsl.config()
        .setFollowRedirect(true)          // Enables redirect following
        .setRealm(new Realm.Builder("admin", "SuperSecret123")
            .setScheme(Realm.AuthScheme.BASIC))
        // stripAuthorizationOnRedirect(true) does NOT fully protect
        // because the Realm object is still propagated
);

// Attacker-controlled redirect receives:
// Authorization: Basic YWRtaW46U3VwZXJTZWNyZXQxMjM=
// Plus the Realm object regenerates auth on each hop

// FIXED: Upgrade to 3.0.9+ or 2.14.5+
// The library now automatically strips auth headers on cross-origin redirects
// and clears Realm credentials on HTTPS-to-HTTP downgrades.

Step 1: Identify if you're affected. Check your dependency tree for org.asynchttpclient:async-http-client with versions below 3.0.9 or 2.14.5. Many Java frameworks—Play Framework, Spring WebFlux integrations, and various microservice libraries—bundle AHC transitively. Run mvn dependency:tree or gradle dependencies and grep for async-http-client.

Step 2: Upgrade immediately. The patched versions fix the behavior at the library level. If you're stuck on an older version for compatibility reasons, set followRedirect(false) and handle redirects manually in your application code, where you can inspect the target URL before forwarding credentials.

Step 3: Audit your API credentials. If you've been running a vulnerable version in production, assume your credentials have been exposed to any redirect target your application has contacted. Rotate API keys, revoke OAuth tokens, and invalidate active sessions. The Instructure breach shows how quickly a credential compromise escalates when those credentials have broad access to institutional data.

Step 4: Check transitive dependencies. IBM's DevOps Test Performance was affected because it bundles AHC. Your vulnerability scanner might flag the direct dependency but miss embedded or shaded JARs. Check everything.

CVE-2026-40490 is not an exotic zero-day requiring nation-state resources. It's a configuration-driven credential leak in a popular library that behaves in a way developers reasonably assumed was safe. The OAuth redirect abuse Microsoft warned about in March, the cPanel authentication bypass being actively exploited with a CVSS 9.8, and now this—all of them share a common thread: systems doing what they were told to do, in ways that expose credentials to unintended recipients.

The Java ecosystem has a particular weakness here. Transitive dependency chains in Maven and Gradle mean that AHC can be pulled in by frameworks three layers deep, with developers never directly configuring it. A Spring Boot starter or a test utility pulls in AHC with followRedirect(true) as the default, and suddenly your microservice is shipping Bearer tokens to every 302 responder on the internet.

For DevSecOps teams, the fix is not just patching. It's visibility. You need to know which HTTP clients your services use, how they're configured, and whether they handle redirects safely. You need dependency scanning that catches shaded JARs. And you need to treat API credentials as volatile—rotating them aggressively, scoping them tightly, and assuming that any request path involving redirects is a potential exfiltration channel.

AsyncHttpClient 3.0.9 and 2.14.5 fix the immediate problem. The deeper problem is that we keep building systems that trust redirect targets by default. Maybe it's time to stop.