What breaks in practice when Apache Tomcat handles partial PUT paths incorrectly?

When path separators are rewritten into dots, attackers can use carefully crafted filenames to bypass the intended protection and write files into unintended locations. That can lead to unauthorized file modification, content injection, disclosure of sensitive data, and in some cases server compromise if the uploaded content is later processed by the application.

Why Partial PUT Path Handling Becomes a File-Writing Problem

Apache Tomcat’s partial PUT handling only becomes dangerous when the container normalises or rewrites path separators in a way that changes where uploaded bytes land on disk. At that point the issue is no longer a neat request-routing bug. It becomes a file integrity problem with consequences for web content, application state, and any server-side component that later trusts the written file. The practical failure is usually that a request path is interpreted more broadly than the application intended, so the protection boundary around upload targets is weakened. In practice, many security teams encounter the impact only after an unexpected file appears in a writable directory and the original request path no longer explains where it came from.

Tomcat documentation on request handling and security controls helps frame this as an integrity and access-control issue rather than a mere upload quirk, and the control perspective is useful when deciding how to harden the web tier. Read the current NIST SP 800-53 Rev 5 Security and Privacy Controls as a control reference for protecting file integrity and limiting unintended write paths.

How Incorrect Partial PUT Mapping Changes the Outcome on Disk

Partial PUT is meant to support range-based or incremental file updates, but the safe version of that behaviour depends on exact path handling. If separator rewriting turns a path-like string into something that the server treats as a different filename, the upload target can shift from the intended file or directory into another location that shares a translated form. That is why the impact is not limited to “uploading the wrong file.” The core issue is that the mapping between the URL path and the filesystem path is no longer stable.

In practice, this can create several concrete failure modes. First, an attacker may overwrite or create content inside a directory that should have been unreachable through the upload route. Second, a crafted path may place data beside executable or template assets, which turns a simple write issue into a content injection problem. Third, if the application later parses, serves, or processes the written object, the initial write can become a stepping stone to disclosure or code execution.

Path normalisation can collapse distinct request paths into the same stored filename.
Rewrite rules can make a blocked separator act like a harmless character in one layer but not another.
Upload handlers can lose alignment between request validation and disk-write location.
Later application processing can amplify a write into a more serious compromise.

This guidance breaks down when the web container, application router, and filesystem all apply different canonicalisation rules and no single trusted mapping is enforced.

Where the Real Edge Cases Appear in Production

Tighter upload-path restrictions often reduce flexibility for legitimate partial updates, so organisations have to balance operational convenience against the risk of ambiguous filename translation. That tradeoff matters most when multiple components touch the same path before persistence.

The most important edge case is not the obvious upload endpoint. It is the environment where static content, generated content, and application-managed files share a writable tree. In those deployments, a small path handling defect can affect cache files, configuration fragments, or application assets that were never meant to be writable from an HTTP request. Another common edge case is platform-specific separator handling, where a path that looks safe in one operating system or servlet layer is interpreted differently lower down. Guidance from NIST SP 800-63 Digital Identity Guidelines is not directly about file paths, but it is useful when teams are reviewing whether a write path is tied to an authenticated, authorised workflow and not simply exposed by convenience.

There is no universal consensus that partial PUT should be enabled at all for general web applications; many practitioners treat it as a specialised capability that should be disabled unless the application has a strong, tested use case for incremental updates.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	4.8 — Data Recovery	Incorrect writes can corrupt files and require rollback or restoration.
	8.2 — Unapproved Software	Wrong-path writes can place content beside executable web assets.
	16.10 — Application Software Security	Partial PUT path handling is an application-layer input handling flaw.
Recommendation — Maintain recoverable copies so unintended file writes can be restored quickly. Restrict writable locations away from executable and application content. Validate request paths and reject ambiguous upload targets before persistence.
MITRE ATT&CK	T1105 — Ingress Tool Transfer	Attackers use file transfer paths to place malicious content on a host.
	T1190 — Exploit Public-Facing Application	The weakness is exploitable through a public web upload surface.
Recommendation — Monitor inbound file transfers for uploads that land outside approved paths. Hunt public upload endpoints for path handling flaws and abnormal write locations.
NIST CSF 2.0	PR.DS — Data Security	The issue directly threatens file integrity and protected content.
	PR.AC — Identity Management, Authentication and Access Control	Unintended writes indicate broken authorisation around write access paths.
	DE.CM — Security Continuous Monitoring	Unexpected file creation or modification needs detection and alerting.
Recommendation — Apply data integrity controls to keep web writes within authorised storage paths. Enforce least-privilege write access to limit who can modify stored content. Alert on file changes that occur outside normal application write patterns.

Practitioner Guidance

What to prioritise: Validate the exact request-to-filesystem mapping, not just the endpoint allowlist. The question to answer is whether the path seen by the application is identical to the path that the storage layer uses after normalisation, decoding, and separator handling.

What to verify: Confirm that write targets are confined to a dedicated directory that cannot overlap with executable content, templates, or configuration files. Also verify that the application rejects ambiguous filenames before the container has a chance to reinterpret them.

Common mistake: Teams often assume that blocking one dangerous character or pattern is enough. Path handling bugs usually arise from combinations of encoding, normalisation, and translation, so a single filter rarely provides durable protection.

What good looks like: A partial update either lands exactly where the application intended or fails closed. There should be no case where an alternate separator, encoded character, or rewritten path can change the destination on disk.

Practitioner takeaway: Treat partial PUT as safe only when the path mapping is deterministic end to end; if that mapping can drift, the issue is already a file-integrity weakness, not a narrow upload defect.