CVE-2026-55688: Cookie Tossing / Cookie Injection Vulnerability in AsyncHttpClient

AsyncHttpClient (AHC) is a widely used Java library designed to execute HTTP requests asynchronously. The library is commonly integrated into backend services, microservices, web scrapers, and API gateways to execute outbound connections.

By default, AHC implements a shared cookie management system utilizing the ThreadSafeCookieStore class. This shared state model introduces a significant attack surface if a single client instance is reused to interact with both trusted resources and external, attacker-influenced endpoints.

Under default conditions, the HTTP client should strictly isolate cookie storage based on origin boundaries. When this boundary isolation fails, the client is exposed to cookie injection techniques, enabling unauthorized configuration of client-side application states across different security domains.

The root cause of CVE-2026-55688 is the library's omission of RFC 6265 Section 5.3 Step 6 verification during the parsing and storing of HTTP cookies. RFC 6265 governs how HTTP state management mechanisms must behave. Specifically, it mandates that an agent must reject cookies whose Domain attribute does not domain-match the request URI's host.

Prior to the patch, the ThreadSafeCookieStore.add method accepted the domain attribute specified in the server's Set-Cookie header without comparing it against the requesting host's domain. When the store processed the incoming metadata, it immediately mapped the parsed cookie to the domain claimed by the Set-Cookie header itself, rather than restricting it to the domain of the originating server.

Consequently, an untrusted server could register a cookie for an unrelated target domain. When the client subsequently initialized a request to the target domain, the shared ThreadSafeCookieStore retrieved the injected cookie and appended it to the outgoing HTTP headers.

The vulnerability resided in ThreadSafeCookieStore.java. In the vulnerable implementation, the add method accepted incoming cookies and assigned their storage key directly using the parsed domain attribute.

// Vulnerable Implementation (Before Fix)
private void add(String requestDomain, String requestPath, Cookie cookie) {
    AbstractMap.SimpleEntry<String, Boolean> pair = cookieDomain(cookie.domain(), requestDomain);
    String keyDomain = pair.getKey();
    boolean hostOnly = pair.getValue();
    
    // Vulnerable code lacked domain-matching validation.
    // Any domain specified in the Set-Cookie header was processed directly.
    
    String keyPath = cookiePath(cookie.path(), requestPath);
    CookieKey key = new CookieKey(cookie.name().toLowerCase(), keyPath);
    // ... processes storage without verifying requestDomain against keyDomain ...
}

The fix, introduced in PR #2196 and PR #2199, added standard validation to reject mismatches.

// Patched Implementation (With Validation Guard)
private static boolean domainsMatch(String cookieDomain, String requestDomain) {
    return requestDomain.equals(cookieDomain) || requestDomain.endsWith('.' + cookieDomain);
}
 
private void add(String requestDomain, String requestPath, Cookie cookie) {
    AbstractMap.SimpleEntry<String, Boolean> pair = cookieDomain(cookie.domain(), requestDomain);
    String keyDomain = pair.getKey();
    boolean hostOnly = pair.getValue();
 
    // RFC 6265 Section 5.3 Step 6 verification
    // Rejects the cookie if the domain attribute does not domain-match the request host
    if (!hostOnly && !domainsMatch(keyDomain, requestDomain)) {
        return;
    }
 
    String keyPath = cookiePath(cookie.path(), requestPath);
    CookieKey key = new CookieKey(cookie.name().toLowerCase(), keyPath);
    // ... processes validated storage ...
}

While the patch prevents basic domain mismatches, it does not include Public Suffix List (PSL) validation, which represents an architectural limitation in multi-tenant environments.

An exploitation flow requires that the victim client application uses a single, shared AsyncHttpClient instance to process requests to both an attacker-controlled endpoint and a targeted secure domain.

First, the client application issues an HTTP request to http://www.attacker.com/. The attacker's server responds with an HTTP status code and a malicious header payload: Set-Cookie: session_id=evil_attacker_session; Domain=victim.com; Path=/.

Second, the vulnerable ThreadSafeCookieStore parses this response. Because of the missing validation check, AHC indexes this cookie under the domain key victim.com.

Third, when the client subsequently initiates a legitimate request to https://victim.com/, AHC queries the ThreadSafeCookieStore. The engine retrieves the injected cookie and injects it into the outbound request's headers, thereby compromising downstream authentication or session mechanisms.

The CVSS Base Score is evaluated at 4.0 (Medium) due to the high complexity required to execute the attack, as it relies on the execution of multiple sequentially targeted requests. However, the scope of the vulnerability is changed (S:C), meaning the compromise occurs across distinct security authorities.

Successful exploitation can facilitate session fixation attacks where the attacker pre-determines the session identifier of a client communicating with a secure server. Additionally, this allows attackers to overwrite critical anti-CSRF token cookies, rendering web interfaces susceptible to cross-site request forgery.

Furthermore, because the domainsMatch helper function uses a simple .endsWith() matching mechanism, it lacks verification against the Public Suffix List. In multi-tenant systems utilizing shared suffixes (e.g., github.io or herokuapp.com), an attacker hosting an application on a tenant subdomain can still toss cookies to sister subdomains, posing continued risks in multi-tenant configurations.