Summary
AsyncHttpClient: Cookies received over plaintext HTTP can plant, overwrite or delete Secure cookies set over HTTPS
Affected versions
- 3.x: up to and including 3.0.13
- 2.x: from 2.1.0, when the cookie store was introduced, up to and including 2.16.1
Workarounds
Do not share one CookieStore between plaintext and HTTPS origins that are not mutually trusted, including hosts under the same site. Disabling the cookie store also avoids it.
Details
ThreadSafeCookieStore.add(Uri, Cookie) reduces the request to its host and path before storing, so the scheme never reaches the code that decides whether to keep a cookie. get(Uri) does read it, but only to leave Secure cookies out of plaintext requests.
A narrower form survives the two storage rules on their own. The step 16 path test is one-way by design, so a plaintext SID for Path=/ is legitimately stored beside a Secure SID for Path=/account, and both match a request under /account. The store returned matching cookies in hash order, and the client keeps only the first cookie of each name when it builds the request (RequestBuilderBase.addCookieIfUnset), so an attacker could decide which one was sent, for example by padding one plaintext response with filler cookies. The ordering described above closes it.
The fix does not stop an HTTPS host under the same site from setting a domain cookie for a name the request host never sets itself. Only a __Host- cookie name prefix prevents that, and the client does not enforce cookie name prefixes.
Attribution
AI-assisted tools were used to support discovery and analysis.
Impact
The cookie store ignores the scheme a Set-Cookie arrived on. draft-ietf-httpbis-rfc6265bis-22 (approved to obsolete RFC 6265, in the RFC Editor queue) Section 5.7 requires a user agent to ignore a cookie with the Secure attribute unless it arrived over a secure connection (step 13), and to ignore a non-Secure cookie from an insecure connection when it would overlay a Secure cookie the store already holds (step 16). Neither rule is implemented. The only Secure handling is on retrieval, where a Secure cookie is not sent over plaintext.
So anyone who can answer a plaintext request to a site can set, replace or delete the site's Secure cookies, and the next HTTPS request carries the attacker's value back inside TLS:
http://example.com -> Set-Cookie: SID=attacker-value; Secure; Path=/
https://example.com -> Cookie: SID=attacker-value
This does not need an attacker on the network path. A plaintext host under the same site reaches the HTTPS one by setting a domain cookie:
http://insecure.example.com -> Set-Cookie: SID=attacker-value; Secure; Domain=example.com; Path=/
https://bank.example.com -> Cookie: SID=attacker-value
A plaintext Set-Cookie of the same name, domain and path overwrites a Secure cookie, and one with Max-Age=0 deletes it. Depending on what the application does with the cookie, this is session fixation into the HTTPS session, an overwritten CSRF token, or the removal of a cookie the site relies on. Unlike GHSA-qjr7-w8pj-pmv9, which can only add a cookie, this replaces or deletes one, hence Integrity: High; the harm lands on the HTTPS site, hence Scope: Changed.
CVE-2026-107226 has a CVSS score of 6.8 (Medium). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.0.14); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
Fixed in 3.0.14 on the 3.x line. A cookie with the Secure attribute is ignored unless the request was secure, and a non-Secure cookie from a request that did not use TLS is ignored when it would overlay a Secure cookie of the same name whose path its own path falls under. A plaintext response can therefore no longer plant, overwrite or delete a Secure cookie.
When several cookies of one name match a request, the client sends only the first, so the order in which the store returns them decides which one is used. That order is now: on a secure request, cookies received in a secure context (HTTPS, WSS or plaintext loopback) first; then the request host's own cookies before cookies set for a parent domain; then, within one host, longer paths first. A plaintext attacker cannot outrank a cookie the site set over HTTPS by ordering or padding its own cookies, or by setting one before the site sets its own.
Plaintext requests to localhost, or to an address literal that is a loopback address, count as secure, so a development server that sets Secure cookies over http://localhost gets them back. This is limited to the cookies such a server set itself: a Secure cookie that arrived over HTTPS is never sent over plaintext, loopback included, and a plaintext loopback port cannot overlay it. Numeric spellings that are not address literals, such as 127.0.0.256, and names under localhost are not treated as loopback, because the client resolves them as names.
The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14.
Frequently Asked Questions
- What is CVE-2026-107226? CVE-2026-107226 is a medium-severity security vulnerability in org.asynchttpclient:async-http-client (maven), affecting versions >= 3.0.0, <= 3.0.13. It is fixed in 3.0.14.
- How severe is CVE-2026-107226? CVE-2026-107226 has a CVSS score of 6.8 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of org.asynchttpclient:async-http-client are affected by CVE-2026-107226? org.asynchttpclient:async-http-client (maven) versions >= 3.0.0, <= 3.0.13 is affected.
- Is there a fix for CVE-2026-107226? Yes. CVE-2026-107226 is fixed in 3.0.14. Upgrade to this version or later.
- Is CVE-2026-107226 exploitable, and should I be worried? Whether CVE-2026-107226 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-107226 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-107226? Upgrade
org.asynchttpclient:async-http-clientto 3.0.14 or later.