The security product I’m developing can fully intercept and block this vulnerability! This is something I’m incredibly proud of.

Was My Uploaded File Tampered With? Data Leaked?

Have you heard about CVE-2025–24813, the vulnerability affecting Apache Tomcat?

Oh, and it’s not just any vulnerability — it can lead to remote code execution (RCE) and data leaks. This is not something you can afford to ignore — absolutely not, especially when you realize just how many servers depend on Tomcat. It’s scary to think about, right?

As someone who develops security products, I couldn’t resist analyzing this vulnerability, and of course, I’ll be sharing everything with you.

But beyond that, there’s something even more exciting — I’ve been developing a security product, and it can fully intercept this vulnerability. Yes, you heard that right. The product I’m building is designed to block the majority of security threats targeting Java-based applications. This is a huge milestone, and I couldn’t be more thrilled to share it with you.

Now, let’s take a look at the vulnerability details captured by my product. But first, let’s get back to today’s topic.

Today, we’re skipping the basics and diving straight into the core of this vulnerability — what it tells us about the bigger picture of cybersecurity. Sounds like a plan? Let’s get into it.

Imagine this:

You’re uploading a large file to a server. Because it’s so big, your browser splits it into smaller chunks to send it more efficiently. Makes sense, right?

These chunks are known as Partial PUT requests.

Now, here’s the problem — how does Tomcat handle these chunks?

Tomcat creates temporary files using the user-provided filenames. Sounds risky? It is.

This small detail opened the door to a massive security vulnerability.

So, how can an attacker actually use this to break into a system or steal data?

There are a few ways:

Information Leakage & Corruption
Let’s say an attacker knows the name of a sensitive file that’s being uploaded. If certain conditions are met — like if the server allows access to default Servlets — they could view or even modify these sensitive files. That’s bad news.

But that’s not all — Remote Code Execution (RCE) is even worse.

And this is where things get really tricky…

For this exploit to work, a few conditions need to be met:
1. Certain permissions need to be enabled.
2. The server must allow Partial PUT pre-requests.
3. The application must use file-based session persistence.

What’s session persistence? It’s how the server remembers your session information while you browse — storing it in files.

Now, if an attacker manipulates these session files, they could hijack an entire session.

And if the application is using a library vulnerable to deserialization attacks… game over.

At this point, the attacker could completely take over the server.

Sounds bad? It gets worse. Partial PUT requests are enabled by default in vulnerable versions of Tomcat. This is practically leaving the door wide open for attackers.

Looking at the patch for this vulnerability, we see changes in how the executePartialPut function handles uploaded filenames.

Before the fix:
The function replaced / with . in the file path before saving the uploaded data.

How it’s triggered:

• The function is called within DefaultServlet#doPut.
• The readOnly property must be set to false (meaning PUT is enabled).
• The parseContentRange function must return a non-empty value.

By default, files uploaded via PUT are stored in /work/Catalina/localhost/ROOT, but slashes (/) are replaced with dots (.).

Now, here’s where things get really dangerous…

Let’s go back to a previous vulnerability — CVE-2020–9484, a deserialization exploit in Tomcat’s session persistence mechanism.

Here’s how it works:

1. If Tomcat is configured to use file-based session persistence, it stores session data in files inside /work/Catalina/localhost/ROOT/.
2. When a JSESSIONID is parsed, Tomcat calls FileStore#load, which deserializes the session file.
3. If an attacker can upload a .session file via a PUT request, they might be able to trigger deserialization and execute arbitrary code.
4. Combine this with a known serialization gadget in the classpath (e.g., Commons Collections 3.2.1), and you’ve got full RCE.

Brilliant exploitation method? Yes.
Easy to pull off? Not really.

Despite how dangerous this vulnerability is, exploiting it in the wild isn’t straightforward.

Here’s why:

1. DefaultServlet must have PUT enabled (readOnly=false). This is not a default setting.
2. Tomcat must be using file-based session persistence. Again, not a default configuration (similar to CVE-2020–9484).
3. A vulnerable deserialization gadget must exist in the classpath.

So, is this a massive security threat? Yes. But is every Tomcat server at risk?
Not necessarily.

First things first — check your Apache Tomcat version.

The affected versions are:

• Apache Tomcat 11.0.0-M1 to 11.0.2
• Apache Tomcat 10.1.0-M1 to 10.1.2
• Apache Tomcat 9.0.0 and older

If you’re running any of these versions… Update. Right now.

Patches have been released, and you need to update immediately.

Beyond just patching, this vulnerability reveals a bigger issue in cybersecurity:

Software complexity is a major risk.
Even the smallest coding mistakes can lead to huge security consequences.

Security configurations matter.
Many servers were vulnerable simply because Partial PUT was enabled — even when it wasn’t necessary. Reducing attack surfaces is critical.

Security auditing and testing are more important than ever.
If thorough security reviews were done earlier, this vulnerability could have been caught before reaching production.

Just building software isn’t enough — you have to build it securely from day one.

END

Thank you for reading! If you’d like a more in-depth look, you can check out the YouTube video I posted yesterday — the visual format makes everything more intuitive and clear.

Disclaimer:The information provided in this article is for educational and informational purposes only. Any consequences or damages resulting from the use, distribution, or exploitation of the content presented here are solely the responsibility of the user. The author of this article assumes no liability for any direct or indirect impact caused by the information shared. Use this knowledge responsibly.