Apache Tomcat CVE-2025-24813: Vulnerable Does Not Mean Exploitable

The listed fixed releases are historical reference points. Organizations should upgrade to a current supported release in the appropriate Tomcat branch and account for security fixes published since the original advisory.

The flaw centered on how Tomcat handled partial HTTP PUT requests. Tomcat created a temporary file from the user-controlled request path and replaced path separators with periods. Under certain conditions, two paths that should have remained distinct could resolve to the same temporary file.

Apache documented two principal impact paths. The file read or content-injection path required all the following:

• The Default Servlet allowed writes, a setting Tomcat disables by default.
• Partial PUT support was enabled, which was the default behavior at the time.
• A sensitive upload destination existed beneath a public upload location.
• The attacker knew the sensitive filename, and that file was also uploaded through partial PUT.

Remote code execution required a different combination. The Default Servlet had to allow writes, partial PUT had to remain enabled, the application had to use file-based session persistence in the default storage location, and a library suitable for a deserialization attack had to be present.

With those conditions in place, an attacker could attempt to place a crafted serialized session file where Tomcat expected persisted sessions. When Tomcat loaded the session, an available deserialization gadget could lead to code execution. The vulnerability was real and serious, but a version banner alone could not establish that this complete path existed.

Security teams often begin with version detection because it is fast and scalable. That is useful for locating affected assets, but it does not determine whether writes are enabled, whether session persistence uses the required path, whether a usable deserialization gadget exists, or whether another control interrupts the attack.

Horizon3's Attack Team analyzed more than 10,000 publicly accessible Tomcat endpoints across customer environments. At the time of the analysis, the team reported that none used the vulnerable configuration, including servers running versions in the affected range. Horizon3 also reported in its campaign brief that development of its Rapid Response test began 13 days before CISA added the CVE to KEV.

This is not an argument for slower patching. Active exploitation and KEV inclusion still demand prompt remediation. The finding shows why defenders need two parallel answers: which systems require action, and which of those systems expose a working exploit path right now?

NodeZero Rapid Response addresses the second question. Horizon3's Attack Team analyzes emerging vulnerabilities and develops targeted tests that customers can run against their own assets. For CVE-2025-24813, the objective is to go beyond a software-version match and test whether the conditions required for exploitation are present and reachable.

A confirmed result gives the security team evidence for immediate escalation. A validated negative result does not remove the obligation to patch, but it can show that the tested exploit path is closed while remediation continues. Running the test again after a change helps verify that the patch or mitigation altered the outcome.

Rapid Response is therefore tightly scoped. It answers whether the known Tomcat exploit can work in the tested environment. It does not test every authorization decision, workflow, or API exposed by the applications running on Tomcat.

Once the infrastructure-level question is answered, the application becomes the next layer of risk. Tomcat frequently hosts customer and partner portals, internal business applications, administrative tools, APIs, and custom Java services. These systems can contain exploitable weaknesses even when CVE-2025-24813 is patched or its required configuration is absent.

An attacker may not need server-level code execution if the application already offers another route to the objective. Broken access control could allow one user to retrieve another user's data. An API might accept a changed object identifier without checking ownership. A privileged function hidden from the interface may remain callable through a direct request. A weak session or workflow may expose an administrative action to a lower-privileged user.

These weaknesses often have no CVE and no version signature. They arise from the way a custom application implements roles, objects, routes, identity, and business processes. They also tend to live behind authentication, where a public-only scan has limited visibility.

NodeZero WebApp applies Horizon3's offensive validation approach to custom, business-critical web applications. It is separate from the Rapid Response test for CVE-2025-24813. Its role is to examine the application routes, authenticated workflows, APIs, and authorization boundaries that remain after the server-level vulnerability has been addressed.

According to Horizon3, NodeZero WebApp uses headless-browser crawling and route discovery to map modern single-page applications, hidden functions, and REST, SOAP, or GraphQL endpoints. It can authenticate through real user workflows and test role-based experiences, including environments that use multifactor authentication.

The platform then validates how the application enforces access. Testing can cover broken access control, IDOR and BOLA conditions, session behavior, and business-logic weaknesses. A read-only, GET-only mode can provide a lower-impact starting point for production environments before teams authorize broader methods.

The useful output is evidence that developers and defenders can act on: replayable requests and responses, screenshots, route context, and a demonstrated result. The broader NodeZero platform can add context when an application weakness exposes credentials, tokens, cloud resources, or internal systems. That helps teams distinguish a contained defect from the beginning of a larger attack path.

See how NodeZero WebApp tests authenticated workflows, APIs, access controls, and application attack paths with replayable proof: Watch the Introducing NodeZero WebApp webinar.

The sequence below moves from inventory to validated, business-relevant risk.