CVE-2026-107226: 
Java vulnerability analysis and mitigation

CVE-2026-107226 is a cookie security bypass vulnerability in the AsyncHttpClient (AHC) Java library (org.asynchttpclient:async-http-client) where cookies received over plaintext HTTP can plant, overwrite, or delete Secure-flagged cookies that were set over HTTPS. The vulnerability affects versions 3.0.0–3.0.13 and 2.1.0–2.16.1 of the library. It was published by the project maintainer on September 24, 2026, and added to the GitHub Advisory Database on October 8, 2026. The CVSS v3.1 base score is 6.8 (Medium) (GitHub Advisory, AHC Security Advisory).

The root cause lies in ThreadSafeCookieStore.add(Uri, Cookie), which reduces the request URI to only its host and path before storing a cookie — the scheme (HTTP vs. HTTPS) is never recorded or checked at storage time (CWE-693: Protection Mechanism Failure). As a result, neither of the two rules mandated by draft-ietf-httpbis-rfc6265bis-22 §5.7 are enforced: (1) a cookie with the Secure attribute must be ignored unless it arrived over a secure connection (step 13), and (2) a non-Secure cookie from an insecure connection must be ignored if it would overlay an existing Secure cookie (step 16). This enables session fixation (CWE-384) because an attacker controlling any plaintext HTTP response to the client can inject Set-Cookie: SID=attacker-value; Secure; Path=/, and the next HTTPS request will carry that attacker-controlled value. Exploitation does not require a network-path attacker — a plaintext sibling host under the same registrable domain can set a domain-scoped cookie that reaches the HTTPS target (GitHub Advisory, AHC Security Advisory).

Successful exploitation allows an attacker to fix or replace session identifiers (session fixation), overwrite CSRF tokens, or delete cookies that the HTTPS application depends on — all of which affect the integrity of the HTTPS session. Because the injected cookie is transmitted inside TLS on the next HTTPS request, the attack crosses the HTTP/HTTPS security boundary (Scope: Changed). Confidentiality and availability are not directly impacted, but integrity is rated High, as the attacker fully controls the cookie value sent to the secure origin. Applications using AHC as an HTTP client that share a CookieStore across plaintext and HTTPS origins are at risk (GitHub Advisory, AHC Security Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the advisory date. The CVE status is listed as "Reserved" and no EPSS score or CISA KEV catalog entry is available. Exploitation requires high attack complexity — the attacker must be able to influence a plaintext HTTP response seen by the vulnerable AHC client, either via a network position or by controlling a plaintext sibling host under the same domain (GitHub Advisory).

1. Identify a target: Locate a Java application using org.asynchttpclient:async-http-client versions 3.0.0–3.0.13 or 2.1.0–2.16.1 that makes both HTTP and HTTPS requests and shares a single CookieStore across origins.
2. Gain ability to respond to a plaintext HTTP request: Either position yourself on the network path to intercept/respond to an HTTP request from the AHC client, or control a plaintext HTTP host (e.g., http://insecure.example.com) that is a sibling of the HTTPS target under the same registrable domain.
3. Inject a malicious Set-Cookie header: In the HTTP response, include a Set-Cookie header targeting the session cookie name used by the HTTPS application, e.g.:

   Set-Cookie: SID=attacker-value; Secure; Domain=example.com; Path=/

   Because the Secure attribute is not validated at storage time, AHC stores this cookie despite it arriving over plaintext.
4. Trigger an HTTPS request: Wait for or cause the AHC client to make a subsequent HTTPS request to the target origin (e.g., https://bank.example.com/).
5. Cookie delivered inside TLS: AHC sends Cookie: SID=attacker-value in the HTTPS request, completing session fixation, CSRF token replacement, or cookie deletion (using Max-Age=0) depending on the application's cookie usage (GitHub Advisory, AHC Security Advisory).

• Network: Unexpected Set-Cookie headers with the Secure attribute appearing in plaintext HTTP (port 80) responses from hosts that are not the primary HTTPS application server; domain-scoped Set-Cookie headers (e.g., Domain=example.com) arriving over HTTP targeting cookie names used by the HTTPS application.
• Logs: Application-side session anomalies such as session fixation events, CSRF validation failures, or unexpected session invalidations that correlate with prior HTTP requests from the AHC client.
• Application Behavior: Authentication or authorization failures on HTTPS endpoints immediately following HTTP requests to the same or sibling domains, suggesting a cookie value was replaced or deleted.

Upgrade: The fix is available in version 3.0.14 of org.asynchttpclient:async-http-client. The 2.x line is end-of-life and will not receive a patch — users on 2.x must upgrade to 3.0.14. The fix enforces both rfc6265bis §5.7 rules: Secure cookies are rejected unless the request was secure, and non-Secure cookies from plaintext requests are rejected if they would overlay an existing Secure cookie. Workarounds (if immediate upgrade is not possible): do not share a single CookieStore instance between plaintext HTTP and HTTPS origins that are not mutually trusted; alternatively, disable the cookie store entirely (AHC Security Advisory, AHC v3.0.14 Release).