Apache Tomcat vulnerability CVE-2024-50379

[JohnLivengood]

We're already getting pinged by our IT for a security vulnerability with Apache Tomcat released 12/17/24 - CVE-2024-50379.  I am operating on 11.3.  Assume I just need to wait for a patch to be released? 

The Time-of-check Time-of-use (TOCTOU) Race Condition vulnerability in Apache Tomcat allows for Remote Code Execution (RCE) on case insensitive file systems when the default servlet is enabled for write. This vulnerability affects Apache Tomcat versions 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. An attacker can exploit this vulnerability to execute arbitrary code. It is recommended to upgrade to version 11.0.2, 10.1.34, or 9.0.08 to fix this issue.

Impact: If this vulnerability is exploited, an attacker can execute arbitrary code on the affected system, potentially leading to a complete compromise of the system.

Remediation: Apply the latest patches and updates provided by the respective vendors.

[RandallWilliams]

@Jay_Geisen Correct. All of these issues require that the Tomcat application server be configured to allow writes to the default servlet, which is disabled by default (and we don't enable). We also don't enable PUT or partial PUT. These facts can be validated with a quick look at our web.xml file. 

SOAPBOX:

This kind of issue is representative of the fact that automated vuln scanners provide super-high levels of false positives. They simply enumerate component versions and compare against a list of vulnerabilities in a database, but don't typically have the ability to actually validate their findings OR provide context. I understand why: a false positive is better than a false negative. The challenge comes when organizations take these findings as absolute truth, when the scan vendors provide clear statements that they do NOT validate based on context, just component version. That leaves many users in a weird spot, where a vendor like Esri says "we're not impacted" but the automated tool says, "...therefore the software is vulnerable".

/SOAPBOX

[Jay_Geisen]

Thank you for the clarification - much appreciated. 

[JohnLivengood]

I do appreciate your responses.  This new CVE came across my desk and I was able to respond in kind based on the previous CVE. 

We'll continue have these false positive scans.  No way around it as our Office of Cyber Security team is in a completely separate agency and each State Agency receives a vulnerability score based on these scans.  They are willing to close out select vulnerabilities, but it takes a bit of thrashing back and forth.  Most of us administrators may not know where and how to look at the server's susceptibility. 

In this instance, your help has been very much appreciated and thanks for the tip about the web.xml.

[RandallWilliams]

I frequently hold conversations with security stakeholders on this topic. Hit us up using the form on https://trust.arcgis.com if we can help provide context to security teams. Usually when I talk to "security", they get where I'm coming from. "Compliance" is a whole 'nother can o' worms. If it helps, we update major frameworks like Java, Tomcat, PostGREs with each release. We have a clear history of addressing vulnerabilities - wherever they come from - if they are exploitable. We don't take these things lightly and have vested interest in ensuring we provide safe software. We just take a measured, risk-based approach to make sure we use our limited resources in the most effective manner. For instance, no, we don't plan to patch Tomcat for this issue, but that's because we have issues that are clearly exploitable to manage. We can publicly attest to that fact here: https://nvd.nist.gov/vuln/search/results?form_type=Advanced&results_type=overview&search_type=all&is...

[MichaelJenkins]

Recent Apache Tomcat RCE Vulnerabilities

Esri just posted about that one and says we are not vulnerable to the exploit.

I checked our 11.3 server and it running Tomcat 9.0.84.  Can someone check what version 11.4 has?

[RandallWilliams]

Portal for ArcGIS and ArcGIS Server use Tomcat 9.0.93 at 11.4

[RandallWilliams]

Correct. There is no exploit path for this and other CVEs in ArcGIS Enterprise. In order to be vulnerable, someone with local access must have rights to the ArcGIS Enterprise installation and modify configuration files. If an attacker has local access to a machine and can make these changes, the victim has much bigger vulnerabilities they need to address. 

[JeffGilmour]

@RandallWilliams  Is the same true for this CVE-2025-24813?  This one shows up on the KEV Known Exploited Vulnerabilities Catalog | CISA  : https://www.cisa.gov/known-exploited-vulnerabiliti...

[RandallWilliams]

Yes, we speak to all three Recent Apache Tomcat RCE Vulnerabilities CVE-2025-24813,  CVE-2024-50379 and CVE-2024-56337 together in this advisory:

https://www.esri.com/arcgis-blog/products/trust-arcgis/administration/recent-apache-tomcat-rce-vulne...

Some teams require a higher level of detail and assurance to understand why these CVEs don't impact ArcGIS Enterprise. 

To get deep in the weeds on why CVE-2025-24813 has no impact on ArcGIS Enterprise:

1. The team should first understand the CVE: NVD - CVE-2025-24813
2. The team should understand this writeup: Understanding and Checking for Tomcat CVE-2025-24813

CVE text:

Title: Path Equivalence: 'file.Name' (Internal Dot) leading to Remote Code Execution and/or Information disclosure and/or malicious content added to uploaded files via write enabled Default Servlet in Apache Tomcat.

***********************************************

 Impacted versions: This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.2, from 10.1.0-M1 through 10.1.34, from 9.0.0.M1 through 9.0.98.

Impact statement: If all of the following were true, a malicious user was able to view security sensitive files and/or inject content into those files:

- writes enabled for the default servlet (disabled by default)

- support for partial PUT (enabled by default)

- a target URL for security sensitive uploads that was a sub-directory of a target URL for public uploads

- attacker knowledge of the names of security sensitive files being uploaded

- the security sensitive files also being uploaded via partial PUT

If all of the following were true, a malicious user was able to perform remote code execution:  

- writes enabled for the default servlet (disabled by default) - support for partial PUT (enabled by default)

- application was using Tomcat's file-based session persistence with the default storage location

- application included a library that may be leveraged in a deserialization attack

Users are recommended to upgrade to version 11.0.3, 10.1.35 or 9.0.99, which fixes the issue. 

*********************************

Esri Detail:

The non-default parameter “readonly” needs to be explicitly set. Not setting this value does not indicate vulnerability. Tomcat doesn’t set this option at all because there’s rarely a reason to enable write on the default servlet.

Proof:

Compare the default, out of the box Tomcat’s web.xml, which again is not vulnerable by default against the Esri implementation. You will not see a directive to setting “readonly:false” in our implementation.

Here’s a link to download the default OOTB Tomcat : https://dlcdn.apache.org/tomcat/tomcat-10/v10.1.40/bin/apache-tomcat-10.1.40.tar.gz

Here’s a complete writeup to fully substantiate our assertions:

Understanding and Checking for Tomcat CVE-2025-24813

Here’s an OPTIONS request indicating that the PUT method is not enabled (writes are NOT enabled for the default servlet (disabled by default).

Here’s an open source scanner than can check for this issue:

GitHub - issamjr/CVE-2025-24813-Scanner: CVE-2025-24813 - Apache Tomcat Vulnerability Scanner

We have updated our 3rd party component CVE response application to include our responses to these CVEs.