CVE-2025-55752 exposes Tomcat path traversal and upload risk

At a glance

What this is: CYCOGNITO reports that CVE-2025-55752 is a Tomcat path traversal vulnerability that can bypass access controls and, in some configurations, enable file upload and possible remote code execution.

Why it matters: This matters because exposed Tomcat instances, especially legacy or unmonitored ones, can turn a configuration-sensitive flaw into a practical external attack path that reaches web application data and upload surfaces.

Context

CVE-2025-55752 is a path traversal vulnerability, which means a crafted request can manipulate how the server resolves a URL so it reaches directories that should not be directly accessible. In this case, the security gap is not just the bug itself but the way deployment choices such as rewrite rules, HTTP PUT, and external exposure can widen exploitability.

For IAM and application security teams, the identity angle is indirect but real: this is about access control being bypassed before authentication and authorisation logic can hold the line. Unowned Tomcat servers, shadow IT deployments, and legacy web stacks are the environments most likely to expose that gap, which is typical for this class of issue.

Key questions

Q: What breaks when Tomcat path traversal is not controlled?

A: When Tomcat normalisation and decoding do not align with access controls, attackers may reach restricted directories that should never be exposed. If the deployment also allows HTTP PUT or writable upload paths, the issue can move from directory access to file placement and potential remote code execution. The failure is configuration and governance, not just patch delay.

Q: Why do rewrite rules and HTTP PUT increase Tomcat exploit risk?

A: Rewrite rules can help a crafted request survive routing checks, while HTTP PUT can turn that same request into a write operation. Together, they expand a path traversal bug from unauthorized directory access into a potential upload and execution path. That is why configuration review matters as much as patching.

Q: What are the signs that Tomcat exposure is being mismanaged?

A: The main warning signs are internet-facing instances that are not on the patch cadence, legacy or end-of-life builds, and servers with custom rewrite logic nobody can explain clearly. If teams cannot quickly answer who owns a Tomcat server, whether PUT is enabled, and whether upload endpoints are necessary, governance is weak.

Q: What should teams do after a Tomcat traversal flaw is disclosed?

A: Contain the exposed systems first by patching to the fixed Tomcat versions, then verify that PUT is disabled unless explicitly required. After that, review logs for traversal attempts and unexpected uploads, because the incident response goal is to stop unauthorised file placement before it becomes execution.

Technical breakdown

How Tomcat path traversal bypasses URL normalisation controls

The flaw comes from a regression that changes the order of URL processing. Tomcat normalizes the path before decoding it, so crafted encoded sequences can survive normalization and then resolve into protected locations after decoding. That matters because access checks are usually applied to the resolved path, and if the server reaches /WEB-INF/ or /META-INF/ unexpectedly, the request has crossed a boundary the application assumed was closed. This is not universal remote code execution by itself. It is a request-routing failure that becomes exploitable when the deployment exposes the right surface.

Practical implication: validate how the server resolves paths before relying on application-level access controls.

Why HTTP PUT changes a traversal bug into upload risk

HTTP PUT is an upload-capable method that can write content to a server location when enabled. If a traversal flaw can steer the request into a writable path, the attacker may be able to place files where the application did not intend to accept them. That shifts the issue from restricted-directory access to content injection, which can create a stepping stone toward code execution if the server later processes the uploaded file as executable content. The key point is that PUT does not create the flaw, but it can convert path confusion into a higher-impact abuse path.

Practical implication: treat enabled PUT as an exploit amplifier and disable it where it is not strictly required.

Why exposed legacy Tomcat systems are the highest-risk target

Legacy, forgotten, or externally reachable Tomcat instances concentrate the risk because they are least likely to have clean configuration baselines and timely patching. Rewrite rules, custom routing, and partial monitoring all increase the chance that a regression survives in production unnoticed. The article also notes that some end-of-life builds may be affected, which means patching may not be straightforward and the exposure may persist longer than teams expect. In practice, the exploitability of this issue is less about the vulnerability abstractly and more about whether governance still covers the server estate.

Practical implication: inventory all Tomcat assets first, then prioritise internet-facing and unsupported instances for remediation.

Threat narrative

Attacker objective: The attacker aims to bypass web access controls, upload malicious content, and potentially gain remote code execution on exposed Tomcat servers.

1. Entry begins when an attacker sends a crafted request that exploits Tomcat's path normalisation and decoding order to reach restricted directories.
2. Credential or privilege bypass occurs because the request reaches locations the application assumed were protected, weakening server-side access control boundaries.
3. Escalation becomes possible where HTTP PUT is enabled, because the attacker can upload files through the traversal path and potentially stage code execution.
4. Impact is the compromise of exposed Tomcat workloads through unauthorized file placement and possible remote execution on vulnerable systems.

Breaches seen in the wild

• Gladinet Hard-Coded Keys RCE Exploitation: Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Configuration-dependent flaws are a governance problem before they are a vulnerability problem. CVE-2025-55752 only becomes high impact when deployment choices such as PUT, rewrite rules, and exposure to untrusted networks are present. That means the control failure is not just patch lag, but incomplete configuration governance across the web server estate. Practitioners should treat exposed Tomcat as an asset-discovery and policy-enforcement issue, not only a patching issue.

Path traversal matters here because it undermines the trust boundary between routing and access control. The server first interprets the path, then the application assumes the resolved location is safe. When normalization and decoding are ordered badly, that assumption collapses and protected directories become reachable through crafted requests. The practical consequence is that secure design must verify request parsing, not just downstream authorisation.

Shadow IT and forgotten middleware create the longest exploit window. The article's warning about legacy and unmonitored deployments is the real operational lesson. Unsupported Tomcat builds, dormant upload endpoints, and inconsistent rewrite rules give attackers the best chance of finding a server that no one is actively governing. Practitioners should assume the highest-risk systems are the ones least visible to change management.

Upload-enabled traversal is a classic example of blast-radius expansion. A bug that begins as unauthorized path access becomes much more dangerous once file-write capability is present. That is the pattern teams need to recognize: the vulnerability is the entry point, but the configuration determines whether it remains a nuisance or becomes a foothold for execution. Security teams should assess not just exploitability, but what the server can do after the first boundary is crossed.

What this signals

Traversal risk becomes an exposure-management problem when middleware is external-facing. Tomcat is often embedded in service stacks that security teams do not watch closely enough, so the practical control gap is asset visibility rather than theory. Once a server is reachable from untrusted networks, the question is not whether the flaw exists, but whether the organisation can still govern the deployment boundary.

Upload capability is the point where a routing flaw starts to matter operationally. A path traversal issue can be tolerated as a narrow bug only until write privileges or upload features are present. At that point, the attack surface changes, and practitioners need to re-evaluate both server hardening and the business necessity of allowing remote file writes.

For practitioners

• Map every Tomcat instance and its exposure level Build a full inventory of Apache Tomcat servers, then classify each one by version, internet exposure, and ownership so no legacy instance stays hidden in the estate.
• Disable HTTP PUT where uploads are not required Remove write-capable request methods from any Tomcat deployment that does not explicitly need them, because upload support raises the impact of traversal abuse.
• Review rewrite rules and request-routing exceptions Check whether custom routing, encoded paths, or reverse-proxy rules could let crafted URLs bypass normal access control logic before they reach protected directories.
• Prioritise external-facing and unsupported builds Patch Tomcat 11.0.11, 10.1.45, or 9.0.109 and above where possible, and move end-of-life deployments into a retirement plan if they cannot be updated safely.
• Add traversal and upload attempts to monitoring Watch web logs for unexpected directory traversal patterns, access to restricted paths, and anomalous file uploads so suspicious behaviour is visible early.

Key takeaways

• CVE-2025-55752 is dangerous because path traversal can defeat Tomcat's access controls and, in the right configuration, open an upload path.
• The risk is highest on exposed, legacy, or unmonitored deployments where rewrite rules and HTTP PUT are still enabled.
• Patch levels, request-routing rules, and write-capable methods all need to be checked together, because the exploitability depends on the full configuration stack.

Key terms

• Path Traversal: A bug where crafted path segments such as ../ allow input to escape an intended directory boundary. In practice, it turns a normal file operation into a boundary break, which is especially dangerous when the affected service runs with non-human identity privileges and touches production data or secrets.
• HTTP PUT: HTTP PUT is a request method used to place or replace a resource at a known location on a server. It becomes risky when exposed to untrusted users because it can create writable paths that attackers may abuse to store malicious content or stage execution.
• Rewrite Rules: Rewrite rules are routing instructions that change how incoming URLs are interpreted before they reach the application. They are useful for clean URL handling, but they can also increase exploitability if they interact badly with decoding or path normalization and let malicious requests bypass security assumptions.
• Digital Attack Surface: The digital attack surface is the set of internet-facing systems, applications, endpoints, cloud services, and APIs that can be reached or abused by an external actor. It changes constantly as environments expand, so teams need ongoing discovery and monitoring rather than one-time inventories or periodic scans.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners connect identity control to broader security programmes that depend on it.