External Control of File Name or Path

What this weakness means

External control of file name or path occurs when untrusted input decides which file a program opens, creates, or modifies. The core problem is not just bad input validation, but allowing user influence over a filesystem location that should be reserved for the application or operating system.

That makes the weakness especially dangerous in any workflow that builds paths from request parameters, filenames, upload metadata, archive contents, or form fields. If the application does not constrain the target location, the result can be unexpected reads, writes, deletes, or overwrites outside the intended directory.

Why it becomes a security issue

This weakness is often exploited through path traversal, absolute-path injection, or crafted names that escape a sandboxed directory. The impact can range from disclosure of sensitive files to corruption of application state, log poisoning, configuration tampering, or code execution when a writable target is abused.

It is also dangerous because the vulnerable operation may look routine. File handling is often spread across upload handlers, import routines, cache management, temporary file creation, and document processing, so the flaw can hide inside otherwise normal business logic.

How defenders constrain file handling

The safest approach is to treat the user input as a label, not as a filesystem directive. Defenders should map allowed names to known-safe locations, canonicalise paths before use, and reject path separators, absolute references, and other constructs that can redirect access outside the intended directory.

Controls for file-path safety fit naturally with broader application hardening. The application should run with the minimum filesystem privileges it needs, and sensitive directories should not be writable by the same process that handles untrusted input. OWASP API Security Top 10 is a useful adjacent reference when the file operation is exposed through an API surface and access decisions need to be tightened at the request boundary.

Detection and review after exploitation

Detection usually starts with abnormal file access patterns, unexpected locations in logs, or writes to filenames that contain traversal sequences, mixed separators, or encoded variants. Because exploitation can be subtle, teams should review recent file operations after a suspected incident, not just rely on failed request logs.

If the weakness was used to alter application files, configuration, scripts, or stored data, the compromise review should extend beyond the original entry point. A MITRE ATT&CK Enterprise Matrix view helps teams think about follow-on activity such as persistence, privilege abuse, and lateral movement after the initial file write.

Risk and Threat Considerations

This weakness matters because file access often sits on a direct trust boundary between user input and operating-system resources. When attackers can steer a path, they may be able to steal secrets, overwrite executable or configuration files, or place malicious content where the application later consumes it.

Failure mechanism: The application accepts a filename or path from untrusted input, then uses it without strict canonicalisation and allowlisting, so the attacker escapes the intended directory or targets a sensitive file.

Impact: The result can be data exposure, destructive overwrite, integrity loss, service disruption, or, in some designs, a path to code execution or durable compromise.

Related resources from NHI Mgmt Group

• How should security teams control public file sharing in Salesforce?
• What do security teams get wrong about external file sharing?
• How do organisations make file encryption easier without weakening control?
• How do security teams know when an AI instruction file has become a security control?