Official definition

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. (Roles: Common-Name, Attack-Focused, Attack-Focused)

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.

Detailed description

Many file operations are intended to remain within a restricted directory. Special elements such as .. and / can cause the operating system to resolve the pathname elsewhere; the common ../ form is relative path traversal. Absolute pathnames such as /usr/local/bin are also relevant because they can bypass the intended base directory.

The impact depends on the file operation controlled by the pathname. An unsafe path may permit unexpected file reads, creation or overwriting of critical files, deletion or corruption, access to the process filesystem, or interaction with files used for security mechanisms and code execution. Validation must occur after decoding and canonicalizing the representation that the application will actually use, and the final path must be verified to remain within the permitted directory.

Characteristics

The weakness occurs when external data participates in pathname construction without being properly constrained to the intended parent directory. Relative elements such as ../ can move resolution to a parent directory, while absolute pathnames such as /usr/local/bin can bypass the intended base location. It can affect many file operations, including reading, writing, creation, deletion, extraction, and execution; repeated decoding, incomplete canonicalization, alternate separators, or client-only validation can undermine protection.

Common consequences

The record identifies impacts across confidentiality, integrity, and availability. An attacker may read unexpected files and disclose sensitive information; create or overwrite programs, libraries, important data, or security files; bypass security mechanisms; or cause denial of service by deleting, corrupting, or replacing critical files. In relevant cases, overwriting files used for code execution may enable unauthorized code or command execution, and damage to authentication or other protection mechanisms may prevent legitimate users from accessing the product.

Impact	Scope	Explanation
Execute Unauthorized Code or Commands	Integrity, Confidentiality, Availability	The attacker may be able to create or overwrite critical files that are used to execute code, such as programs or libraries.
Modify Files or Directories	Integrity	The attacker may be able to overwrite or create critical files, such as programs, libraries, or important data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, appending a new account at the end of a password file may allow an attacker to bypass authentication.
Read Files or Directories	Confidentiality	The attacker may be able to read the contents of unexpected files and expose sensitive data. If the targeted file is used for a security mechanism, then the attacker may be able to bypass that mechanism. For example, by reading a password file, the attacker could conduct brute force password guessing attacks in order to break into an account on the system.
DoS: Crash, Exit, or Restart	Availability	The attacker may be able to overwrite, delete, or corrupt unexpected critical files such as programs, libraries, or important data. This may prevent the product from working at all and in the case of protection mechanisms such as authentication, it has the potential to lock out product users.

Risk mitigations

Validate against an allowlist. Treat all external input as malicious and accept only values that strictly conform to the required syntax, type, length, range, and business rules. For filenames, use a stringent character allowlist, preferably permitting only a single . where feasible, exclude directory separators such as /, and restrict extensions to an approved set. Do not rely solely on denylists or character removal, since alternate separators and other representations may bypass them.

Canonicalize before validation. Decode and canonicalize input once into the application’s internal representation before applying validation. Use a built-in canonicalization routine, such as realpath in C, getCanonicalPath in Java, GetFullPath in ASP.NET, realpath or abs_path in Perl, and realpath in PHP, and ensure the resulting path remains within the intended directory.

Enforce checks on the server. Duplicate client-side security checks on the server because attackers can alter client values or remove client checks. Prefer vetted libraries or frameworks that provide safe path-handling constructs. When the set of valid files or URLs is known, map fixed identifiers to those objects and reject all other inputs.

Limit impact and exposure. Run with the least privileges required, preferably using isolated accounts. Use a sandbox or jail such as chroot, AppArmor, SELinux, or applicable managed-code file permissions, while recognizing that this may only reduce impact and must be configured carefully. Store libraries, include files, and utility files outside the web document root where possible, or restrict direct web access to them.

Add operational defenses. An application firewall can provide defense in depth or temporary protection when the code cannot immediately be fixed, but it may miss input vectors, be bypassed, or reject legitimate requests. Keep error messages minimal and avoid disclosing filesystem paths; record necessary detail in protected logs. In PHP, do not use register_globals and do not create an unsafe emulation of it.

Input Validation · ImplementationAssume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright. When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single "." character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as "/" to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434. Do not rely exclusively on a filtering mechanism that removes potentially dangerous characters. This is equivalent to a denylist, which may be incomplete (CWE-184). For example, filtering "/" is insufficient protection if the filesystem also supports the use of "\" as a directory separator. Another possible error could occur when the filtering is applied in a way that still produces dangerous data (CWE-182). For example, if "../" sequences are removed from the ".../...//" string in a sequential fashion, two instances of "../" would be removed from the original string, but the remaining characters would still form the "../" string.
Architecture and DesignFor any security checks that are performed on the client side, ensure that these checks are duplicated on the server side, in order to avoid CWE-602. Attackers can bypass the client-side checks by modifying values after the checks have been performed, or by changing the client to remove the client-side checks entirely. Then, these modified values would be submitted to the server.
Input Validation · ImplementationInputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180). Make sure that the application does not decode the same input twice (CWE-174). Such errors could be used to bypass allowlist validation schemes by introducing dangerous inputs after they have been checked. Use a built-in path canonicalization function (such as realpath() in C) that produces the canonical version of the pathname, which effectively removes ".." sequences and symbolic links (CWE-23, CWE-59). This includes: - realpath() in C - getCanonicalPath() in Java - GetFullPath() in ASP.NET - realpath() or abs_path() in Perl - realpath() in PHP
Libraries or Frameworks · Architecture and DesignUse a vetted library or framework that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid [REF-1482].
Firewall · Operation · Effectiveness: ModerateUse an application firewall that can detect attacks against this weakness. It can be beneficial in cases in which the code cannot be fixed (because it is controlled by a third party), as an emergency prevention measure while more comprehensive software assurance measures are applied, or to provide defense in depth [REF-1481].An application firewall might not cover all possible input vectors. In addition, attack techniques might be available to bypass the protection mechanism, such as using malformed inputs that can still be processed by the component that receives those inputs. Depending on functionality, an application firewall might inadvertently reject or modify legitimate requests. Finally, some manual effort may be required for customization.
Environment Hardening · Architecture and Design, OperationRun your code using the lowest privileges that are required to accomplish the necessary tasks [REF-76]. If possible, create isolated accounts with limited privileges that are only used for a single task. That way, a successful attack will not immediately give the attacker access to the rest of the software or its environment. For example, database applications rarely need to run as the database administrator, especially in day-to-day operations.
Enforcement by Conversion · Architecture and DesignWhen the set of acceptable objects, such as filenames or URLs, is limited or known, create a mapping from a set of fixed input values (such as numeric IDs) to the actual filenames or URLs, and reject all other inputs. For example, ID 1 could map to "inbox.txt" and ID 2 could map to "profile.txt". Features such as the ESAPI AccessReferenceMap [REF-185] provide this capability.
Sandbox or Jail · Architecture and Design, Operation · Effectiveness: LimitedRun the code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which files can be accessed in a particular directory or which commands can be executed by the software. OS-level examples include the Unix chroot jail, AppArmor, and SELinux. In general, managed code may provide some protection. For example, java.io.FilePermission in the Java SecurityManager allows the software to specify restrictions on file operations. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of the application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.The effectiveness of this mitigation depends on the prevention capabilities of the specific sandbox or jail being used and might only help to reduce the scope of an attack, such as restricting the attacker to certain system calls or limiting the portion of the file system that can be accessed.
Attack Surface Reduction · Architecture and Design, OperationStore library, include, and utility files outside of the web document root, if possible. Otherwise, store them in a separate directory and use the web server's access control capabilities to prevent attackers from directly requesting them. One common practice is to define a fixed constant in each calling program, then check for the existence of the constant in the library/include file; if the constant does not exist, then the file was directly requested, and it can exit immediately. This significantly reduces the chance of an attacker being able to bypass any protection mechanisms that are in the base program but not in the include files. It will also reduce the attack surface.
ImplementationEnsure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not. In the context of path traversal, error messages which disclose path information can help attackers craft the appropriate attack strings to move through the file system hierarchy.
Environment Hardening · Operation, ImplementationWhen using PHP, configure the application so that it does not use register_globals. During implementation, develop the application so that it does not rely on this feature, but be wary of implementing a register_globals emulation that is subject to weaknesses such as CWE-95, CWE-621, and similar issues.

Detection methods

Detection can use several layers: automated or manual static analysis of source code, binaries, and bytecode; architecture and design review; and dynamic analysis with web application, web services, and database scanners, fuzz testers, and framework-based fuzzers. The record rates automated and manual static analysis, source-code analysis, dynamic testing, and architecture review as highly effective; manual binary or bytecode analysis provides partial coverage according to SOAR. Automated tools may need tuning to de-prioritize cases exploitable only by administrators or other privileged users, while manual methods can be constrained by time and coverage.

Method	Approach	Effectiveness
Automated Static Analysis	Automated techniques can find areas where path traversal weaknesses exist. However, tuning or customization may be required to remove or de-prioritize path-traversal problems that are only exploitable by the product's administrator - or other privileged users - and thus potentially valid behavior or, at worst, a bug instead of a vulnerability.	High
Manual Static Analysis	Manual white box techniques may be able to provide sufficient code coverage and reduction of false positives if all file access operations can be assessed within limited time constraints.	High
Automated Static Analysis - Binary or Bytecode	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Bytecode Weakness Analysis - including disassembler + source code weakness analysis ``` Cost effective for partial coverage: ``` Binary Weakness Analysis - including disassembler + source code weakness analysis	High
Manual Static Analysis - Binary or Bytecode	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Cost effective for partial coverage: ``` Binary / Bytecode disassembler - then use manual analysis for vulnerabilities & anomalies	SOAR Partial
Dynamic Analysis with Automated Results Interpretation	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Web Application Scanner Web Services Scanner Database Scanners	High
Dynamic Analysis with Manual Results Interpretation	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Fuzz Tester Framework-based Fuzzer	High
Manual Static Analysis - Source Code	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Manual Source Code Review (not inspections) ``` Cost effective for partial coverage: ``` Focused Manual Spotcheck - Focused manual analysis of source	High
Automated Static Analysis - Source Code	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Source code Weakness Analyzer Context-configured Source Code Weakness Analyzer	High
Architecture or Design Review	According to SOAR [REF-1479], the following detection techniques may be useful: ``` Highly cost effective: ``` Formal Methods / Correct-By-Construction ``` Cost effective for partial coverage: ``` Inspection (IEEE 1028 standard) (can apply to requirements, design, source code, etc.)	High

Representative vulnerabilities

The following are representative examples, not an exhaustive list:

CVE-2024-37032: an LLM management tool failed to validate a digest value from an untrusted private model registry, enabling relative path traversal.
CVE-2024-4315: a text-generation API omitted the Windows folder separator \ from its denylist, allowing arbitrary file deletion on Windows.
CVE-2024-0520: an AI training and evaluation dataset product permitted relative and absolute path traversal through a Content-Disposition header, enabling file overwrites.
CVE-2022-31503: a Python package used os.path.join with untrusted input, allowing an absolute input path to replace the intended pathname.
CVE-2022-24877: a Go-based Kubernetes operator allowed access to data in the controller pod’s filesystem through ../ sequences in a YAML file.
CVE-2021-21972: a chain in a virtualization platform allowed an unauthenticated tar upload and then used .. traversal to access unexpected files; the record notes exploitation in the wild.
CVE-2020-4053 and CVE-2019-10743: Kubernetes-related or archive packages allowed files in a plugin or ZIP archive to be written outside the target directory, commonly called “Zip Slip”.
CVE-2019-20916: a Python package manager allowed arbitrary file reads through traversal sequences in a Content-Disposition header.
CVE-2010-0467, CVE-2009-4194, CVE-2009-4053, CVE-2009-0244, and CVE-2009-4013: examples include arbitrary file reading, deletion, directory creation, directory listing, and file overwriting using .. or ../.
CVE-2009-4581, CVE-2008-5748, CVE-2006-7079, and CVE-2020-3452: chains involving includes, externally controlled values, a register_globals compatibility layer, or improper input validation led to path traversal and, in some cases, code execution or file access.

Below are representative vulnerabilities related to this CWE, prioritized by severity.

Sources (2)

MITRE CWE

CWE Terms of Use

CWE-22: Improper Limitation of a Pathname to a Restricted Directory

What is CWE-22?

Vulnerabilities mapped to CWE-22

Vulnerabilities in CISA KEV for CWE-22

Official definition

Detailed description

Characteristics

Common consequences

Risk mitigations

Detection methods

Representative vulnerabilities

Supporting documents

Run an in-depth assessment with complete web risk management

Explore more resources from CyStack

Website security reports

CyStack research

Cybersecurity knowledge