CVE-2023-42794 is an incomplete-cleanup denial-of-service vulnerability in Apache Tomcat, where the internal fork of Commons FileUpload bundled with certain 8.5 and 9.0 releases contained an unreleased, in-progress refactoring that, on Windows, could leave uploaded temporary files on disk if a web application opened a stream for an uploaded file but never closed it. Over time those orphaned files fill the disk, and a full disk means denial of service. It is a control-plane issue only, with no data-plane exposure, and it is specific to Windows.
This is a good example of a vulnerability that is entirely undramatic in mechanism yet perfectly capable of taking a service down. There is no injection, no memory corruption, no bypass, just files that should have been deleted and were not.
What went wrong
Tomcat ships its own internal fork of Apache Commons FileUpload to handle multipart form uploads. In the affected releases, that fork included refactoring work that had not been finished or officially released upstream. The incomplete state introduced a resource-management gap: when a web application opened a stream over an uploaded file part and then failed to close that stream, the temporary file backing the upload was never deleted.
Normally the container cleans up upload temp files once the request is done. The refactoring broke that guarantee on Windows specifically, where file-locking and deletion semantics differ from Unix. An open handle to a file on Windows prevents its deletion in ways that do not apply the same way on Linux, which is why the platform matters here.
The attack, such as it is
There is no clever payload. An attacker (or even normal traffic against a vulnerable app that leaks streams) repeatedly uploads files. Each upload that hits the buggy path leaves a temporary file behind. Repeat enough times and the temporary directory's disk fills up. Once the disk is full, Tomcat cannot write new temp files, logs, or session data, and the service degrades or stops. That is the denial of service.
Because the trigger is "upload files and let the count grow," the practical severity depends on how exposed your upload endpoints are and whether the affected application actually leaks the stream. But you should not rely on your own code being careful, because the whole point of the CVE is that the container should have cleaned up regardless.
Affected versions
Verified against the NVD record and the Apache Tomcat security pages:
Affected: Apache Tomcat 9.0.70 – 9.0.80
Apache Tomcat 8.5.85 – 8.5.93
Fixed in: 9.0.81
8.5.94
Platform: Windows only
Impact: Denial of service via disk exhaustion
(control plane only, no data plane exposure)
Reported: 2023-09-01
Public: 2023-10-10
Note the tight version window. This was not present in older 8.5 or 9.0 releases; the vulnerable refactoring was introduced in the 9.0.70 and 8.5.85 builds and removed again in 9.0.81 and 8.5.94. If you are on an earlier or later release in those series, you are outside the affected range for this specific CVE.
Remediation
Upgrade Tomcat. Move to 9.0.81 or later on the 9.0 line, or 8.5.94 or later on the 8.5 line. The fix removes the incomplete refactoring so upload temp files are cleaned up correctly again.
9.0.70 – 9.0.80 -> upgrade to 9.0.81+
8.5.85 – 8.5.93 -> upgrade to 8.5.94+
If you cannot upgrade immediately, mitigations reduce the exposure without closing the bug:
- Audit your web applications for any code that opens a stream over an uploaded file part and ensure the stream is always closed, ideally with try-with-resources so it closes even on an exception path.
- Monitor free space on the volume backing Tomcat's temp directory and alert before it fills, so disk exhaustion does not arrive as a surprise outage.
- On Windows specifically, consider constraining upload sizes and rates on exposed endpoints as a rate-limit on how fast the temp directory can grow.
These are stopgaps. The version upgrade is the fix, and the version window is narrow enough that most teams can simply step to the next patch release.
Finding it across your fleet
Tomcat is frequently embedded rather than run standalone, as spring-boot-starter-tomcat, inside application servers, or baked into vendor appliances. That makes manual inventory error-prone. Check the packaged version directly:
# standalone
sh $CATALINA_HOME/bin/version.sh | grep "Server number"
# embedded via Maven
mvn dependency:tree -Dincludes=org.apache.tomcat.embed
An SCA tool that reads your build manifests will flag the affected org.apache.tomcat coordinates across every service, including the embedded copies that hide inside Spring Boot starters, so you find the vulnerable window without grepping each project by hand.
FAQ
Is CVE-2023-42794 exploitable on Linux?
No. It is Windows-specific. The bug depends on Windows file-deletion semantics where an open handle prevents deletion, so Linux and other Unix-like platforms are not affected by this CVE.
What is the impact?
Denial of service through disk exhaustion. Undeleted upload temp files accumulate until the disk fills, at which point Tomcat can no longer function. Apache describes it as a control-plane-only issue with no data-plane exposure.
Which Tomcat versions fix it?
9.0.81 and later on the 9.0 line, and 8.5.94 and later on the 8.5 line. The affected window is 9.0.70 through 9.0.80 and 8.5.85 through 8.5.93.
I run Tomcat embedded in Spring Boot. Am I affected?
Possibly. Spring Boot bundles Tomcat via spring-boot-starter-tomcat, so check the embedded Tomcat version with mvn dependency:tree -Dincludes=org.apache.tomcat.embed. If it falls in the affected range and you deploy on Windows, upgrade the starter to pull a fixed Tomcat.