CVE-2025-24813: Tomcat Partial PUT Exposure Conditions

CVE-2025-24813 is an Apache Tomcat path-equivalence issue involving partial PUT and a write-enabled Default Servlet. Depending on the full configuration, Apache describes remote code execution, sensitive-file disclosure or malicious content added to uploaded files. Apache’s CVE record defines distinct prerequisites for those outcomes. A Tomcat banner or a successful PUT request does not establish the complete RCE condition.

Start with the branch, then inspect the effective configuration

These are historical first fixes for this vulnerability, not a recommendation to install an old minimum today. Select a currently supported release containing the correction, or a supported supplier package with an explicit backport advisory. The Apache security page and the record also leave uncertainty for some older end-of-life versions; do not interpret missing confirmation as safety.

Evaluate the RCE path as four conditions together

Apache requires all of the following for the described RCE path: writes enabled for the Default Servlet, which is disabled by default; support for partial PUT, which is enabled by default; Tomcat file-based session persistence using its default storage location; and an application library that can be leveraged in a deserialization attack. The presence of Java serialization somewhere in an organization is not evidence for the fourth condition in a specific web application.

This decision logic narrows what is known; it does not waive the upgrade. If one necessary condition is demonstrably absent, record the RCE path as not established under the observed configuration, with the observation date. Configuration may change, and the separate file-impact path still needs assessment.

Assess disclosure and file corruption independently

For the file disclosure or content-injection path, Apache lists the same write-enabled Default Servlet and partial PUT conditions plus three others: the sensitive-upload target URL is a subdirectory of a public-upload target URL; the attacker knows the names of sensitive files being uploaded; and those sensitive files are also uploaded via partial PUT. These are URL and upload-workflow relationships, not a generic statement that every upload directory is vulnerable.

Map public and sensitive upload handling from application configuration and design documentation. Confirm which component accepts each upload and how it stores temporary and completed content. Use a harmless owned file in a staging regression when behavior needs confirmation. Do not probe production with an exploit or a serialized execution payload to fill a configuration gap.

Tie the fix to the active Tomcat instance

Inventory embedded Tomcat distributions, containers and supplier appliances as well as standalone services. Record the deployed artifact, supplier package version and relevant advisory. Where a supplier backports the fix, retain that supplier’s evidence instead of comparing only the upstream version string. Link the fixed artifact to the process actually serving the application after deployment and any required restart.

A useful acceptance record has two independent outcomes: the corrected build is active, and the intended authorization and upload behavior still works. Exercise ordinary permitted reads and uploads, denied writes where applicable and normal session behavior in the approved test scope. Passing these benign checks supports operational confidence; it is not a reproduction or disproof of every exploit chain.

Treat KEV history as a reason to review the earlier window

CISA added CVE-2025-24813 to its CISA Known Exploited Vulnerabilities catalog on April 1, 2025, with a listed federal due date of April 22, 2025. If an affected application previously satisfied the relevant conditions, review available access, upload, application and endpoint records for that period. Retain evidence before routine cleanup. Catalog inclusion establishes a known-exploitation signal; it does not attribute a local incident or prove an unverified multi-CVE chain.

The practical closure decision is configuration-aware: corrected supported runtime, documented assessment of both impact paths and evidence from the active application. Keep unknown prerequisites visible until the application owner can resolve them.

The following official Penligent 3.0 video demonstrates the general product workflow. It does not demonstrate exploitation or certify remediation of the vulnerabilities discussed here.

Source review: November 12, 2026. This analysis uses public primary records and configuration or source-code reasoning; no exploit reproduction is claimed.