CVE-2026-107226: AsyncHttpClient Cookies Received Over Plaintext HTTP Vulnerability

MODERATE
Advisory Identifier: GHSA-p2jm-6hj6-9rjg
CVSS 6.8
CWE-384 CWE-693
Published
Advisory Summary

CVE-2026-107226 is a MODERATE (CVSS 6.8) cookies received over plaintext http vulnerability (CWE-384: Session Fixation) affecting AsyncHttpClient libraries in the Maven ecosystem. The issue involves cookies received over plaintext http can plant, overwrite or delete secure cookies set over https. Remediation is available by upgrading affected packages to version 3.0.14.

CVE-2026-107226 at a Glance

CVE Identifier CVE-2026-107226
GHSA Identifier GHSA-p2jm-6hj6-9rjg
Severity MODERATE
CVSS v3.1 Base Score 6.8
CWE Classification CWE-384: Session Fixation
Affected Product AsyncHttpClient
Package Ecosystem Maven
Published Date
Last Updated

Security Impact

CVSS: 6.8

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality None (C:N)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2026-107226

To remediate this vulnerability, upgrade all affected AsyncHttpClient dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

org.asynchttpclient:async-http-client fixed: 3.0.14
<dependency>
    <groupId>org.asynchttpclient</groupId>
    <artifactId>async-http-client</artifactId>
    <version>3.0.14</version>
</dependency>
org.asynchttpclient:async-http-client fixed: Latest secure release
<dependency>
    <groupId>org.asynchttpclient</groupId>
    <artifactId>async-http-client</artifactId>
    <version>Latest secure release</version>
</dependency>
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

mvn dependency:tree -Dincludes=org.asynchttpclient

How to Check if You Are Affected

To determine whether your Java application is affected by CVE-2026-107226, inspect your build dependencies using the Maven Dependency Plugin:

mvn dependency:tree -Dincludes=org.asynchttpclient

Analyze the terminal output to locate any version of AsyncHttpClient in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.0.14), your application is affected.

Note: The mvn dependency:tree -Dincludes=org.asynchttpclient command inspects the resolved dependency graph declared in your project's POM files; it does not perform automated security scanning or inspect runtime dynamic classpaths. Always verify runtime container classpaths and shaded JARs.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-384: Session Fixation, where authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions. In AsyncHttpClient, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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. ### 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 ### Patches 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. ### 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.

CVE-2026-107226 Affected AsyncHttpClient Versions

2 component(s)
Fixed Versions:
3.0.14
Product / Package Ecosystem Affected Versions Fixed Version
org.asynchttpclient:async-http-client
Maven
≥ 3.0.0
< 3.0.14
3.0.14
org.asynchttpclient:async-http-client
Maven
≥ 2.1.0
≤ 2.16.1

References

Frequently Asked Questions

What is CVE-2026-107226?
CVE-2026-107226 is a security vulnerability in AsyncHttpClient involving Cookies received over plaintext HTTP can plant, overwrite or delete Secure cookies set over HTTPS under CWE-384: Session Fixation.
Which AsyncHttpClient versions are affected?
Affected versions include releases prior to 3.0.14 across affected packages: org.asynchttpclient:async-http-client.
What version fixes CVE-2026-107226?
Upgrading to 3.0.14 (or the latest patched release for your respective branch) resolves the vulnerability.
Is async-http-client affected?
Yes, org.asynchttpclient:async-http-client is affected in releases prior to 3.0.14, Latest secure release. Upgrade your dependency to 3.0.14, Latest secure release or later.
What is the CVSS score of CVE-2026-107226?
CVE-2026-107226 has a CVSS v3.1 base score of 6.8 (MODERATE) with vector string CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N.
What CWE is associated with CVE-2026-107226?
CVE-2026-107226 is classified under CWE-384: Session Fixation (Authenticating a user, or otherwise establishing a new user session, without invalidating any existing session identifier gives an attacker the opportunity to steal authenticated sessions.).
How can I check Maven dependencies for CVE-2026-107226?
Run the dependency tree command: 'mvn dependency:tree -Dincludes=org.asynchttpclient'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-p2jm-6hj6-9rjg",
  "modified" : "2026-10-08T16:49:59Z",
  "published" : "2026-10-08T16:49:59Z",
  "aliases" : [ "CVE-2026-107226" ],
  "summary" : "AsyncHttpClient: Cookies received over plaintext HTTP can plant, overwrite or delete Secure cookies set over HTTPS",
  "details" : "### Impact\nThe 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.\n\nSo 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:\n\n```\nhttp://example.com   ->  Set-Cookie: SID=attacker-value; Secure; Path=/\nhttps://example.com  ->  Cookie: SID=attacker-value\n```\n\nThis 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:\n\n```\nhttp://insecure.example.com  ->  Set-Cookie: SID=attacker-value; Secure; Domain=example.com; Path=/\nhttps://bank.example.com     ->  Cookie: SID=attacker-value\n```\n\nA 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.\n\n### Affected versions\n* 3.x: up to and including 3.0.13\n* 2.x: from 2.1.0, when the cookie store was introduced, up to and including 2.16.1\n\n### Patches\nFixed 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.\n\nWhen 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.\n\nPlaintext 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.\n\nThe 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14.\n\n### Workarounds\nDo 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.\n\n### Details\n`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.\n\nA 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.\n\nThe 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.\n\n### Attribution\n\nAI-assisted tools were used to support discovery and analysis.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Maven",
      "name" : "org.asynchttpclient:async-http-client"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "3.0.0"
      }, {
        "fixed" : "3.0.14"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 3.0.13"
    }
  }, {
    "package" : {
      "ecosystem" : "Maven",
      "name" : "org.asynchttpclient:async-http-client"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "2.1.0"
      }, {
        "last_affected" : "2.16.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/AsyncHttpClient/async-http-client/security/advisories/GHSA-p2jm-6hj6-9rjg"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/AsyncHttpClient/async-http-client/commit/6ec7ee45034d154f502852a962d2891746fb82c1"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/AsyncHttpClient/async-http-client"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/AsyncHttpClient/async-http-client/releases/tag/async-http-client-project-3.0.14"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-384", "CWE-693" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-10-08T16:49:59Z",
    "nvd_published_at" : null
  }
}