AsyncHttpClient EUVD-2026-41134

Exploitation requires that the target application uses a single AsyncHttpClient instance - and therefore the default shared ThreadSafeCookieStore - to issue HTTP requests to both (1) an attacker-controlled or attacker-influenced server and (2) a trusted server whose domain the attacker wishes to target, with both connections occurring within the same application process lifetime so the injected cookie persists in the shared store. Applications that instantiate a separate AHC client per destination domain are not exploitable, as each instance holds an isolated CookieStore. Applications that supply a custom CookieStore with proper domain-origin validation, or that configure a no-op CookieStore, are also not exploitable. The CVSS PR:N confirms that the attacker requires no authentication or privileges - they only need to operate an HTTP server that the victim AHC client will contact. AC:H reflects that the required shared-instance architecture is a non-trivial deployment pattern, not present in all AHC consumers.

The NVD CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N, score 4.0) accurately reflects an architecturally constrained but real threat. AC:H correctly captures the strict prerequisite that the vulnerable application must use one shared AHC instance to reach both an attacker-controlled server and a trusted target server within the same lifecycle. S:C (Scope Changed) is appropriate because the integrity impact crosses a domain boundary to affect a third-party host beyond the AHC client itself. No EPSS score was provided in the source intelligence, preventing probability-of-exploitation quantification. This CVE is not listed in the CISA KEV catalogue, and no public exploit code has been identified at time of analysis, making real-world exploitation conditional on application architecture rather than trivially achievable. The highest-risk deployments are aggregation services, API gateways, or scraping platforms that fan out HTTP requests to user-supplied or third-party URLs alongside internal or authenticated endpoints using a shared client. Microservices that instantiate a separate AHC client per destination, or that disable cookie handling, are not exploitable. No conflicting signals were detected between the CVSS vector and the vulnerability description.

An attacker operates a web server that a target Java application calls - for example, as part of a third-party REST API integration or a user-supplied URL fetch. The attacker's server responds to a legitimate request with a Set-Cookie header such as 'session=attacker_value; Domain=internal-auth.example.com', which AHC stores without domain validation. On the application's next request to internal-auth.example.com, AHC automatically includes the injected cookie, potentially overwriting the legitimate session token or injecting an attacker-controlled value into an authenticated transaction. No public exploit code has been identified at time of analysis, but the mechanism is mechanically straightforward once the shared-CookieStore precondition is satisfied.