67
CWE-32: Path Traversal: '...' (Triple Dot)
Weakness ID : 32
Structure : Simple
Abstraction : Variant
Description
The product uses external input to construct a pathname that should be within a restricted
directory, but it does not properly neutralize '...' (triple dot) sequences that can resolve to a location
that is outside of that directory.
Extended Description
This allows attackers to traverse the file system to access files or directories that are outside of the
restricted directory.
The '...' manipulation is useful for bypassing some path traversal protection schemes. On some
Windows systems, it is equivalent to "..\.." and might bypass checks that assume only two dots
are valid. Incomplete filtering, such as removal of "./" sequences, can ultimately produce valid ".."
sequences due to a collapse into unsafe value (CWE-182).
Relationships
The table(s) below shows the weaknesses and high level categories that are related to this
weakness. These relationships are defined as ChildOf, ParentOf, MemberOr 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 may want to be explored.
Relevant to the view "Research Concepts" (CWE-1000)
Nature Type ID Name Page
ChildOf 23 Relative Path Traversal 46
Applicable Platforms
Language : Not Language-Specific (Prevalence = Undetermined)
Common Consequences
Scope Impact Likelihood
Confidentiality
Integrity
Read Files or Directories
Modify Files or Directories
Potential Mitigations
Phase: Implementation
Strategy = Input Validation
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 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
CWE Version 4.14
CWE-32: Path Traversal: '...' (Triple Dot)
CWE-32: Path Traversal: '...' (Triple Dot)