When it comes to Apache Tomcat, the world’s most popular Java application server, security bugs can have far-reaching effects. CVE-2022-23181 is one such bug—a time-of-check, time-of-use (TOCTOU) race condition that quietly slid into Tomcat versions during a previous attempt to fix another vulnerability (CVE-202-9484). If you’re running Tomcat 8.5.55 to 8.5.73, 9..35 to 9..56, 10..-M5 to 10..14, or 10.1.-M1 to 10.1.-M8, and you’re persisting sessions using FileStore, you may be at risk. Let’s see why—using straightforward language, code snippets, exploit details, and practical links.

Quick Intro to the Bug

CVE-2022-23181  
After fixing CVE-202-9484 (which was about how the session persistence mechanism could allow deserialization of arbitrary data), the Tomcat developers introduced checks in the FileStore session manager—meant to be more secure. But, the way these checks were implemented led to a TOCTOU problem. This means that between the time when Tomcat *checks* what a file is, and when it *uses* the file (like reading from it), an attacker with local access could swap out the file, causing Tomcat to act on something different than what it thought it had checked.

If the Tomcat process is running with higher privileges (like root or a specialized user), this could allow local users or attackers to read or modify session data, escalate privileges, or perform other malicious actions—depending on what the Tomcat process is allowed to do.

10.1.-M1 → 10.1.-M8

Only affected *if you use session persistence with FileStore* (not JDBC or Memory).

Session Persistence Using FileStore

When Tomcat saves HTTP sessions to disk, the FileStore mechanism writes Java-style serialized files into a session directory:

work/Catalina/localhost/yourapp/sessions/SESSION_ID.session

After CVE-202-9484, Tomcat added a check to ensure that session files belong to the Tomcat process and aren’t manipulated to point to something malicious. However, this check introduced a gap: After checking the file’s permissions (ownership, path, etc.), Tomcat would go on to actually *open* the file—without re-checking it. If an attacker was quick (or cunning), they could swap in a symlink or different file between the check and the use.

Here’s a high-level illustration, not the actual Tomcat source but enough to understand

File sessionFile = new File(dir, sessionId + ".session");

// Step 1: Check the file is a real session file
if (!isExpectedSessionFile(sessionFile)) {
    throw new SecurityException("Unexpected session file");
}

// ...attacker swaps symlink here...

// Step 2: Load the session data
try (ObjectInputStream ois = new ObjectInputStream(new FileInputStream(sessionFile))) {
    Session session = (Session) ois.readObject();
    // ... use session ...
}


> *Between the check and the file open, an attacker could swap, symlink, or replace sessionFile to point to sensitive files or their own malicious content.*

The Attack Scenario

1. Attacker must have local access: This isn’t a remote code execution bug, but many multi-user production systems run Tomcat as a non-root but privileged user.
2. Attacker observes Tomcat saving/loading sessions: Ideally, by writing code that triggers session saving frequently (like repeated logins/logouts).
3. Race condition exploitation: Between the check and file open (usually mere microseconds apart), the attacker must swap the session file with a symlink or malicious file.

Practical Exploit Example: Pointing to Sensitive Files

Suppose the attacker creates a symlink from /path/to/sessions/attacker.session to /etc/passwd. When Tomcat proceeds to open and read the “session” file, it ends up reading /etc/passwd as if it was valid session data.

Example Steps

# Attacker script creates and swaps symlink rapidly
while true; do
    ln -sf /etc/passwd /path/to/tomcat/sessions/attacker.session
    # Quickly swap back to legit file to evade detection
done


Meanwhile, attacker’s code (running in or outside of Tomcat) tries to access their session file at the right moment. If timed perfectly, Tomcat leaks the contents of /etc/passwd as session attributes.

10.1.-M10 and later

Or, disable FileStore and use Memory or JDBC session persistence if possible.

> Note: You should also run Tomcat as an unprivileged dedicated user (never as root) for defense-in-depth.

Original CVE Report:

https://nvd.nist.gov/vuln/detail/CVE-2022-23181

Tomcat Security Advisory:

https://tomcat.apache.org/security-10.html#Fixed_in_Apache_Tomcat_10.1.-M10  
 https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9..58  
 https://tomcat.apache.org/security-8.html#Fixed_in_Apache_Tomcat_8.5.74

Tomcat FileStore Source:

FileStoreManager.java (GitHub)

Summary and Takeaway

CVE-2022-23181 is the classic story of security fixes causing unexpected new problems. It’s a rare critical bug—because you need local access and the right configuration—but if you meet those conditions, the window for abuse is real and very dangerous. Always use the latest stable Tomcat, don’t run it as root, and keep an eye out for how your session data is persisted.

Have questions or want advice on locking down your Tomcat? Post below or check the official Tomcat docs!

Timeline

Published on: 01/27/2022 13:15:00 UTC
Last modified on: 07/30/2022 02:02:00 UTC