Like a bank vault with a broken lock, but only if the bank voluntarily removed the door first
CVE-2024-50379 and CVE-2024-56337 describe a TOCTOU (time-of-check time-of-use) race condition in Apache Tomcat's DefaultServlet that can lead to remote code execution. The flaw allows an attacker to concurrently upload and request the same file, bypassing Tomcat's case-sensitivity checks so that an uploaded file is treated as a JSP and executed server-side. Affected versions span 9.0.0.M1 through 9.0.97 (fixed in 9.0.98). The bundle also includes CVE-2024-54677, a low-severity DoS in the examples web application. Tenable plugin 213078 rolls all three into a single detection.
The NVD scored CVE-2024-50379 at CVSS 9.8 CRITICAL, and Tenable's plugin inherits that rating. This dramatically overstates real-world risk. The chain requires two non-default conditions simultaneously: (1) the DefaultServlet's readonly parameter must be set to false (default is true — almost nobody changes this), and (2) the Tomcat instance must run on a case-insensitive file system (Windows or macOS), while the vast majority of production Tomcat runs on Linux. The CVSS score models this as unauthenticated network RCE with no preconditions, which is flatly wrong. Apache themselves rated this Important, not Critical. The vendor severity label on this plugin is misleading for any enterprise running Tomcat on Linux with default settings — which is nearly all of them.
4 steps from start to impact.
Identify Tomcat with writable DefaultServlet
readonly=false in web.xml or conf/web.xml. This enables HTTP PUT uploads to the default servlet. This is a non-default, explicitly opted-in configuration that is almost never present in production deployments.- Tomcat instance is network-reachable
- DefaultServlet
readonlyparameter is set tofalse
- The default value of
readonlyistrue— administrators must deliberately change this - Enterprise deployment templates and hardening guides universally leave this at default
- Automated CIS benchmarks flag
readonly=falseas a misconfiguration
web.xml for readonly parameter value.Confirm case-insensitive file system
- Target OS uses a case-insensitive file system
- Practically: Windows or macOS, not Linux
- ~70-80% of production Tomcat deployments run on Linux
- macOS is not a typical production Tomcat platform
- Even Windows Tomcat deployments are a minority of the installed base
Race the upload and read
.jsp file (e.g., shell.JSP with uppercase extension) while simultaneously requesting the same file. The TOCTOU window allows the uploaded file to bypass case-sensitivity validation and be compiled as a JSP by Tomcat's Jasper engine. This is a probabilistic attack — it may require hundreds or thousands of attempts.- Network path allows PUT requests to the DefaultServlet
- Sufficient request volume to win the race condition
- Race conditions are inherently unreliable — success is probabilistic
- WAF or reverse proxy may block PUT requests to unexpected paths
- Rate limiting or request throttling reduces race window
Execute webshell
tomcat on Linux, SYSTEM or a service account on Windows). The attacker can now pivot, exfiltrate data, or escalate privileges depending on the host role.- Successful race condition exploitation in step 3
- Tomcat process has sufficient OS privileges for attacker objectives
- EDR on the host should detect webshell activity (process spawning from Java)
- Network segmentation limits lateral movement from a Tomcat host
- Application-layer monitoring can detect anomalous JSP compilation
The supporting signals.
| In-the-Wild Exploitation | No confirmed active exploitation campaigns. Not listed in CISA KEV as of September 2025. EPSS score suggests elevated *predicted* exploitation probability, but real-world conditions severely limit the exploitable population. |
|---|---|
| Proof-of-Concept | 10+ public PoC repositories on GitHub including SleepingBag945/CVE-2024-50379 (Go), iSee857/CVE-2024-50379-PoC (Python), ph0ebus/Tomcat-CVE-2024-50379-Poc (Go), and a Nuclei template. All require readonly=false + case-insensitive FS. |
| EPSS | CVE-2024-50379: 0.443 (98.7th percentile). CVE-2024-56337: 0.090 (95.0th percentile). CVE-2024-54677: not significant. The high EPSS reflects Tomcat's brand recognition and PoC availability, not actual exploitation volume. |
| CISA KEV | Not listed in CISA Known Exploited Vulnerabilities catalog. |
| CVSS Vector | CVE-2024-50379: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H — NVD scores this 9.8 assuming no preconditions. The vector ignores the non-default configuration requirements (readonly=false), which should raise Attack Complexity to High at minimum. |
| Affected Versions | Apache Tomcat 9.0.0.M1 through 9.0.97. Also affects Tomcat 10.1.0-M1 to 10.1.33 and 11.0.0-M1 to 11.0.1 (covered by separate Tenable plugins). |
| Fixed Version | Apache Tomcat 9.0.98 (released December 2024). CVE-2024-56337 notes that even after patching, Java 8/11 users must also set sun.io.useCanonCaches=false. |
| Exposure Data | Apache Tomcat is one of the most widely deployed Java application servers globally. However, instances with readonly=false are an extreme minority — this configuration is explicitly warned against in Apache's own documentation. |
| Disclosure Date | CVE-2024-50379: 2024-12-17. CVE-2024-56337: 2024-12-20. CVE-2024-54677: 2024-12-17. |
| Reporter | CVE-2024-50379 reported by Nacl, WHOAMI, Yemoli, and Ruozhi. CVE-2024-56337 identified by the Apache Tomcat security team as an incomplete fix follow-up. |
noisgate verdict.
The single most decisive factor is the non-default readonly=false configuration requirement — the DefaultServlet ships with readonly=true and virtually no production deployment changes this, reducing the exploitable population to near zero regardless of network exposure. The secondary narrowing from case-insensitive filesystem requirements (Windows-only in practice) compounds to make this a theoretical RCE that almost never lands in enterprise environments.
Why this verdict
- Non-default config gate: The
readonly=falsesetting on the DefaultServlet is explicitly warned against in Apache documentation and is not present in any standard deployment template, CIS benchmark, or vendor-recommended configuration. This single prerequisite eliminates >99% of the installed base from the exploitable population. - OS platform narrowing: The TOCTOU race requires a case-insensitive file system. Production Tomcat overwhelmingly runs on Linux (ext4/xfs, case-sensitive). This further narrows the already-tiny
readonly=falsepopulation to Windows-only deployments — a minority of a minority. - Race condition unreliability: Even when both prerequisites are met, exploitation requires winning a TOCTOU race via concurrent PUT and GET requests. This is probabilistic, detectable by WAFs and IDS, and adds operational friction for attackers.
- Role multiplier: Tomcat serves as middleware in many enterprise architectures including identity-adjacent applications, API gateways, and business-critical services. In high-value roles (e.g., Tomcat fronting an identity service, running on a Windows app tier), a successful chain would yield code execution with potentially significant blast radius. However, because the chain requires
readonly=false— a configuration that is effectively absent in hardened high-value deployments — the chain does not realistically succeed in these roles. The role multiplier does not raise the floor because the prerequisite configuration is not role-correlated; it is misconfiguration-correlated.
Why not higher?
Upgrading to HIGH or CRITICAL would require the attack chain to be viable against default or common configurations. The readonly=false prerequisite is so rare in production that even the high EPSS score (0.443) and abundant PoC availability do not translate to meaningful real-world risk. No KEV listing and no confirmed in-the-wild exploitation after 9+ months further supports that the theoretical severity is not materializing in practice.
Why not lower?
Dropping to LOW or IGNORE would understate the risk for the small population of Windows Tomcat instances that have deliberately enabled writable DefaultServlet. The PoC ecosystem is mature (10+ public exploits, Nuclei templates), and the EPSS percentile (98.7th) indicates elevated scanning activity. If an organization does have this misconfiguration, the impact is full RCE with no authentication required — that tail risk keeps this at MEDIUM rather than LOW.
What to do — in priority order.
- Audit and enforce
readonly=trueon all DefaultServlet configurations — Grep your Tomcat fleet'sweb.xmlandconf/web.xmlforreadonlyparameter set tofalse. If found, revert to default (true) immediately. This single action completely eliminates the attack surface for CVE-2024-50379 and CVE-2024-56337. No noisgate mitigation SLA applies at MEDIUM — go straight to the 365-day remediation window for the actual patch. - Remove the examples web application from production instances — Delete
$CATALINA_HOME/webapps/examples/on all production Tomcat instances. This eliminates CVE-2024-54677 entirely. This should already be standard hardening practice per CIS Apache Tomcat benchmarks. - Block HTTP PUT at the reverse proxy or WAF — If your architecture requires
readonly=false(extremely rare), configure your reverse proxy (nginx, Apache httpd, F5) or WAF to deny PUT requests to Tomcat's default servlet paths. This breaks the upload step of the attack chain. - Set
sun.io.useCanonCaches=falseon Java 8/11 Tomcat instances — Even after patching to 9.0.98, CVE-2024-56337 notes that Java 8 and 11 runtimes require this JVM flag to fully close the TOCTOU window. Add-Dsun.io.useCanonCaches=falseto your Tomcat JVM startup arguments. Java 21+ does not need this flag.
- Network segmentation alone — if the attacker is already inside the network and the Tomcat instance has
readonly=falseon Windows, segmentation doesn't prevent the race condition exploitation via direct HTTP access. - Version-only patching without JVM flag — upgrading to 9.0.98 on Java 8/11 without setting
sun.io.useCanonCaches=falseleaves CVE-2024-56337 exploitable per Apache's own advisory. - Linux filesystem hardening — if you're on Linux, you're already not vulnerable to this specific chain. Hardening the filesystem doesn't add protection because case-sensitivity is already the default.
Crowdsourced verification payload.
Run this script on each Tomcat host as any user with read access to the Tomcat installation directory. Example: bash check_tomcat_cve2024_50379.sh /opt/tomcat or bash check_tomcat_cve2024_50379.sh /usr/share/tomcat. No elevated privileges required.
#!/bin/bash
# check_tomcat_cve2024_50379.sh — noisgate verification for Tenable 213078
# Checks: Tomcat version, readonly setting, OS filesystem case sensitivity
# Usage: bash check_tomcat_cve2024_50379.sh <CATALINA_HOME>
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
CATALINA_HOME="${1:-}"
if [ -z "$CATALINA_HOME" ]; then
echo "Usage: $0 <CATALINA_HOME>"
exit 2
fi
# Detect Tomcat version
VERSION_FILE="$CATALINA_HOME/lib/catalina.jar"
if [ ! -f "$VERSION_FILE" ]; then
echo "UNKNOWN — cannot find catalina.jar at $CATALINA_HOME/lib/"
exit 2
fi
TOMCAT_VER=$(unzip -p "$VERSION_FILE" org/apache/catalina/util/ServerInfo.properties 2>/dev/null | grep 'server.number' | cut -d= -f2 | tr -d '[:space:]')
if [ -z "$TOMCAT_VER" ]; then
echo "UNKNOWN — cannot determine Tomcat version"
exit 2
fi
echo "Detected Tomcat version: $TOMCAT_VER"
# Compare version (need 9.0.98+)
MAJOR=$(echo "$TOMCAT_VER" | cut -d. -f1)
MINOR=$(echo "$TOMCAT_VER" | cut -d. -f2)
PATCH=$(echo "$TOMCAT_VER" | cut -d. -f3)
if [ "$MAJOR" -eq 9 ] && [ "$MINOR" -eq 0 ] && [ "$PATCH" -ge 98 ]; then
echo "PATCHED — Tomcat $TOMCAT_VER is >= 9.0.98"
exit 0
elif [ "$MAJOR" -gt 9 ]; then
echo "PATCHED — Tomcat $TOMCAT_VER is not in the 9.0.x affected range (check version-specific plugin)"
exit 0
elif [ "$MAJOR" -lt 9 ]; then
echo "UNKNOWN — Tomcat $TOMCAT_VER is not in the 9.0.x range covered by this plugin"
exit 2
fi
# Version is vulnerable (9.0.0-9.0.97). Check mitigating factors.
echo "Version $TOMCAT_VER is in vulnerable range (< 9.0.98)"
# Check readonly setting
READONLY_FALSE=0
for WEBXML in "$CATALINA_HOME/conf/web.xml" "$CATALINA_HOME/webapps/ROOT/WEB-INF/web.xml"; do
if [ -f "$WEBXML" ]; then
if grep -qi 'readonly' "$WEBXML" && grep -A2 -i 'readonly' "$WEBXML" | grep -qi 'false'; then
READONLY_FALSE=1
echo "WARNING: readonly=false found in $WEBXML"
fi
fi
done
# Check OS case sensitivity
CASE_INSENSITIVE=0
TMPFILE=$(mktemp "$CATALINA_HOME/.noisgate_case_XXXXXX" 2>/dev/null || mktemp /tmp/.noisgate_case_XXXXXX)
if [ -f "$(echo "$TMPFILE" | tr '[:lower:]' '[:upper:]')" ] 2>/dev/null; then
CASE_INSENSITIVE=1
echo "WARNING: Case-insensitive filesystem detected"
else
echo "OK: Case-sensitive filesystem (Linux) — race condition not exploitable"
fi
rm -f "$TMPFILE" 2>/dev/null
if [ "$READONLY_FALSE" -eq 1 ] && [ "$CASE_INSENSITIVE" -eq 1 ]; then
echo "VULNERABLE — Tomcat $TOMCAT_VER with readonly=false on case-insensitive FS"
exit 1
elif [ "$READONLY_FALSE" -eq 1 ]; then
echo "VULNERABLE — Tomcat $TOMCAT_VER with readonly=false (risk reduced on case-sensitive FS)"
exit 1
else
echo "PATCHED — Tomcat $TOMCAT_VER is in vulnerable version range but readonly=true (default). Exploitability: NONE. Upgrade recommended but not urgent."
exit 0
fiIf you remember one thing.
readonly=false in its DefaultServlet configuration. If you find any (you almost certainly won't), revert to readonly=true immediately and patch those hosts to 9.0.98 within the week. For the rest of your fleet, this is a MEDIUM finding under the noisgate reassessment — there is no noisgate mitigation SLA at this severity, so go straight to the noisgate remediation SLA of 365 days and roll the 9.0.98 upgrade into your next scheduled Tomcat maintenance window. Remove the examples webapp from any production instance while you're at it. If you're running Tomcat on Java 8 or 11, add -Dsun.io.useCanonCaches=false to JVM args when you do patch. Do not let this CVSS 9.8 label panic your team into an emergency change window — the preconditions simply aren't met in standard deployments.Sources
What defenders are saying.
Crowdsourced verification outputs.
Results submitted by users who ran the verification payload against their environment.