CWE-22 is the Common Weakness Enumeration entry for path traversal. It describes failures to properly restrict a pathname to a safe directory boundary. Security teams use it to classify, triage, and track flaws where untrusted input can escape the intended file system scope.
Expanded Definition
CWE-22 refers to path traversal, a weakness where untrusted input is used to build a file path without sufficiently constraining it to the intended directory. In practice, the flaw appears when applications concatenate user-controlled names, file references, or upload paths and then trust the resulting pathname.
Within NHI and agentic AI systems, path traversal matters because service accounts, bots, and agents often read logs, templates, payloads, or cache files with broad filesystem permissions. The issue is not limited to web forms; it also shows up in job runners, internal APIs, and automation scripts that accept filenames or archive paths. Guidance across vendors is consistent on the core problem, but implementation detail varies on whether the control should be expressed as canonicalisation, allowlisting, sandboxing, or rooted file access.
Standards-oriented practice is to treat the filesystem boundary like an authorization boundary, aligning with the intent of the NIST Cybersecurity Framework 2.0 for access control and safe system design. The most common misapplication is assuming a filename is safe because it came from an internal workflow, which occurs when automation passes attacker-influenced input into path-joining logic without canonicalization checks.
Examples and Use Cases
Implementing path handling rigorously often introduces friction, because teams must balance flexible file workflows against strict validation, normalization, and permission boundaries.
- An upload service receives a filename and must reject attempts to escape the storage root, even if the request came from an authenticated NHI.
- A CI/CD pipeline writes build artifacts to disk and validates that archive extraction cannot overwrite files outside the workspace.
- A support bot or agent reads customer attachments and is confined to a sandboxed directory so it cannot enumerate host files.
- An internal API maps document IDs to files and uses canonical path resolution before any read or delete operation.
- A scheduled job opens configuration files and applies allowlisted directory roots instead of trusting relative paths from environment variables.
For broader identity governance context, NHI Management Group notes in the Ultimate Guide to NHIs that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools. That matters because the same automation surfaces that mishandle secrets often also mishandle file paths. When teams are validating secret placement or rotation workflows, they should also verify that file reads and writes stay inside intended directories, a pattern that aligns with the access-control intent in NIST Cybersecurity Framework 2.0.
Why It Matters in NHI Security
Path traversal becomes especially dangerous when an NHI has broad filesystem access, because a single traversal flaw can expose credentials, configuration files, deployment artifacts, or logs that reveal downstream secrets. In agentic environments, the risk extends to tool outputs and local working directories, where an AI agent may be able to read or overwrite files outside its assigned scope if the application does not enforce rooted paths.
The operational problem is not just data exposure. It can also become a privilege boundary failure, where an otherwise low-trust workflow gains access to higher-value assets through the filesystem. NHI Management Group’s Ultimate Guide to NHIs reports that 97% of NHIs carry excessive privileges, which makes filesystem mistakes far more damaging when they occur. Preventing CWE-22 therefore supports least privilege, environment isolation, and safer incident containment.
Organisations typically encounter the consequence only after an exposed file, leaked secret, or overwritten artifact is discovered in production, at which point CWE-22 becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-07 | Path traversal often exposes NHI secrets, configs, and tokens through unsafe file access. |
| OWASP Agentic AI Top 10 | A-04 | Agent tool use can turn unsafe path handling into unintended filesystem reach. |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access should limit which directories NHI workflows can touch. |
| NIST Zero Trust (SP 800-207) | SC-7 | Zero trust relies on enforced boundaries, including storage and file access paths. |
| NIST AI RMF | AI systems that read or write files need risk controls around unsafe tool and data access. |
Map file-system permissions to least privilege and review directory access as part of access governance.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
