CVE-2024-53990 - Critical Cookie Handling Flaw in AsyncHttpClient (AHC) Exposes User Data

A highly critical vulnerability, CVE-2024-53990, has been discovered in the popular Java HTTP networking library AsyncHttpClient (AHC). This bug can cause the library to silently substitute your app’s explicit cookie values with those stored in its internal cookie jar—even when you’ve set your own cookies for a request. In apps or services with multiple users, one user's authentication cookie might accidentally be used in another user's outgoing request, leading to account mix-ups or worse: user data leaks and privilege escalation.

This post explains how the bug works, why it’s dangerous, shows code snippets to demonstrate it, and provides resources and links for further reading.

What is AsyncHttpClient (AHC)?

AsyncHttpClient (AHC) is a widely-used open source Java library for making HTTP requests. It's known for its simplicity and performance, letting your code fire off HTTP calls asynchronously—that is, without waiting for slow network operations to finish before moving on.

One convenience feature it provides is automatic cookie management. By default, AHC maintains a cookie jar (officially known as CookieStore), which tracks cookies set on responses and attaches them to new requests based on the target domain.

CVE-2024-53990 Details

Vulnerable Version: All versions before the fix (check official repo for patched release)

Bug:
When you make a new HTTP request in AHC and explicitly set a cookie header, the library’s *automatic cookie management* will overwrite your value if its internal cookie jar has a cookie with the same name. This happens silently.

Consequence:
- In any app or backend service that handles multiple users (for example, a server making requests on behalf of users with different sessions), one user's cookie may be substituted for another's.
- This can lead to account confusion, unauthorized data access, or accidental privilege escalation.

Proof-of-Concept (PoC) Exploit

Suppose you have a simple web service that makes authenticated API calls on behalf of multiple logged-in users. When User A and User B are both using the service, the following scenario can happen:

import org.asynchttpclient.*;

public class AHC_Cookie_Exploit {
    public static void main(String[] args) throws Exception {
        AsyncHttpClient client = Dsl.asyncHttpClient();

        // User A logs in
        Request requestA = new RequestBuilder("GET")
            .setUrl("https://api.example.com/account";)
            .addHeader("Cookie", "session=AAA") // Explicitly set
            .build();

        // This response sets a Set-Cookie header (session=AAA), which is stored in AHC's cookie jar
        client.executeRequest(requestA).get();

        // Now User B logs in (different session)
        Request requestB = new RequestBuilder("GET")
            .setUrl("https://api.example.com/account";)
            .addHeader("Cookie", "session=BBB") // Explicitly set
            .build();

        // YOU WOULD EXPECT this request to use "session=BBB"
        client.executeRequest(requestB).get();

        // But in reality, due to CVE-2024-53990, if the cookie jar contains session=AAA,
        // AHC will silently replace "session=BBB" with "session=AAA"
        // User B's request now uses User A's authentication cookie!
    }
}

User A’s session cookie gets stored in the jar.

2. When User B tries to send their own session cookie, AHC replaces it with User A’s, because the cookie jar takes precedence for cookies of the same name.

Why Does This Happen?

- AHC's CookieStore is process-wide by default. If you don’t manually separate per-user cookies, the library *thinks* it’s doing you a favor by always using the latest value from the jar.
- Explicit cookies are overridden by the library’s own cookie jar (even though you, as the developer, tried to set a specific value).

Uses AsyncHttpClient’s default cookie management.

- Handles requests for multiple users (ex: HTTP proxies, API gateways, microservices, SSR backends).

One user views or modifies another's private data.

- Session swaps/privilege escalation via mixed-up cookies.

How to Fix

- Upgrade AHC: Check the official GitHub repo or CVE Database for a patched version.
- Workaround: Disable the automatic cookie jar as soon as you make a new client, or manage separate clients per user:

AsyncHttpClientConfig config = new DefaultAsyncHttpClientConfig.Builder()

.setCookieStore(null) // or your own per-user CookieStore

Original References

- AsyncHttpClient security issue - GitHub
- CVE-2024-53990 - NIST NVD
- AsyncHttpClient Docs
- Discussion on GitHub issue (if published)

Final Thoughts

If you use AsyncHttpClient in a context where you process requests on behalf of multiple users, you must ensure each user's cookies are managed separately or the cookie store is disabled. This is not just a “best practice” but essential for data security.

Double-check your dependencies, update immediately, and audit your cookie usage code!

*Stay safe, and keep your libraries updated! If this post helped, please share with developers who use Java HTTP clients.*


*Post written exclusively for Stack Knowledge Base in June 2024.*

Timeline

Published on: 12/02/2024 18:15:11 UTC