Async-Http-Client Cross-Host Replay Leaks Credentials and Downgrades TLS (GHSA-jmqq-x5g9-9p2w)

What happened

A GitHub Security Advisory published on October 8, 2026 discloses a vulnerability (CVE-2026-107282) in org.asynchttpclient:async-http-client, affecting the 2.x line through 2.16.0 and the 3.x line through 3.0.12. According to the advisory, when the client replays a request to a different host — via a ResponseFilter-driven failover or the IOException retry path — it updates the "current request" but fails to update the "target request" to the new host. Four internal consumers then read that stale target value, causing the original host's request data, credentials, or both to be sent to the new host.

The advisory describes four concrete consequences of this stale-state bug: the connection pool key is derived from the old host, causing later requests intended for host A to be served over a connection already open to host B; CONNECT-tunnel requests negotiate TLS correctly with host B but then write host A's path, Host header, and Authorization header into that tunnel; the original auth realm is reapplied to the replay request even though it carries no realm of its own, regenerating credentials for the new host; and the scheme of the original request determines whether TLS is used at all, so an http:// request replayed as https:// can be sent in cleartext. The advisory notes this is long-standing behavior rather than a recent regression, and that the project's existing replay tests never covered a cross-host replay scenario. Exploit status is listed as poc-public.

Why it matters for defenders

This is not an exotic attack chain — the advisory states the replay happens through documented, ordinary features (a supported failover ResponseFilter pattern and standard retry-on-IOException logic). Any application using async-http-client with configured credentials, proxying, or failover across hosts is affected by design, without an attacker needing to induce anything. The impact is credential and request-data leakage to an unintended host, plus a silent downgrade from TLS to cleartext — and because the TLS handshake genuinely completes with the second host, there's no certificate mismatch to alert on.

What defenders should watch for or do now

• Inventory services depending on org.asynchttpclient:async-http-client (Maven coordinate org.asynchttpclient:async-http-client) and check the version against the affected ranges (≤2.16.0, ≤3.0.12).
• Prioritize upgrading to 2.16.1 or 3.0.13, where the advisory states the target request now moves with the replay, and the proxy moves with it in the connection pool key.
• Until patched, the advisory's workaround is to avoid any ResponseFilter that replays to a different host and to disable request retries wherever the client is configured with credentials or routed through a proxy; replaying to the same host is not affected.
• At a high level, defenders can hunt for outbound requests from async-http-client-based services carrying authorization headers or hostnames inconsistent with the destination, or for unexpected cleartext HTTP connections where HTTPS was configured — though confirming this specific condition requires application-level logging rather than network signatures alone.

Developing intel

This is a same-day disclosure and detail here reflects only what the GitHub Security Advisory reports; there is no known in-the-wild exploitation or ransomware linkage at this time. Treat this as developing intel and consult the original advisory for authoritative detail and future updates: GHSA-jmqq-x5g9-9p2w.