WebDAV MKCOL Path Traversal

What Makes WebDAV MKCOL Path Traversal Dangerous

WebDAV MKCOL is meant to create directories, but path traversal turns that capability into an unintended write primitive. When servers accept crafted paths without strict normalisation, an attacker can force directory creation outside the intended WebDAV root and place files where they should never have write access.

The danger is not just mistaken directory placement. Once an application lets an unauthorised path influence filesystem writes, the result can be website defacement, placement of executable content, log or configuration tampering, or a foothold for broader compromise if the target directory is security-sensitive.

How the Vulnerability Works in Practice

Path traversal issues appear when the server interprets path segments differently from the application’s security logic. Dot-dot segments, encoded separators, mixed normalisation rules, or inconsistent handling of trailing slashes can let a request escape its intended directory boundary.

With MKCOL, the attacker is not trying to read a file as in classic traversal examples. The goal is to create a directory in an unexpected location. That matters because write access is often more dangerous than read access when the destination can influence web content, deployment paths, or application state.

This class of flaw is closely related to broader traversal and input-handling problems, so the defensive mindset should match other directory traversal issues: treat every user-controlled path as untrusted until it has been canonicalised, bounded, and re-checked against an allowed base path.

How Defenders Confirm Exposure

Exposure analysis starts with inventorying any WebDAV-enabled server, reverse proxy, or application component that accepts MKCOL. Teams should confirm whether the endpoint is reachable from the internet, whether WebDAV is actually required, and whether any upstream proxy rewrites or backend filesystem mappings expand the attack surface.

Validation should include the vendor advisory or product documentation for the exact server stack, because the practical risk often depends on request routing, filesystem permissions, and normalisation behaviour in that specific implementation. Organisations should also review whether WebDAV methods are enabled more broadly than intended, especially on public-facing sites.

For web application context, it is useful to map the issue to the broader pattern of path traversal and broken access control. The key question is not only whether traversal is theoretically possible, but whether a crafted MKCOL request can reach a directory boundary that matters operationally.

Detection, Containment, and Recovery

Detection should focus on unusual MKCOL usage, unexpected directory creation events, and requests containing traversal markers or encoded path segments. Access logs, application logs, and filesystem monitoring can help identify suspicious attempts and confirm whether a write landed outside the intended location.

If patching is not immediately possible, reduce exposure by disabling WebDAV where it is unnecessary, restricting the method at the reverse proxy or web server layer, and tightening filesystem permissions so the web process cannot write into sensitive directories. Strong containment also means separating writable content paths from code, configuration, and executable locations.

After suspected exploitation, review newly created directories and files, and inspect adjacent locations for follow-on tampering. If the server can write into session stores, upload paths, or application configuration areas, the compromise may extend beyond the initial directory creation event.

Risk and Threat Considerations

WebDAV MKCOL path traversal is attractive to attackers because it converts a single malformed request into filesystem write access outside the intended boundary. That can enable persistence, defacement, content injection, or preparation for a second-stage attack if the created path sits somewhere the server later executes or serves.

Failure mechanism: The server fails to canonicalise and revalidate the requested path after decoding and normalisation, so directory creation is evaluated against the wrong filesystem location.

Impact: An attacker may place data or directories in privileged locations, tamper with web content or configuration, and in some deployments create a stepping stone toward code execution or broader compromise.

Practitioner Guidance

Why practitioners should care: MKCOL should never be treated as a harmless housekeeping method. If a WebDAV endpoint can create directories, it must be governed with the same care as any other write-capable interface, because write paths are often the shortest route to real impact.

What to watch for: Review whether the server enforces a single canonical path view before authorising the write. The most important implementation detail is that security checks must occur after decoding and normalisation, not before them.

Where possible, remove WebDAV from internet-facing deployments entirely. When it is genuinely required, confine it to tightly scoped directories, verify request-method handling at every layer, and keep writable paths isolated from executable or configuration-bearing locations.

Related resources from NHI Mgmt Group

• Why do path traversal bugs create identity and secrets risk?
• What do security teams get wrong about path traversal in file upload handlers?
• Where do path traversal flaws become especially dangerous in command tooling?
• What breaks when a container download endpoint allows path traversal?