Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') (4.18) (original) (raw)

CWE Glossary Definition

Weakness ID: 22

Vulnerability Mapping: ALLOWED This CWE ID may be used to map to real-world vulnerabilities
Abstraction:Base Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.

Description

The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory.

Extended Description

Many file operations are intended to take place within a restricted directory. By using special elements such as ".." and "/" separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the "../" sequence, which in most modern operating systems is interpreted as the parent directory of the current location. This is referred to as relative path traversal. Path traversal also covers the use of absolute pathnames such as "/usr/local/bin" to access unexpected files. This is referred to as absolute path traversal.

Alternate Terms

Common Consequences

This table specifies different individual consequences associated with the weakness. The Scope identifies the application security area that is violated, while the Impact describes the negative technical impact that arises if an adversary succeeds in exploiting this weakness. The Likelihood provides information about how likely the specific consequence is expected to be seen relative to the other consequences in the list. For example, there may be high likelihood that a weakness will be exploited to achieve a certain impact, but a low likelihood that it will be exploited to achieve a different impact.

Potential Mitigations

Relationships

This table shows the weaknesses and high level categories that are related to this weakness. These relationships are defined as ChildOf, ParentOf, MemberOf and give insight to similar items that may exist at higher and lower levels of abstraction. In addition, relationships such as PeerOf and CanAlsoBe are defined to show similar weaknesses that the user may want to explore.

Relevant to the view "Research Concepts" (View-1000)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	706	Use of Incorrectly-Resolved Name or Reference
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	23	Relative Path Traversal
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	36	Absolute Path Traversal
CanFollow	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	20	Improper Input Validation
CanFollow	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	73	External Control of File Name or Path
CanFollow	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	172	Encoding Error
CanPrecede	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	668	Exposure of Resource to Wrong Sphere

Relevant to the view "Software Development" (View-699)

Nature	Type	ID	Name
MemberOf	Category - a CWE entry that contains a set of other entries that share a common characteristic.	1219	File Handling Issues

Relevant to the view "Weaknesses for Simplified Mapping of Published Vulnerabilities" (View-1003)

Nature	Type	ID	Name
ChildOf	Class - a weakness that is described in a very abstract fashion, typically independent of any specific language or technology. More specific than a Pillar Weakness, but more general than a Base Weakness. Class level weaknesses typically describe issues in terms of 1 or 2 of the following dimensions: behavior, property, and resource.	706	Use of Incorrectly-Resolved Name or Reference

Relevant to the view "CISQ Quality Measures (2020)" (View-1305)

Nature	Type	ID	Name
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	23	Relative Path Traversal
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	36	Absolute Path Traversal

Relevant to the view "CISQ Data Protection Measures" (View-1340)

Nature	Type	ID	Name
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	23	Relative Path Traversal
ParentOf	Base - a weakness that is still mostly independent of a resource or technology, but with sufficient details to provide specific methods for detection and prevention. Base level weaknesses typically describe issues in terms of 2 or 3 of the following dimensions: behavior, property, technology, language, and resource.	36	Absolute Path Traversal

Modes Of Introduction

The different Modes of Introduction provide information about how and when this weakness may be introduced. The Phase identifies a point in the life cycle at which introduction may occur, while the Note provides a typical scenario related to introduction during the given phase.

Applicable Platforms

This listing shows possible areas for which the given weakness could appear. These may be for specific named Languages, Operating Systems, Architectures, Paradigms, Technologies, or a class of such platforms. The platform is listed along with how frequently the given weakness appears for that instance.

Likelihood Of Exploit

Demonstrative Examples

Example 1

The following code could be for a social networking application in which each user's profile information is stored in a separate file. All files are stored in a single directory.

(bad code)

Example Language: Perl

my $dataPath = "/users/cwe/profiles";
my $username = param("user");
my profilePath=profilePath = profilePath=dataPath . "/" . $username;

open(my fh,"<",fh, "<", fh,"<",profilePath) || ExitError("profile read error: $profilePath");
print "

\n";
while (<$fh>) {

print "

• $_
\n";

}
print "

While the programmer intends to access files such as "/users/cwe/profiles/alice" or "/users/cwe/profiles/bob", there is no verification of the incoming user parameter. An attacker could provide a string such as:

The program would generate a profile pathname like this:

/users/cwe/profiles/../../../etc/passwd

When the file is opened, the operating system resolves the "../" during path canonicalization and actually accesses this file:

As a result, the attacker could read the entire text of the password file.

Notice how this code also contains an error message information leak (CWE-209) if the user parameter does not produce a file that exists: the full pathname is provided. Because of the lack of output encoding of the file that is retrieved, there might also be a cross-site scripting problem (CWE-79) if profile contains any HTML, but other code would need to be examined.

Example 2

In the example below, the path to a dictionary file is read from a system property and used to initialize a File object.

(bad code)

Example Language: Java

String filename = System.getProperty("com.domain.application.dictionaryFile");
File dictionaryFile = new File(filename);

However, the path is not validated or modified to prevent it from containing relative or absolute path sequences before creating the File object. This allows anyone who can control the system property to determine what file is used. Ideally, the path should be resolved relative to some kind of application or user home directory.

Example 3

The following code takes untrusted input and uses a regular expression to filter "../" from the input. It then appends this result to the /home/user/ directory and attempts to read the file in the final resulting path.

(bad code)

Example Language: Perl

my $Username = GetUntrustedInput();
$Username =~ s/\.\.\///;
my filename="/home/user/".filename = "/home/user/" . filename="/home/user/".Username;
ReadAndSendFile($filename);

Since the regular expression does not have the /g global match modifier, it only removes the first instance of "../" it comes across. So an input value such as:

will have the first "../" stripped, resulting in:

This value is then concatenated with the /home/user/ directory:

/home/user/../../etc/passwd

which causes the /etc/passwd file to be retrieved once the operating system has resolved the ../ sequences in the pathname. This leads to relative path traversal (CWE-23).

Example 4

The following code attempts to validate a given input path by checking it against an allowlist and once validated delete the given file. In this specific case, the path is considered valid if it starts with the string "/safe_dir/".

(bad code)

Example Language: Java

String path = getInputPath();
if (path.startsWith("/safe_dir/"))
{

File f = new File(path);
f.delete()

}

An attacker could provide an input such as this:

/safe_dir/../important.dat

The software assumes that the path is valid because it starts with the "/safe_path/" sequence, but the "../" sequence will cause the program to delete the important.dat file in the parent directory

Example 5

The following code demonstrates the unrestricted upload of a file with a Java servlet and a path traversal vulnerability. The action attribute of an HTML form is sending the upload file request to the Java servlet.

(good code)

Example Language: HTML

Choose a file to upload:

When submitted the Java servlet's doPost method will receive the request, extract the name of the file from the Http request header, read the file contents from the request and output the file to the local upload directory.

(bad code)

Example Language: Java

public class FileUploadServlet extends HttpServlet {

...

protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

response.setContentType("text/html");
PrintWriter out = response.getWriter();
String contentType = request.getContentType();

// the starting position of the boundary header
int ind = contentType.indexOf("boundary=");
String boundary = contentType.substring(ind+9);

String pLine = new String();
String uploadLocation = new String(UPLOAD_DIRECTORY_STRING); //Constant value

// verify that content type is multipart form data
if (contentType != null && contentType.indexOf("multipart/form-data") != -1) {

// extract the filename from the Http header
BufferedReader br = new BufferedReader(new InputStreamReader(request.getInputStream()));
...
pLine = br.readLine();
String filename = pLine.substring(pLine.lastIndexOf("\\"), pLine.lastIndexOf("\""));
...

// output the file to the local upload directory
try {

BufferedWriter bw = new BufferedWriter(new FileWriter(uploadLocation+filename, true));
for (String line; (line=br.readLine())!=null; ) {

if (line.indexOf(boundary) == -1) {

bw.write(line);
bw.newLine();
bw.flush();

}

} //end of for loop
bw.close();

} catch (IOException ex) {...}
// output successful upload response HTML page

}
// output unsuccessful upload response HTML page
else
{...}

}

...

}

This code does not perform a check on the type of the file being uploaded (CWE-434). This could allow an attacker to upload any executable file or other file with malicious code.

Additionally, the creation of the BufferedWriter object is subject to relative path traversal (CWE-23). Since the code does not check the filename that is provided in the header, an attacker can use "../" sequences to write to files outside of the intended directory. Depending on the executing environment, the attacker may be able to specify arbitrary files to write to, leading to a wide variety of consequences, from code execution, XSS (CWE-79), or system crash.

Example 6

This script intends to read a user-supplied file from the current directory. The user inputs the relative path to the file and the script uses Python's os.path.join() function to combine the path to the current working directory with the provided path to the specified file. This results in an absolute path to the desired file. If the file does not exist when the script attempts to read it, an error is printed to the user.

(bad code)

Example Language: Python

import os
import sys
def main():

filename = sys.argv[1]
path = os.path.join(os.getcwd(), filename)
try:

with open(path, 'r') as f:

file_data = f.read()

except FileNotFoundError as e:

print("Error - file not found")

main()

However, if the user supplies an absolute path, the os.path.join() function will discard the path to the current working directory and use only the absolute path provided. For example, if the current working directory is /home/user/documents, but the user inputs /etc/passwd, os.path.join() will use only /etc/passwd, as it is considered an absolute path. In the above scenario, this would cause the script to access and read the /etc/passwd file.

(good code)

Example Language: Python

import os
import sys
def main():

filename = sys.argv[1]
path = os.path.normpath(f"{os.getcwd()}{os.sep}{filename}")
if path.startswith("/home/cwe/documents/"):

try:

with open(path, 'r') as f:

file_data = f.read()

except FileNotFoundError as e:

print("Error - file not found")

main()

The constructed path string uses os.sep to add the appropriate separation character for the given operating system (e.g. '\' or '/') and the call to os.path.normpath() removes any additional slashes that may have been entered - this may occur particularly when using a Windows path. The path is checked against an expected directory (/home/cwe/documents); otherwise, an attacker could provide relative path sequences like ".." to cause normpath() to generate paths that are outside the intended directory (CWE-23). By putting the pieces of the path string together in this fashion, the script avoids a call to os.path.join() and any potential issues that might arise if an absolute path is entered. With this version of the script, if the current working directory is /home/cwe/documents, and the user inputs /etc/passwd, the resulting path will be /home/cwe/documents/etc/passwd. The user is therefore contained within the current working directory as intended.

Selected Observed Examples

Note: this is a curated list of examples for users to understand the variety of ways in which this weakness can be introduced. It is not a complete list of all CVEs that are related to this CWE entry.

Weakness Ordinalities

Detection Methods

Functional Areas

• File Processing

Affected Resources

• File or Directory

Memberships

This MemberOf Relationships table shows additional CWE Categories and Views that reference this weakness as a member. This information is often useful in understanding where a weakness fits within the context of external information sources.

Vulnerability Mapping Notes

Notes

Relationship

Pathname equivalence can be regarded as a type of canonicalization error.

Relationship

Some pathname equivalence issues are not directly related to directory traversal, rather are used to bypass security-relevant checks for whether a file/directory can be accessed by the attacker (e.g. a trailing "/" on a filename could bypass access rules that don't expect a trailing /, causing a server to provide the file when it normally would not).

Terminology

Like other weaknesses, terminology is often based on the types of manipulations used, instead of the underlying weaknesses. Some people use "directory traversal" only to refer to the injection of ".." and equivalent sequences whose specific meaning is to traverse directories.

Other variants like "absolute pathname" and "drive letter" have the *effect* of directory traversal, but some people may not call it such, since it doesn't involve ".." or equivalent.

Research Gap

Many variants of path traversal attacks are probably under-studied with respect to root cause. CWE-790 and CWE-182 begin to cover part of this gap.

Research Gap

Incomplete diagnosis or reporting of vulnerabilities can make it difficult to know which variant is affected. For example, a researcher might say that "..\" is vulnerable, but not test "../" which may also be vulnerable.

Any combination of directory separators ("/", "\", etc.) and numbers of "." (e.g. "....") can produce unique variants; for example, the "//../" variant is not listed (CVE-2004-0325). See this entry's children and lower-level descendants.

Other

In many programming languages, the injection of a null byte (the 0 or NUL) may allow an attacker to truncate a generated filename to apply to a wider range of files. For example, the product may add ".txt" to any pathname, thus limiting the attacker to text files, but a null injection may effectively remove this restriction.

Taxonomy Mappings

References

Content History

Submissions
Submission Date	Submitter	Organization
2006-07-19(CWE Draft 3, 2006-07-19)	PLOVER
Contributions
Contribution Date	Contributor	Organization
2022-07-11	Nick Johnston
Identified weakness in Perl demonstrative example
2024-02-29(CWE 4.15, 2024-07-16)	Abhi Balakrishnan
Provided diagram to improve CWE usability
2024-11-01	Drew Buttner	MITRE
Identified weakness in "good code" for Python demonstrative example
Modifications
Modification Date	Modifier	Organization
2025-09-09(CWE 4.18, 2025-09-09)	CWE Content Team	MITRE
updated Applicable_Platforms, Detection_Factors, Observed_Examples, Potential_Mitigations, References
2025-04-03(CWE 4.17, 2025-04-03)	CWE Content Team	MITRE
updated Relationships
2024-11-19(CWE 4.16, 2024-11-19)	CWE Content Team	MITRE
updated Demonstrative_Examples, Relationships
2024-07-16(CWE 4.15, 2024-07-16)	CWE Content Team	MITRE
updated Common_Consequences, Description, Diagram, Observed_Examples, Other_Notes, References
2023-10-26	CWE Content Team	MITRE
updated Observed_Examples
2023-06-29	CWE Content Team	MITRE
updated Mapping_Notes, Relationships
2023-04-27	CWE Content Team	MITRE
updated Demonstrative_Examples, References, Relationships, Time_of_Introduction
2023-01-31	CWE Content Team	MITRE
updated Common_Consequences, Description, Detection_Factors
2022-10-13	CWE Content Team	MITRE
updated Observed_Examples, References
2022-06-28	CWE Content Team	MITRE
updated Observed_Examples, Relationships
2021-10-28	CWE Content Team	MITRE
updated Observed_Examples, Relationships
2021-07-20	CWE Content Team	MITRE
updated Relationships
2021-03-15	CWE Content Team	MITRE
updated Demonstrative_Examples, Relationships
2020-12-10	CWE Content Team	MITRE
updated Potential_Mitigations, Relationships
2020-08-20	CWE Content Team	MITRE
updated Relationships
2020-06-25	CWE Content Team	MITRE
updated Demonstrative_Examples, Potential_Mitigations
2020-02-24	CWE Content Team	MITRE
updated Potential_Mitigations, Relationships
2019-09-19	CWE Content Team	MITRE
updated Relationships
2019-06-20	CWE Content Team	MITRE
updated Related_Attack_Patterns, Relationships, Type
2019-01-03	CWE Content Team	MITRE
updated References, Related_Attack_Patterns, Relationships, Taxonomy_Mappings
2018-03-27	CWE Content Team	MITRE
updated References, Relationships
2017-11-08	CWE Content Team	MITRE
updated Affected_Resources, Causal_Nature, Likelihood_of_Exploit, References, Relationships, Relevant_Properties, Taxonomy_Mappings
2017-05-03	CWE Content Team	MITRE
updated Demonstrative_Examples
2017-01-19	CWE Content Team	MITRE
updated Related_Attack_Patterns
2015-12-07	CWE Content Team	MITRE
updated Relationships
2014-07-30	CWE Content Team	MITRE
updated Detection_Factors, Relationships, Taxonomy_Mappings
2014-06-23	CWE Content Team	MITRE
updated Other_Notes, Research_Gaps
2013-07-17	CWE Content Team	MITRE
updated Related_Attack_Patterns, Relationships
2013-02-21	CWE Content Team	MITRE
updated Observed_Examples
2012-10-30	CWE Content Team	MITRE
updated Potential_Mitigations
2012-05-11	CWE Content Team	MITRE
updated Demonstrative_Examples, References, Relationships
2011-09-13	CWE Content Team	MITRE
updated Potential_Mitigations, References, Relationships, Taxonomy_Mappings
2011-06-27	CWE Content Team	MITRE
updated Relationships
2011-03-29	CWE Content Team	MITRE
updated Potential_Mitigations
2010-12-13	CWE Content Team	MITRE
updated Potential_Mitigations
2010-09-27	CWE Content Team	MITRE
updated Potential_Mitigations
2010-06-21	CWE Content Team	MITRE
updated Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Potential_Mitigations, References, Relationships
2010-02-16	CWE Content Team	MITRE
updated Alternate_Terms, Applicable_Platforms, Common_Consequences, Demonstrative_Examples, Description, Detection_Factors, Likelihood_of_Exploit, Name, Observed_Examples, Other_Notes, Potential_Mitigations, References, Related_Attack_Patterns, Relationship_Notes, Relationships, Research_Gaps, Taxonomy_Mappings, Terminology_Notes, Time_of_Introduction, Weakness_Ordinalities
2009-07-27	CWE Content Team	MITRE
updated Potential_Mitigations
2008-11-24	CWE Content Team	MITRE
updated Relationships, Taxonomy_Mappings
2008-10-14	CWE Content Team	MITRE
updated Description
2008-09-08	CWE Content Team	MITRE
updated Alternate_Terms, Relationships, Other_Notes, Relationship_Notes, Relevant_Properties, Taxonomy_Mappings, Weakness_Ordinalities
2008-08-15	Veracode
Suggested OWASP Top Ten 2004 mapping
2008-07-01	Eric Dalci	Cigital
updated Potential_Mitigations, Time_of_Introduction
Previous Entry Names
Change Date	Previous Entry Name
2010-02-16	Path Traversal

More information is available — Please edit the custom filter or select a different filter.