CVE-2024-52317 - How Apache Tomcat's HTTP/2 Request Recycling Led to User Data Leaks

CVE-2024-52317 is a new critical vulnerability discovered in Apache Tomcat, specifically involving incorrect recycling and reuse of request and response objects when using HTTP/2 connections. This flaw opens the door for mixing up request and response data between users—potentially leading to data leakage. If you’re running Tomcat, this is one you can’t ignore. In this post, we’ll dig into how it happens, why it matters, and exactly what you should do next.

What Is the Issue?

Apache Tomcat is widely used for running Java web applications. Like any high-performance server, Tomcat tries to reuse objects as much as possible to save resources—this is sometimes called “object pooling”.

But in HTTP/2—where many requests can happen at once (multiplexed) using a single connection—Tomcat’s object recycling logic had a flaw. In certain situations, a recycled HTTP/2 request or response object could accidentally be used by the wrong user. This could cause parts of one user’s response to be sent to another user, or even let a request from one user be served data from another’s session. Yikes!

CVE ID: CVE-2024-52317

- Type: Object re-use/recycling, Privileged Information Disclosure

9..96

- Severity: High (request/response mix-ups!)

Technical Details: How Does It Happen?

Every time a browser or client makes a request, Tomcat constructs HttpServletRequest and HttpServletResponse objects to handle data. To go faster, Tomcat reuses these objects wherever it can.

With HTTP/1.1, it’s easy: one request per connection. But with HTTP/2, multiple users can have ongoing requests through the same TCP connection (thanks to multiplexing). If Tomcat mixes things up—say, reuses a HttpServletResponse from a previous user before it’s fully clean—you get responses being sent to the wrong person.

Example Code Snippet: (simplified for clarity!)

// Vulnerable pattern (oversimplified for explanation)
Request req = requestPool.get(); // grab recycled request
Response res = responsePool.get(); // grab recycled response

// ...problem: old data wasn't fully cleared, and can end up being populated across parallel streams...

Suppose User A requests /profile, and User B requests /settings, both over HTTP/2 on the same TCP connection. If Tomcat does not *fully sanitize* the objects before giving them to the next incoming request, User A may see User B’s data, or vice versa.

Is There a Working Exploit?

While there is no public, weaponized exploit as of June 2024, here's how an attacker *could* exploit it:

Multiple Users + Same Connection:

Multiple users (or tabs) from the same client IP access the server over HTTP/2.

Observe Cross-Request Data Leakage:

By carefully timing and observing responses, the attacker may receive data intended for another request—possibly another user.

Proof-of-Concept Scenario:
Here's a conceptual Python snippet (using HTTP/2) showing repeated requests that could trigger the bug in a vulnerable Tomcat version:

import httpx

client = httpx.Client(http2=True)

# Simulate multiple users on the same connection
for i in range(100):
    response = client.get('https://vulnerable-tomcat.example.com/profile';)
    print(f"Response {i}: {response.text}")
# Look for content from OTHER users or requests mixed in your responses

Why Does It Matter?

If you’re running a web app with sensitive data—say, a bank, email, or corporate portal—this flaw could let an attacker see someone else’s info. Even with no special privileges, data gets mixed up just by using HTTP/2. That means your users could leak or receive cross-session data, violating confidentiality and security.

In summary:

Apache Tomcat Security Advisory:

https://tomcat.apache.org/security-11.html#Fixed_in_Apache_Tomcat_11..
https://tomcat.apache.org/security-10.html#Fixed_in_Apache_Tomcat_10.1.31
https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9..96

CVE Record:

https://nvd.nist.gov/vuln/detail/CVE-2024-52317

Public Discussion:

https://markmail.org/message/1be1dw3klcs6s3z

What Should You Do?

Upgrade immediately:

For most, this means updating a line in your Dockerfile or build script, e.g.

FROM tomcat:9..96-jdk17-temporal

Or:

# For hand installs (Linux)
wget https://archive.apache.org/dist/tomcat/tomcat-9/v9..96/bin/apache-tomcat-9..96.tar.gz
tar -xzvf apache-tomcat-9..96.tar.gz
# Replace your old Tomcat directory with the new one

Final Thoughts

CVE-2024-52317 is a textbook example of how parallel processing (like HTTP/2 multiplexing) changes the security game. Old object pooling tricks can become dangerous if “who owns what” isn’t crystal clear. If you’re responsible for any Java web platform, patch your Tomcat now—leaking even one user’s data is one too many.

If you want help with upgrading or verifying your patch, check out the official Tomcat docs or engage your security team.

Stay safe, and patch promptly!

*Did this help? Share with your devops and security teams. Questions? Drop them in the comments below!*

Timeline

Published on: 11/18/2024 12:15:18 UTC
Last modified on: 11/21/2024 09:46:16 UTC