AsyncHttpClient CVE-2026-107229

Requires an application that shares a single AsyncHttpClient instance (using ThreadSafeCookieStore) across multiple distinct trust domains/origins, so that a cookie set by one origin can be replayed to another. The attacker must control, or be able to inject a Set-Cookie response from, one of those origins. Exploitation is LIMITED by this non-default deployment pattern (a per-origin or per-trust-boundary client is not vulnerable to cross-origin cookie leakage), by the AC:H conditions in the vector, and by the fact that impact is confined to cookie injection/session fixation (no data disclosure). Affected only on AsyncHttpClient versions in the 2.16.x and 3.0.11-3.0.13 ranges prior to the 3.0.14 fix.

This is a genuine but modest-priority issue, not a top-tier emergency. The provided CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:N, base 4.0, Medium) tells a consistent story: network-reachable and unauthenticated (PR:N) but with high attack complexity (AC:H) because exploitation depends on a specific, non-default application architecture, and the only impact is low integrity (I:L) via cookie injection/session fixation - there is no confidentiality (C:N) or availability (A:N) loss. No EPSS score was supplied, so exploitation probability cannot be quantified from the input. The CVE is NOT in CISA KEV and NO public exploit/POC is referenced - only an upstream advisory, fix commit, and release tag. There is therefore no evidence of real-world exploitation; this is a defense-in-depth cookie-handling hardening fix. The one notable caveat is the S:C (scope-changed) rating combined with AC:H: the real danger only materializes when a single AsyncHttpClient instance is deliberately shared across multiple trust domains, which is an application design choice rather than a default state, so real-world exposure is narrower than a bare 'network/unauthenticated' reading of the vector would suggest. Note also a minor version-range discrepancy between sources (see confidence_notes) that should be verified against the vendor advisory before remediation scoping.

An application uses one shared AsyncHttpClient instance (with ThreadSafeCookieStore) to make requests to multiple origins across different trust boundaries. An attacker-controlled origin returns a Set-Cookie with a crafted Domain attribute that AHC's incomplete public-suffix/domain validation wrongly accepts, so the cookie is later attached to requests sent to a different, trusted origin, enabling session fixation. No public exploit code is referenced, and the attack requires the shared-client-across-trust-domains pattern, consistent with the AC:H rating.