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

At a glance

What this is: This advisory explains how CVE-2025-55752 lets attackers reach restricted Tomcat paths and, in some configurations, move toward file upload and remote code execution.

Why it matters: It matters because Tomcat often sits inside web application and middleware estates where exposed, forgotten, or third-party-managed instances can become high-impact entry points for application compromise.

By the numbers:

• Tomcat 11.0.0-M1 through 11.0.10, Tomcat 10.1.0-M1 through 10.1.44, and Tomcat 9.0.0-M11 through 9.0.108 are affected by CVE-2025-55752.
• Apache patched the issue in Tomcat 11.0.11, 10.1.45, and 9.0.109.

👉 Read CYCOGNITO's analysis of CVE-2025-55752 and exposed Tomcat workloads

Context

CVE-2025-55752 is a path traversal flaw in Apache Tomcat, and the security problem is not the path traversal alone but the way configuration and exposure change exploitability. When a parser normalizes before decoding, attackers can sometimes steer requests into restricted directories, which is especially relevant for application servers that sit behind inconsistent access controls or outdated operational assumptions.

For identity and access teams, the important issue is not just server patching but who can reach upload paths, which systems are internet-facing, and whether third-party or shadow IT Tomcat instances are still trusted inside the environment. Exposed application servers often become privileged launch points into broader web estates, and that pattern is typical for unmanaged infrastructure rather than well-governed production stacks.

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 exposed application servers increase application attack risk?

A: Exposed application servers sit at a boundary where routing, authorization, and backend trust intersect. If those servers are reachable from untrusted networks, a path traversal flaw can become a direct entry point into application logic or file-handling flows. They also often carry service credentials, which turns a web flaw into a broader trust problem.

Q: How can security teams know whether Tomcat authentication exposure is actually contained?

A: They should confirm every JNDIRealm deployment, verify whether GSSAPI binds are enabled, and check whether the vulnerable versions are still running in production, staging, or third-party hosted platforms. Containment is real only when the exposure is inventoried, the risky bind mode is removed or patched, and network reachability is narrowed to trusted paths.

Q: Who is accountable when a vulnerable Tomcat server remains exposed?

A: Accountability usually spans the application owner, platform team, and whoever owns external attack surface governance. If a third party manages the server, the organisation still needs assurance that patching, configuration validation, and exposure review are being performed. NIST SP 800-53 and NIST CSF both reinforce that control ownership cannot be ambiguous.

Technical breakdown

How Tomcat path traversal bypasses URL-based controls

The flaw described here arises when URL normalization happens before decoding, which can create a mismatch between what the server thinks it is protecting and what the attacker actually requests. That mismatch matters because access checks can be applied to one interpretation of the path while the underlying filesystem resolves another. In practical terms, this is a classic parser-confusion problem. If the application server accepts crafted traversal sequences, requests may reach directories such as /WEB-INF/ and /META-INF/ even when policy says they should not. The vulnerability becomes meaningful only when exposure and configuration align.

Practical implication: inventory exposed Tomcat instances and verify whether path handling differs between rewrite rules, proxies, and the server itself.

Why HTTP PUT and upload endpoints raise the impact

Path traversal becomes more dangerous when HTTP PUT is enabled, because reaching a writable location can turn read access into code placement. In that case, attackers do not need a perfect exploit chain to cause damage. They need a path that lands in a directory the application will serve or process. This is why upload endpoints, writable web roots, and weakly controlled write permissions materially change the risk profile. The flaw does not guarantee remote code execution by itself, but it can create the conditions for execution when the deployment accepts uploaded content in a sensitive location.

Practical implication: remove unnecessary HTTP PUT exposure and treat upload permissions as a high-risk control point.

Why legacy Tomcat deployments are especially exposed

Older or unmaintained Tomcat systems often carry the exact combination of conditions attackers look for: outdated versions, forgotten internet exposure, and configuration drift. Shadow IT amplifies that problem because the asset owner may not know the server still exists, let alone whether rewrite rules or upload features are enabled. The exploitability is therefore less about one bug and more about the operational reality around it. A vulnerable version in an internal lab is not the same as that same version on a public-facing application server with stale hardening and no monitoring.

Practical implication: tie version checks to exposure data so forgotten or third-party Tomcat systems do not bypass patch governance.

Threat narrative

Attacker objective: The attacker aims to turn a configuration-dependent Tomcat path traversal flaw into code execution on an exposed web workload.

1. Entry occurs through a crafted Tomcat request that abuses path traversal and parser confusion to reach restricted directories.
2. Escalation becomes possible when HTTP PUT or similar write-capable functionality allows an attacker to place files into an executable or reachable location.
3. Impact can include remote code execution on exposed Tomcat workloads and broader compromise of the application environment.

Breaches seen in the wild

• Gravity SMTP CVE-2026-4020 API Keys Exposure — CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.
• Gladinet Hard-Coded Keys RCE Exploitation — Actively exploited hard-coded keys in Gladinet CentreStack and Triofox enable remote code execution.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Configuration-dependent exploitation is the real control gap here. CVE-2025-55752 is not just a patching story, because the same flaw becomes materially more dangerous only when rewrite rules, HTTP PUT, and internet exposure line up. That is a governance problem as much as a vulnerability problem. Security teams should treat exploitability as a function of configuration state, not version number alone.

Exposed application servers remain an overlooked identity and access boundary. Tomcat often sits behind assumed trust, but a public-facing application server can become a pivot point into internal web services, upload paths, and backend integrations. That makes this relevant to IAM and PAM teams as well, because service credentials and application trust relationships are frequently attached to the same systems. The control lesson is to govern access paths, not just host patch status.

Shadow IT and forgotten servers create the longest exposure window. The article’s emphasis on legacy and unmonitored deployments reflects a broader operational pattern: unmanaged assets are the ones most likely to miss both patch windows and configuration review. In NHI terms, the same blind spot often applies to service accounts and tokens attached to abandoned workloads. Practitioners should treat asset discovery and lifecycle control as one programme, not separate tasks.

Path traversal risk is a parser-trust problem, not simply an application bug. The underlying issue is that security controls can be bypassed when one layer interprets a request differently from another. That is a useful reminder for web, cloud, and identity teams that layered controls only work when they share the same view of the resource being protected. Practitioners should validate where request normalisation, routing, and authorization checks disagree.

Tomcat exposure should be assessed as part of workload identity and service lifecycle governance. Publicly reachable middleware often carries embedded credentials, backend trust, and automation hooks that extend impact beyond the server itself. The lesson for identity programmes is to map which workloads can write, execute, or relay privileged actions before the next patch cycle completes. That is where risk becomes operationally real.

From our research:

• Only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs.
• From our research: 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
• For a broader governance view, see Ultimate Guide to NHIs , Key Challenges and Risks for how visibility gaps and over-privilege combine across workload estates.

What this signals

Tomcat exposure should be treated as part of identity-linked workload governance, not only vulnerability management. When an externally reachable application server can write files or route requests differently than expected, the surrounding service credentials and backend trust relationships become part of the attack surface. The practical response is to connect patching, exposure review, and credential inventory so the asset cannot be reassigned trust after remediation.

Configuration drift is the hidden multiplier here. A version check alone does not prove safety if rewrite rules, upload permissions, or proxy behaviour still allow traversal to become execution. That pattern mirrors broader NHI governance failures, where the asset appears managed but the privilege model remains opaque. Teams should align remediation evidence with control-state verification, not ticket closure.

The most durable reduction in risk will come from pairing external asset discovery with lifecycle control for the identities and services that those assets use. That means validating which Tomcat instances are still active, which ones are abandoned, and which ones hold backend access that should have been revoked long ago.

For practitioners

• Audit external Tomcat exposure Map every Apache Tomcat instance, then verify which ones are internet-facing, reachable from untrusted networks, or hidden in legacy environments. Prioritise assets that also expose upload endpoints or depend on rewrite rules.
• Disable unnecessary HTTP PUT Remove PUT support wherever the application does not explicitly require it, and confirm that upload paths cannot be used to place executable content in writable directories.
• Validate rewrite and decoding behaviour Test how proxies, rewrite rules, and Tomcat itself interpret crafted paths, especially where access checks depend on URL normalisation. Compare expected and actual routing for traversal-like requests.
• Prioritise patching by exposure Move vulnerable instances to the front of the remediation queue when they are externally reachable or linked to third-party managed services, then confirm Tomcat 11.0.11, 10.1.45, or 9.0.109 and above are in place.

Key takeaways

• CVE-2025-55752 is dangerous because configuration can convert a parser flaw into access control bypass and, in some deployments, code execution.
• Exposed, legacy, and forgotten Tomcat instances are the most likely to create real-world risk because they combine vulnerability, reachability, and weak governance.
• Teams should patch, disable unnecessary write paths, and verify exposure state at the asset level, because version hygiene alone does not close the control gap.

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.
• Attack Surface Management: Attack surface management is the practice of finding and evaluating assets that could be exposed to misuse or compromise. CAASM focuses on internal visibility across the environment, while EASM focuses on externally reachable assets. It is a discovery discipline, not a complete identity control model.
• Configuration Drift: Configuration drift is the gradual divergence between a system's intended secure state and the settings it actually runs with over time. In SaaS, drift often appears when admins change sharing, logging, or access controls under pressure and never return to validate the result.

What's in the full analysis

CYCOGNITO's full article covers the operational detail this post intentionally leaves for the source:

• Version-by-version impact analysis for affected Tomcat builds and why some EOL deployments may still be at risk
• Configuration conditions that increase exploitability, including rewrite rules and HTTP PUT exposure
• Short-term mitigation steps versus durable remediation, including how to validate patches after deployment
• Guidance on monitoring for suspicious upload behaviour and traversal attempts across exposed web services

👉 CYCOGNITO's full article covers patch versions, configuration triggers, and mitigation priorities for exposed Tomcat systems.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity for practitioners building resilient access controls. It helps security teams connect service-account governance to broader identity and attack-surface management.