GHSA-mfj5-cf8g-g2fv
Fix: AsyncHttpClient/async-http-client#2033GHSA-mfj5-cf8g-g2fv is a Improper Authentication vulnerability in org.asynchttpclient:async-http-client. O3 Security confirms whether GHSA-mfj5-cf8g-g2fv is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
AsyncHttpClient (AHC) library's `CookieStore` replaces explicitly defined `Cookie`s
Real-World Exposure
org.asynchttpclient:async-http-client☕org.asynchttpclient:async-http-clientReal-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
Summary
When making any HTTP request, the automatically enabled and self-managed CookieStore (aka cookie jar) will silently replace explicitly defined Cookies with any that have the same name from the cookie jar. For services that operate with multiple users, this can result in one user's Cookie being used for another user's requests.
Details
This issue is described without security warnings here:
https://github.com/AsyncHttpClient/async-http-client/issues/1964
A PR to fix this issue has been made:
https://github.com/AsyncHttpClient/async-http-client/pull/2033
PoC
- Add an auth
Cookieto theCookieStore- This is identical to receiving an HTTP response that uses
Set-Cookie, as shown in issue #1964 above.
- This is identical to receiving an HTTP response that uses
- Handle a different user's request where the same
Cookieis provided as a passthrough, like a JWT, and attempt to use it by explicitly providing it. - Observe that the user's cookie in step 2 is passed as the Cookie in step 1.
Impact
This is generally going to be a problem for developers of backend services that implement third party auth features and use other features like token refresh. The moment a third party service responds by setting a cookie in the response, the CookieStore will effectively break almost every follow-up request (hopefully by being rejected, but possibly by revealing a different user's information).
If your service sets cookies based on the response that happens here, it's possible to lead to even greater levels of exposure.
Workaroud
You can avoid this issue by disabling the CookieStore during client creation:
DefaultAsyncHttpClientConfig.Builder clientBuilder = Dsl.config()
.setCookieStore(null)
// other configuration
;
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.asynchttpclient:async-http-client | ≥ 2.1.0&&< 2.12.4 | 2.12.4 |
| ☕Maven | org.asynchttpclient:async-http-client | ≥ 3.0.0.Beta1&&< 3.0.1 | 3.0.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.asynchttpclient:async-http-client. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update org.asynchttpclient:async-http-client to 2.12.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mfj5-cf8g-g2fv is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-mfj5-cf8g-g2fv is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-mfj5-cf8g-g2fv. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-mfj5-cf8g-g2fv in your dependencies?
O3 detects GHSA-mfj5-cf8g-g2fv across Maven dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.