Apache Advisories: On March 10th, 2025, Apache issued an advisory for CVE-2025-24813 that affected the Apache Tomcat server, which has been reportedly deployed on over 387,000  instances worldwide. This vulnerability affects versions 11.0.0-M1 through 11.0.2, 10.1.0-M1 through 10.1.34, and 9.0.0-M1 through 9.0.98. 

The Apache advisory argues that the RCE vulnerability involves using a non-default configuration. It states that unless the default servlet is write-enabled and the server uses Tomcat’s file-based session persistence with the default storage location, this vulnerability cannot be exploited. 

Unfortunately, developers in many enterprises often use the Apache Tomcat default servlet to upload files and even static content, such as HTML files, to the file system, instead of deploying a separate servlet. This means that, practically speaking, the servlet is configured with write access to the file system. That is the reality. 

CISA’s Advisories: On April 1st, 2025, CISA issued a Known Exploited Vulnerability (KEV) Advisory for CVE-2025-24813.

In this advisory, CISA reminded all federal agencies via its Binding Operational Directive (BOD) 22-01 charter to apply patches for all CVEs. 

Apache’s Recommendations: The referenced CVE recommends users to upgrade to versions 11.0.3, 10.1.35, or 9.0.99, which fixed the Remote Code Execution (RCE) vulnerability. 

Historical Exposure from the Vulnerability: The earliest versions of the vulnerable server were released as follows:

  • Apache Tomcat v9.0.0-M1: release date September 22, 2017
  • Apache Tomcat 10.0.0-M1: release date February 13th, 2020
  • Apache Tomcat 11.0.0-M1: release date December 1st, 2022

This statistic indicates that this vulnerability may have been exploited for several years before the patch became available in March 2025.

Kill Chain of Tool Shell: During Steps 1 and 2, a Threat Actor would be able to determine if a given installation of the server is vulnerable or not. During Step 3, the Threat Actor composes a session ID file to drop on the Server, thereby enabling an active session on the Tomcat server. During Steps 4 and 5, the Threat Actor leverages the CVE-2025-24813 to drop the session file in the appropriate directory. During Step 6, the Threat Actor sends a request to the Tomcat server with the rogue session ID, which was dropped in Steps 4 and 5, along with a malicious serialized payload. The serialized payload effectively hides the malicious access from Web Application Firewalls. During Step 8, the Tomcat server executes the serialized payload, which could be a Bind Shell. During Step 10, the Threat Actor accesses the bind shell to perform arbitrary malicious actions (hence the RCE). 

Protect from Apache Tomcat CISA vulnerability with OttoguardAI

As can be seen in the accompanying demo, several of Virsec’s Protection Engines, shown in the kill chain, stopped the attack – well before the threat actor could even install the web shell and exfiltrate the machine keys from the vulnerable Apache Tomcat Server. Detecting the threat was accomplished by OTTOGUARD.AI using the Protection Engines without leveraging any ephemeral Indicators of Compromise referenced above. Instead, Virsec’s Protection Engines leveraged its patent-protected Default-Deny-Allow-On-Trust technology to stop untrusted code supplied by the Threat Actor. This technology helps Virsec offer true Patchless Mitigation to vulnerabilities such as the Apache Tomcat vulnerability that CISA states is being actively exploited in the wild.

What is a true Patchless Mitigation Solution? 

A true Patchless Mitigation solution should deliver the following characteristics:

  1. Theoretically, a patch stops the exploitation of the underlying vulnerability, thereby delivering Zero Dwell Time protection from Threat Actors. It stands to reason that a true Patchless Mitigation solution must be as effective as a patch in that it must deliver Zero Dwell Time, which means the Threat Actor has zero opportunity to execute even a single instruction of the arbitrary code of their choosing.
  2. A true Patchless Mitigation solution cannot hide behind a reachability argument. A determined Threat Actor can phish legitimate personnel and reach any part of the enterprise’s infrastructure.
  3. A true Patchless Mitigation solution cannot hide behind an exploitability argument. Believing that Threat Actors cannot exploit vulnerabilities undermines the capabilities of Threat Actors and is therefore akin to sticking one’s head in the sand. Many Threat Actors are highly skilled and motivated by profit, what they perceive to be nationalistic zeal, or even unfettered greed.
  4. A true Patchless Mitigation solution must not use Indicators of Compromise (IOC) such as IP addresses, file names and hashes, byte patterns in network traffic, or any ephemeral Threat Intelligence that a Threat Actor can change on a dime. At that point, it turns into a game of whack-a-mole; the Threat Actor will simply use alternative IPs or make slight modifications to the exploit to bypass hash-based lookups.
  5. A true Patchless Mitigation must not force the user into making poor choices in the name of prioritization. Instead, it should be able to scale no matter how many vulnerabilities have built up over time. Given the volume, prioritization may appear to be the way to go, but a true Patchless Mitigation solution should not force the enterprise into making compromises. Threat Actors are creatures of opportunity – when one presents itself, they will take it. 

Why OTTOGUARD.AI? 

Unlike other solutions that promise Patchless Mitigation or prioritization, OTTOGUARD.AI meets the requirements of true Patchless Mitigation:

  • Even when the vulnerability is a zero-day vulnerability. In such a scenario, the vulnerability is known to a few privileged people, which excludes the targeted app’s vendor.
  • Even when a patch from the vulnerable app’s vendor is not yet available. Creating a patch involves root cause analysis, coding, testing, and developing distribution procedures. 
  • Even when a patch is available but has not been deployed. There can be many reasons, from simple ones such as lack of awareness or non-availability of testing/deployment resources, to complex reasons such as loss caused by business discontinuity, or any other reason in between. 
  • Even when a patch prescribed by the app’s ISV is broken and cannot protect the vulnerable app. Recall that the Log4J vulnerability took four iterations of patching before the library was finally patched adequately. 
  • Even when the app has reached the end-of-life stage and no further patches are forthcoming. Most software will reach end-of-life in 5 to 7 years. Changing apps that deliver is not easy. We often see apps that are 20 to 30 years old and still going strong.
  • Even when no Indicators of Compromise are available or the list is not complete.
  • Even if the Threat Actor changes their exploit code. No two pieces of code written by different people will have the same file hash. Even a trivial difference in an algorithm, such as an additional variable that does nothing, will result in a substantial change in the hash of the code, and any cyber protection that relies on the published Indicator of Compromise will be readily blindsided.

Conclusion

Only OTTOGUARD.AI meets all the requirements of a true Patchless Mitigation solution. Empirically, we provide substantial reduction (typically 90% or better – your mileage may vary). Even more noteworthy is the fact that this percentage is, typically, even higher for vulnerabilities with Critical and High CVSS scores. The enterprise can unlock these benefits without:

  • Taking production servers offline. 
  • Without having to test the patches. 
  • Without the risk of breaking the functionality of the app, and
  • Without running the risk of the patch not even working adequately.

OTTOGUARD.AI reduces the cyber risk substantially, even as the tsunami of vulnerabilities gets stronger with each passing day. 

 Please reach out to us at www.virsec.com for more information and live demos.