Listen to this Post
The AsyncHttpClient (AHC) library, a popular asynchronous HTTP client for Java, is affected by a moderate-severity cookie injection vulnerability identified as CVE-2026-55688. This flaw resides in the `ThreadSafeCookieStore` component, which is responsible for managing cookies across HTTP sessions.
The core of the issue is a violation of RFC 6265, the standard that governs how cookies should be handled. Specifically, the `ThreadSafeCookieStore` would store a cookie based solely on the value of its `Domain` attribute without performing a crucial validation step. According to the RFC, before a client accepts a cookie from a server, it must verify that the server’s hostname is allowed to set a cookie for the domain specified in the `Domain` attribute. The library failed to perform this check.
This oversight creates a “cookie tossing” or “cookie injection” vulnerability (CWE-1275). An attacker who controls a host that the client connects to can plant a cookie that is scoped to a completely unrelated, third-party domain. For example, if a client connects to an attacker’s site, evil.com, that site could set a cookie with Domain=trusted-bank.com. Because the `ThreadSafeCookieStore` does not validate the request host (evil.com) against the cookie’s domain (trusted-bank.com), it accepts and stores the cookie.
The danger is realized on subsequent requests. When the same `AsyncHttpClient` instance later makes a request to trusted-bank.com, it will automatically include the forged cookie in the request headers. While the attacker cannot read the victim’s cookies, they can write their own. This allows for attacks like session fixation, where an attacker could set a known session ID and potentially hijack a user’s session, or overwrite other important cookies like CSRF tokens. This issue affects all versions of AsyncHttpClient from 2.0.0 up to (but not including) 2.16.0, and all 3.0.0 Beta versions prior to 3.0.11.
DailyCVE Form:
Platform: AsyncHttpClient
Version: 2.0.0-2.15.0, 3.0.0.Beta1-3.0.10
Vulnerability: Cookie Injection (CWE-1275)
Severity: Medium (CVSS 4.0)
Date: 2026-07-01
Prediction: Already Patched (2026-07-01)
What Undercode Say:
This vulnerability can be identified and mitigated using the following approaches.
Check your version:
Check your project's dependency version (example for Maven) mvn dependency:tree | grep async-http-client Or check the version in your build.gradle or pom.xml directly
Patch your application:
For Debian-based systems, update the package sudo apt-get update sudo apt-get install --only-upgrade async-http-client This updates to version 2.12.2-1+deb11u1 for Debian 11 or 2.12.3-1+deb12u1 for Debian 12
Verify the fix:
Check the installed version after patching dpkg -l | grep async-http-client
Exploit: (Educational Purposes!)
The vulnerability is triggered when an attacker-controlled server responds with a malicious `Set-Cookie` header. The vulnerable client will accept it without validating the domain.
A simplified example of the vulnerable code path:
// A vulnerable AsyncHttpClient setup
AsyncHttpClient client = new AsyncHttpClient();
// 1. Client connects to attacker-controlled host
client.prepareGet("http://attacker.com").execute().get();
// The attacker's server responds with:
// Set-Cookie: sessionId=malicious; Domain=trusted-bank.com
// 2. The vulnerable ThreadSafeCookieStore stores the cookie for trusted-bank.com
// 3. Later, a request to the trusted domain automatically includes the forged cookie
client.prepareGet("https://trusted-bank.com/account").execute().get();
// The request to trusted-bank.com now includes: Cookie: sessionId=malicious
Protection:
The primary protection is to upgrade to a fixed version:
– For 2.x users: Upgrade to version 2.16.0 or later.
– For 3.x users: Upgrade to version 3.0.11 or later.
If an immediate upgrade is not possible, the following workarounds can be applied:
– Disable the cookie store: If your application does not require cookies, you can disable it entirely by setting `setCookieStore(null)` on your `AsyncHttpClient` instance.
– Isolate cookie stores: Use a separate `AsyncHttpClient` instance (and thus a separate cookie store) for each trust domain. This ensures that cookies from an attacker-influenced host and a trusted host are never stored together.
– Implement a custom CookieStore: Provide a custom implementation of `CookieStore` that overrides the `add(Uri, Cookie)` method. In this custom implementation, you can enforce the RFC 6265 domain validation logic and reject any cookie whose domain does not properly match the request URI.
Impact:
The impact of this vulnerability is moderate (CVSS score 4.0). The primary risk is session fixation or the overwriting of other important cookies, which could lead to session hijacking or unauthorized access. The vulnerability does not allow an attacker to read cookies from the victim domain, limiting the scope of the information leak. The exploitation complexity is considered high, as it requires the attacker to control a host that the client application connects to. Furthermore, the EPSS score is less than 1%, indicating a very low probability of active exploitation in the wild. The primary affected applications are those that use a single, shared `AsyncHttpClient` instance to interact with both attacker-influenced and trusted hosts, such as crawlers, link preview generators, and SSRF-style services.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
