CVE-2024-56337

What it actually does

This vulnerability is a time-of-check/time-of-use race condition in Apache Tomcat related to the incomplete mitigation for CVE-2024-50379. It affects Tomcat 11.0.0-M1 through 11.0.1, 10.1.0-M1 through 10.1.33, and 9.0.0.M1 through 9.0.97 when Tomcat is deployed on a case-insensitive file system and the default servlet is configured with write access enabled by setting the non-default readonly parameter to false. Under affected conditions, Java canonical path caching can allow Tomcat security checks to make decisions on stale or inconsistent path resolution results. An attacker who can write content through the default servlet may be able to win a race using path case variations and cause a server-side file, commonly a JSP, to be written and later executed, resulting in remote code execution in the context of the Tomcat process.

Why it matters to the business

Successful exploitation can allow an unauthenticated or low-privileged remote attacker, depending on application exposure and configuration, to place executable content on the web server and run commands with the privileges of the Tomcat service account. Business consequences may include web application takeover, data theft, credential compromise, service disruption, lateral movement from the application server, and deployment of web shells or malware. The issue is not currently listed in CISA KEV and the provided exploit maturity is none, but the EPSS value indicates non-trivial exploitation interest, and Tomcat vulnerabilities have been actively targeted in broader 2025 malware and vulnerability-trend reporting. Because the issue has been public for an extended period, internet-facing Tomcat systems with writable default servlet configurations should be treated as higher priority even without KEV status.

How an attack unfolds

An attacker first identifies a Tomcat instance running an affected version and determines whether the default servlet permits write operations, typically by probing for HTTP PUT behavior. The attacker then checks whether the deployment characteristics are favorable, especially a case-insensitive file system such as many Windows deployments and a Java runtime where sun.io.useCanonCaches remains enabled or improperly configured. The attacker repeatedly sends write requests using path and filename case variations to exploit the race between Tomcat's path validation and file use. If the race succeeds, attacker-controlled server-side content, often a JSP payload, is written into a web-accessible location. The attacker then requests the uploaded JSP or equivalent resource over HTTP, causing Tomcat to execute it. Post-exploitation activity commonly includes command execution, web shell staging, credential discovery, persistence, and attempts to move further into the environment.

How to fix it

Upgrade Apache Tomcat to a fixed release: Tomcat 11.0.3 or later, 10.1.35 or later, or 9.0.99 or later. For source-based deployments, the provided fixed Tomcat Git commit is 727a8467a37e17fef91e12a65db4d56862d36171. If immediate upgrade is not possible, disable write access in the default servlet by ensuring the readonly initialization parameter is not set to false; the safe default is readonly=true. On Java 8 and Java 11, explicitly set -Dsun.io.useCanonCaches=false. On Java 17, ensure sun.io.useCanonCaches is either unset or set to false. On Java 21 and later, the problematic cache has been removed, but upgrading Tomcat is still recommended because fixed Tomcat versions add configuration checks before allowing writable default servlet behavior on case-insensitive file systems. Restrict or block HTTP methods not required by the application, especially PUT, DELETE, and WebDAV-like write behavior. Review package inventory carefully because the supplied affected-product data includes a qemu Ubuntu 14.04 LTS package mapping that does not align with the Tomcat vulnerability description; validate vendor advisories before treating non-Tomcat package entries as applicable to this CVE.

How to confirm the fix worked

Confirm the running Tomcat version is 11.0.3 or later, 10.1.35 or later, or 9.0.99 or later. Review Tomcat configuration for the default servlet and verify readonly is absent or set to true; any readonly=false configuration should be considered exposed unless there is a specific compensating control and a fixed Tomcat version. Check JVM startup arguments and runtime properties for sun.io.useCanonCaches; Java 8 and Java 11 deployments should explicitly show false, Java 17 should not show true, and Java 21 or later removes the affected cache behavior. Confirm the host file system used for deployed web applications is not case-insensitive or, if it is, that all required Tomcat and Java mitigations are present. Perform a controlled validation in a non-production or approved test path to verify that HTTP PUT cannot create files in web-accessible directories and that attempts to upload JSP or server-executable content are rejected. Review access logs after remediation to confirm write methods are blocked or return expected denial status codes.

Typical attack path

1. Fingerprint exposed Apache Tomcat services and identify affected version ranges: 11.0.0-M1 through 11.0.1, 10.1.0-M1 through 10.1.33, or 9.0.0.M1 through 9.0.97.
2. Probe whether the default servlet accepts write methods such as PUT, indicating readonly=false or an equivalent unsafe configuration.
3. Determine or infer whether the server runs on a case-insensitive file system and a Java version/configuration where canonical path caching may be active.
4. Send repeated HTTP write requests using filename or path case variations to trigger the race condition.
5. Write attacker-controlled executable content, commonly a JSP file, into a web-accessible application directory.
6. Request the uploaded file to execute code under the Tomcat process identity.
7. Use the achieved execution path for web shell access, credential harvesting, persistence, data access, or lateral movement.

How to detect it

To determine whether exploitation already occurred, review Tomcat access logs, reverse proxy logs, WAF logs, endpoint telemetry, file integrity monitoring, and process creation records. Focus on HTTP PUT, DELETE, or unusual write-method requests to application paths, especially requests involving .jsp, mixed-case file extensions, encoded path separators, or repeated requests to the same filename with different casing. Look for subsequent GET or POST requests to newly created JSP files that were not part of normal deployments. On the host, inspect Tomcat web application directories for recently modified JSP, JSPX, class, WAR, or unexpected text files, particularly under webapps, webapps/ROOT, manager-deployed applications, and exploded application directories. Review Tomcat temporary and work directories for generated classes corresponding to suspicious JSP names. Endpoint detection should look for the Tomcat Java process spawning shells or system utilities such as cmd.exe, powershell.exe, sh, bash, curl, wget, certutil, whoami, id, net, or netstat. Correlate activity with known broader Tomcat exploitation campaigns and malware-trend reporting, but do not assume named threat-actor attribution without corroborating infrastructure, malware, or tradecraft evidence.

• readonly="false"
• readonly=false
• sun.io.useCanonCaches=true
• -Dsun.io.useCanonCaches=true
• PUT /
• DELETE /
• PUT /.jsp
• PUT .jsp
• PUT .JSP
• PUT .Jsp
• GET /.jsp
• POST /.jsp
• /webapps/ROOT/*.jsp
• /webapps/*/*.jsp
• /work/Catalina/localhost/
• org.apache.catalina.startup.Bootstrap
• java.exe -> cmd.exe
• java.exe -> powershell.exe
• java -> /bin/sh
• java -> /bin/bash
• cmd.exe /c whoami
• powershell.exe -enc
• curl http://
• wget http://
• certutil -urlcache

What your security team should do

• Prioritize internet-facing Tomcat instances and any Tomcat deployments on Windows or other case-insensitive file systems.
• Upgrade affected Tomcat branches to 11.0.3+, 10.1.35+, or 9.0.99+ as the preferred remediation.
• Immediately remove unsafe default servlet write access by changing readonly=false to readonly=true or removing the non-default setting.
• For Java 8 and Java 11, set -Dsun.io.useCanonCaches=false and restart Tomcat; for Java 17, verify it is not set to true.
• Block unnecessary HTTP write methods at the reverse proxy, load balancer, WAF, or application server layer, especially PUT and DELETE.
• Hunt for historical HTTP PUT requests, newly created JSP files, suspicious files in web application directories, and Tomcat child processes spawning operating-system shells.
• Treat signs of uploaded JSP execution or Tomcat-launched command interpreters as potential compromise and initiate incident response.
• Validate software inventory results because unrelated package mappings may appear in some vulnerability feeds; confirm applicability against Apache Tomcat vendor guidance.