nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Finde mehr Beiträge mit dem Tag

Accepted answers

RandallWilliams

Hi All,

While automated vulnerability scanners will complain about CVE-2024-50379, this CVE has no impact on ArcGIS software. A challenge with almost all of these tools is that they are good at comparing a given software product/version against a database of known vulnerabilities, they are typically unable to validate exploitability.

In this case, Esri software is not impacted by CVE-2024-50379 because we do not configure the default servlet to enable write (readonly initialisation parameter set to the non-default value of false). We also don't enable the PUT method at the application server level.

Note also that this CVE would typically only impact Windows - Linux based file systems are case sensitive.

All comments

ChristophK

@RandallWilliams sorry to ping you again on this topic, do you have information about CVE-2025-31650?

I was notified about CVE-2025-31650 in our Portal and Server 11.3 servers, the Tomcat developers have marked this as "important" and fixed it in Tomcat 9.0.104: https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.104

As of now I can't find entries in the KVE database and Esri CVE Responses, but exploits are linked on e.g. the Snyk CVE database.

Update: I was informed that Portal and Server 11.3 are not affected by this vulnerability. It would require the use of HTTP/2 which is not configured on the embedded Tomcats.

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-vulnerabilities

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:

The team should first understand the CVE: NVD - CVE-2025-24813
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.

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-vulnerabilities-catalog?search_api_fulltext=CVE-2025-24813&field_date_added_wrapper=all&field_cve=&sort_by=field_date_added&items_per_page=20&url=

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.

RandallWilliams

Portal for ArcGIS and ArcGIS Server use Tomcat 9.0.93 at 11.4

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

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&isCpeNameSearch=false&cpe_vendor=cpe%3A%2F%3Aesri

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.

Jay_Geisen

Thank you for the clarification - much appreciated.

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

Randall, can we assume the same holds true (no impact) for CVE-2025-24813

RandallWilliams

For completeness - ^^^ This same response also applies to CVE-2024-56337 . These are basically the same bugs, but the mitigation for CVE-2024-50379 was incomplete. We have recently updated our 3rd party CVE response app to reflect the above stance for CVE-2024-50379. That app is found in the "Customer Exclusive" document repository in the ArcGIS Trust Center.

RandallWilliams

I get that. I hear it from customers frequently. However, this is an out-of-date approach and is inconsistent with CISA's guidance.

CISA's approach has been for organizations to provide what's called an SBOM - a Software Bill of Materials. The SBOM is a machine-readable document that lists all of the "ingredients" used to build software.

Due to the fact that the SBOM will surface issues like this that have no practical impact on a product, CISA also provides a way to justify the presence of a vulnerability that does not actually impact software - a similar limit that automated security tooling has. To account for that, CISA provides a tool to justify the presence of these vulns - that's CISA's VEX.

Vulnerability Exploitability eXchange (VEX) – Use Cases

Vulnerability Exploitability eXchange (VEX) - Status Justifications

Additionally, we strongly encourage customers to leverage tools like CISA's KEV catalog.

KEV provides an authoritative source of vulnerabilities that are known to have been exploited "in the wild". CVE-2024-50379 is not (yet) listed in the KEV catalog.

For this case, the VEX status justification is "Vulnerable_code_cannot_be_controlled_by_adversary" because there's not a way for an attacker to exploit this CVE in our software. This is the direction the industry is moving - away from patching due to CVSS (which is not an indicator of risk) and toward using limited resources to address issues that introduce risk - eg: demonstrably exploitable issues.

While we update Tomcat for each release and our 11.5 release will include an updated internal application server, we have no plans to offer an out-of-cycle patch for a CVE that does not impact ArcGIS Enterprise.

In a case like this, when organizations threaten to take a service offline to satisfy a "compliance" requirement when a vendor - who is authoritative in this discussion - provides evidence that the issue is not exploitable, the organization in fact causes a high severity (CVSSv31 7.5) denial of service against themselves. We welcome additional conversation regarding our vulnerability handling process. Feel free to shoot me a DM and we can arrange a discussion with your CISO and other stakeholders.

JohnLivengood

Believe me I understand that but telling our IT security team "it's likely that the vulnerabilities do not impact us" is not a solution. They wanted to shut down our enterprise system entirely until a patch was released. I work for a State Gov Agency, and they don't mess around with these scans.

Is Esri working on a patch? The good news is I stored the old jar files on an external drive. My plan is to place them back when a patch is released. But for now, everything appears to be working normally.

RandallWilliams

John, this is a dangerous, untested, and unsupported path. We do not bundle the default, unmodified Tomcat binaries with ArcGIS software. It is likely that vulnerabilities that do not impact ArcGIS software due to how we build Tomcat are now introduced by this change. We strongly recommend against in-place upgrades of 3rd party components used in our software.

RandallWilliams

Hi All,

Note also that this CVE would typically only impact Windows - Linux based file systems are case sensitive.

JohnLivengood

Apache tomcat has released an update to CVE-2024-50379. Follow at your own peril but I downloaded the latest 9.0.98 jar file and renamed to tomcat-juli.jar. On each server I replaced the vulnerable jar file with the latest version. After restarting the 3 enterprise services, everything is working normally and scans are clear.

Details on the vulnerability Apache Tomcat® - Apache Tomcat 9 vulnerabilities

Downloadable repository Central Repository: org/apache/tomcat/tomcat-juli/9.0.98

I would still recommend waiting for the official patch but if you're in a hurry...

TimWestern

This is actually an interesting question, because, They announced deprecation of ArcGIS Maps SDK for Java in march of 2024. https://support.esri.com/en-us/knowledge-base/arcgis-maps-sdk-for-java-deprecation-000032164
also noted with the notice at the top of this page: https://developers.arcgis.com/java/

So if Java is not being used as an integration point, what other parts of ArcGIS that we may be deploying actually rely on Java and or Tomcat?

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.