AsyncHttpClient CVE-2026-107282

Exploitation requires the application to use AsyncHttpClient prior to 3.0.13 or 2.16.1 configured with a ResponseFilter that triggers failover or retry replay of a request onto a DIFFERENT base origin (different host/scheme/port) or performs an HTTPS-to-HTTP scheme downgrade - the documented ResponseFilter failover/retry path is the exact trigger. The leak occurs because the replay updates the current request but leaves the target request, connection-pool partition key, CONNECT/proxy context, realm, and TLS setup bound to the original origin. Limiting factors: this is NOT a default configuration (stock AHC usage without a cross-host replaying filter is unaffected), AC:H and AT:P indicate a specific sequence/timing condition must be met, and there is no attacker-facing endpoint to exploit directly - the impact is credential/plaintext disclosure to whichever host the application itself replays to.

Signals here point in genuinely different directions, so the raw score should not drive prioritization. The vendor-supplied CVSS 4.0 vector (9.4) uses AV:N/PR:N/UI:N, which reads like trivial remote unauthenticated compromise, but AC:H and AT:P explicitly encode that success depends on a specific, non-default condition and a timing/sequence requirement - namely an application configured with a ResponseFilter whose failover/retry logic replays a request onto a different origin. No EPSS score, KEV listing, or public POC was provided; their absence is not disproof but means there is no evidence of active or at-scale exploitation. The issue is best understood as a client-side credential/data-leak (CWE-319): during cross-host replay, AsyncHttpClient leaves connection-pool selection, CONNECT handling, realm selection, and TLS setup pointing at the original origin, so the original host's path, Host header, Authorization credentials, or plaintext payload can be emitted to the replay destination. The high VC/VI and subsequent-system SC/SI reflect credential disclosure to an unintended host and request mis-delivery, not remote code execution. Net assessment: a real and serious data-exposure bug for the subset of deployments using replaying ResponseFilters, but for the majority of AHC users who do not configure such failover, real-world exploitable risk is substantially lower than 9.4 suggests. The beneficiary of the leak is largely the replay destination (or a network position observing the plaintext/credentials), not an arbitrary internet attacker against a default install.

A Java application uses AsyncHttpClient with a custom ResponseFilter that fails over or retries a failed request against a secondary host. When that replay targets a different origin (or downgrades HTTPS to HTTP), the library re-points the current request but not the target/proxy context, so the first host's Authorization credentials, Host header, or plaintext body are transmitted to the second host, disclosing secrets to an unintended destination. No public exploit identified at time of analysis; the fix commit ships a CrossHostReplayTest demonstrating the condition, but that is a regression test rather than a weaponized exploit.