How severe is GHSA-2jwh-9rmr-j4xf?

GHSA-2jwh-9rmr-j4xf has a CVSS score of 6.8/10, rated MEDIUM. Review your exposure and patch according to your risk tolerance.

Which packages are affected by GHSA-2jwh-9rmr-j4xf?

GHSA-2jwh-9rmr-j4xf affects the following packages: org.asynchttpclient:async-http-client (Maven), org.asynchttpclient:async-http-client (Maven). Ecosystems affected: Maven.

How do I fix GHSA-2jwh-9rmr-j4xf?

Update org.asynchttpclient:async-http-client to 3.0.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2jwh-9rmr-j4xf is resolved across your whole dependency graph.

How do I detect GHSA-2jwh-9rmr-j4xf in my Maven dependencies?

Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.asynchttpclient:async-http-client, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

How do I mitigate GHSA-2jwh-9rmr-j4xf if there is no patch (or I can't update yet)?

Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Is GHSA-2jwh-9rmr-j4xf actively exploited in the wild?

No public exploit code has been indexed for GHSA-2jwh-9rmr-j4xf yet. This does not mean the vulnerability cannot be exploited — absence of public exploits does not imply safety. Apply the recommended fix and use O3 Security to monitor your exposure.

What is the EPSS score for GHSA-2jwh-9rmr-j4xf?

GHSA-2jwh-9rmr-j4xf has an EPSS (Exploit Prediction Scoring System) score of 0.3%, placing it in the 22th percentile of all CVEs. EPSS is maintained by FIRST.org and estimates the probability that a vulnerability will be exploited in the wild within the next 30 days. This score indicates relatively lower exploitation probability, though the CVSS severity should still guide your patching priority.

What type of vulnerability is GHSA-2jwh-9rmr-j4xf?

GHSA-2jwh-9rmr-j4xf is classified as Improper Authentication (CWE-287). This weakness type describe the underlying flaw category, which helps determine the potential impact and the right class of mitigation.

When was GHSA-2jwh-9rmr-j4xf published, and has it been updated?

GHSA-2jwh-9rmr-j4xf was published on October 8, 2026 and was last updated on October 8, 2026. Advisory data evolves as severity scores, affected ranges, and exploit intelligence are revised — always check the latest version of the advisory before acting.

☕

☕ Maven

Not in CISA KEV

MEDIUM severity

AsyncHttpClient CookieStore Silently Overrides Caller's Explicit Cookie Header via setHeader (Bypass of CVE-2024-53990 Fix)GHSA-2jwh-9rmr-j4xf

MEDIUMFix: AsyncHttpClient/async-http-client@fd97636

GHSA-2jwh-9rmr-j4xf is a medium-severity (CVSS 6.8) Improper Authentication vulnerability in org.asynchttpclient:async-http-client. A fix is available for org.asynchttpclient:async-http-client — see the affected versions and patch details below.

Also known asCVE-2026-107228

Published

Oct 8, 2026

Updated

Oct 8, 2026

Affected

2 pkgs

Patched

1 / 2

Exploits

None indexed

Exploitation data as of Oct 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

A successful exploit gives an attacker total control of the affected component, not partial access.
CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-2jwh-9rmr-j4xf.

EPSS Exploitation Probability

via FIRST.org ↗

0.3%probability of exploitation in next 30 days

Lower Risk0.00%

Lower risk than most CVEs22th percentile — riskier than 22% of all scored CVEsHighest risk

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

GHSA-2jwh-9rmr-j4xf by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,415 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

2 pkgs affected

☕org.asynchttpclient:async-http-client☕org.asynchttpclient:async-http-client

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

Impact

With the cookie store enabled, which is the default, a Cookie header that the caller sets on a request with setHeader or addHeader is thrown away whenever the store holds any cookie for the request's origin: the request's cookie list is written into that header afterwards and replaces it. CVE-2024-53990 fixed the same problem for cookies added with addCookie, but that fix works on the cookie list, and a header set directly never reaches it.

This is not limited to a cookie of the same name. A store cookie of any name erases the caller's header, so a request meant to carry the caller's session cookie goes out with only the store's cookies, and where the store has a cookie of the caller's name, the store's value is sent instead.

It matters most where one client acts for several users. An application that puts each user's session on the request itself, and shares one client and its default cookie store, sends one user's request with a session cookie the store took from a response to another user. The request runs as that other user, so a user of such an application can have their request served under someone else's session, or someone else's under theirs.

Affected versions

3.x: up to and including 3.0.13
2.x: from 2.1.0 up to and including 2.16.1

Patches

Fixed in 3.0.14. The store's cookies are added to a caller's Cookie header instead of replacing it, and where both name the same cookie the caller's is kept. The caller's text is kept as written, and several Cookie headers are folded into one, as RFC 6265 Section 5.4 requires.

The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14.

Workarounds

Where requests carry per-user cookies, use a separate client per user, or disable the cookie store with setCookieStore(null).

References

Incomplete fix of CVE-2024-53990 (GHSA-mfj5-cf8g-g2fv). Reported by @1diot9.

Attribution

AI-assisted tools were used to support discovery and analysis.

Affected Packages

2 total 1 fixed

Ecosystem	Package	Vulnerable range	Fix
☕Maven	`org.asynchttpclient:async-http-client`	≥ 3.0.0&&< 3.0.14	3.0.14`org.asynchttpclient:async-http-client:3.0.14`
☕Maven	`org.asynchttpclient:async-http-client`	≥ 2.1.0	No fix

Detection & mitigation playbook

Open-source dependency

Detect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.asynchttpclient:async-http-client, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.asynchttpclient:async-http-client to 3.0.14 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-2jwh-9rmr-j4xf is resolved across your whole dependency graph.
Workarounds
Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used.

Frequently Asked Questions

### Impact With the cookie store enabled, which is the default, a `Cookie` header that the caller sets on a request with `setHeader` or `addHeader` is thrown away whenever the store holds any cookie for the request's origin: the request's cookie list is written into that header afterwards and replaces it. CVE-2024-53990 fixed the same problem for cookies added with `addCookie`, but that fix works on the cookie list, and a header set directly never reaches it. This is not limited to a cookie of the same name. A store cookie of any name erases the caller's header, so a request meant to carry t