Latest Contributions by RandallWilliams

Hi Ben, Happened to see this question, I don't typically follow this space.  This is expected behavior in ArcGIS. There's nothing to fix.  Users expect to be able to see all of the records in a spatial table. In a banking use case, where I'm only expected to see details related to my own bank record, this would be a problem. However, in the ArcGIS use case, the expected behavior is to see, for example, all points in a map in a given spatial envelope.    ... View more

@MarcoBoeringa is correct and Tenable is providing a false positive. We do not provide the parquet-avro module. Tenable chooses to err on the side of false positives over false negatives.  "Esri Assessment & Response: Component not present"  Is the correct response.  ... View more

Don't do this. You will break ArcGIS Enterprise and make it LESS secure, not MORE secure. An in place upgrade of the embedded Tomcat is NOT the solution and is completely unsupported.  ... View more

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.   ... View more

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.  ... View more

Portal for ArcGIS and ArcGIS Server use Tomcat 9.0.93 at 11.4 ... View more

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 ... View more

@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 ... View more

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.  ... View more

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.  ... View more

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.  ... View more

Attempted to DM, but recd message "None of the users have PM enabled. Message will not be sent". Please enable DM and I'll send it.  ... View more

Works for me, please clear your browser cache.  ... View more

It's in the customer exclusive area of the ArcGIS Trust Center document repository. Current version 4.3.   ArcGIS Vulnerability Scanning guidance ... View more