CVE-2023-42795 is a security vulnerability found in multiple versions of Apache Tomcat. It's classified as an "Incomplete Cleanup" issue, potentially allowing sensitive information leakage from one HTTP request/response cycle into the next. In this long read, you’ll learn how the vulnerability works, see some practical code snippets, explore how it can be exploited, and get links to further information.

What is CVE-2023-42795?

Apache Tomcat is a widely used open-source Java servlet container that powers countless web applications worldwide. Starting from version 8.5., an internal error affected how Tomcat recycled certain internal objects such as the request/response processor. Due to this incomplete cleanup, information from one request could unintentionally become visible to another, unrelated request.

How Does the Vulnerability Work?

Tomcat tries to improve performance by pooling and reusing objects such as Request and Response processors. Usually, before reusing an object, Tomcat “recycles” it—that is, resets or wipes its state clean. Due to a code bug, certain error conditions could cause parts of this recycle process to be skipped.

New requests, assigned to these recycled objects, may see this leftover data

This is a classic case of an information leak. Under heavy load or with unusual client disconnects, the risk for data crossover increases.

Exploiting CVE-2023-42795 — How Would an Attacker Abuse It?

While this vulnerability doesn't provide full access to the server, in certain conditions, one user may see another user's data. Imagine a shared hosting environment or a multi-tenant cloud service—this can have severe privacy consequences.

Below is a simplified example inspired by Tomcat's object recycling logic

public class Response {
    StringBuilder body = new StringBuilder();

    public void recycle() {
        // Incomplete cleanup!
        if (someCondition) {
            // Skips clearing body in edge case
            return;
        }
        body.setLength(); // Should clear the body content
    }
}

If someCondition (e.g., a rare error when handling the socket) is true, the recycle() method skips wiping the body, leaving previous data to be sent to the next user.

Proof-of-Concept: Simulating the Flaw

Suppose you make two HTTP requests in quick succession. The first request triggers an error condition—perhaps by abruptly closing the connection. The second request, if it gets the same processor, could see the previous "body" string.

Request 1 — Sends secret data

curl --header "Secret: MyToken123" http://your-tomcat-server/someapi -d "private_value=abcdef"

Request 2 — A different client requests the same resource.

Depending on timing and server load, some headers or response data from request #1 could (leak) appear in request #2.

If using Tomcat 9.x with Docker, update your Dockerfile

FROM tomcat:9..81-jdk17
# (rest of your setup)

Or download the latest binaries from the official Tomcat download page.

Upgrade: Always keep Tomcat up to date

- Isolate Tenants: Don’t share Tomcat instances between customers/users if you can’t upgrade immediately

Monitor for Unusual Behavior: Use log monitoring to catch strange responses

- Clear Caches: Custom servlets/filters should clear request attributes and sensitive data after use

Tomcat Security Advisory:

https://tomcat.apache.org/security-11.html#Fixed_in_Apache_Tomcat_11..-M12
https://nvd.nist.gov/vuln/detail/CVE-2023-42795

Project Release Notes:

https://tomcat.apache.org/tomcat-11.-doc/changelog.html

NIST National Vulnerability Database:

https://nvd.nist.gov/vuln/detail/CVE-2023-42795

https://github.com/apache/tomcat/commit/c2818e2ac9ec5e3b1b453097c99e7bdc65852d8

Conclusion

CVE-2023-42795 is a subtle but serious “incomplete cleanup” flaw affecting several Tomcat versions. Even though it doesn’t let attackers take control directly, accidental data crossover between sessions can have big privacy and business implications, especially on shared servers. Upgrade as soon as possible to stay safe.

If you're running a public or multi-user Tomcat instance, patch now and regularly review security advisories for similar issues!

Timeline

Published on: 10/10/2023 18:15:18 UTC
Last modified on: 11/04/2023 06:15:51 UTC