CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

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.

Affected languages: Not Language-Specific
Affected technologies: AI/ML
Parent weaknesses: CWE-706, CWE-706

Consequences:
  - Integrity: Execute Unauthorized Code or Commands
  - Integrity: Modify Files or Directories
  - Confidentiality: Read Files or Directories
  - Availability: DoS: Crash, Exit, or Restart

Detection methods:
  - 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
  - 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.
  - Automated Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Highly cost effective: 
                         
                           
  - Manual Static Analysis - Binary or Bytecode: According to SOAR [REF-1479], the following detection techniques may be useful: 
                   
                      Cost effective for partial coverage: 
                         
             

Mitigations:
  - [Implementation] Assume 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 pe
  - [Architecture and Design] For 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-s
  - [Implementation] Inputs 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 i
  - [Architecture and Design] Use 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].

Demonstrative examples:
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.
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:
my $dataPath = "/users/cwe/profiles"; my $username = param("user"); my $profilePath = $dataPath . "/" . $username; 
                      open(my $fh, "<", $profilePath) || ExitError("profile read error: $profilePath"); print "<ul>\n"; while (<$fh>) { print "<li>$_</li>\n"; } print "</ul>\n";
../../../etc/passwd

In the example below, the path to a dictionary file is read from a system property and used to initialize a File object.
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.
String filename = System.getProperty("com.domain.application.dictionaryFile"); File dictionaryFile = new File(filename);

Real-world examples:
  - CVE-2024-37032: Large language model (LLM) management tool does not
               validate the format of a digest value (CWE-1287) from a
               private, untrusted model registry, enabling relative
         
  - CVE-2024-4315: Chain: API for text generation using Large Language Models (LLMs) does
			   not include the "\" Windows folder separator in its denylist (CWE-184)
			   when attempting to prevent Local File Inclusio
  - CVE-2024-0520: Product for managing datasets for AI model training and evaluation allows both relative (CWE-23) and absolute (CWE-36) path traversal to overwrite files via the Content-Disposition header
  - CVE-2022-45918: Chain: a learning management tool debugger uses external input to locate previous session logs (CWE-73) and does not properly validate the given path (CWE-20), allowing for filesystem path traversal u
  - CVE-2019-20916: Python package manager does not correctly restrict the filename specified in a Content-Disposition header, allowing arbitrary file read using path traversal sequences such as "../"