Path Traversal has been in security handbooks for decades, but it keeps showing up in modern applications. Spain’s National Cybersecurity Institute (INCIBE) has dedicated a new study to this vulnerability, classified as CWE-22, and warns that the problem should no longer be associated solely with traditional web applications: microservices, containers, APIs, cloud platforms, and AI systems can also be exposed when they work with paths that can be controlled from the outside.
Path Traversal in 30 seconds
- Path Traversal lets an attacker try to escape an application’s authorized directory by manipulating the paths it processes.
- The risk extends to configuration files, credentials, API keys, logs, and other files accessible to the vulnerable process.
- INCIBE also places the problem in microservices, containers, cloud, REST APIs, and AI-powered applications.
- SAST, DAST, and penetration testing can catch these flaws before they reach production.
- Canonicalizing paths, using allowlists, and applying least privilege are among the main defenses.
The root of the problem will sound familiar to any developer: take in a parameter, use it to build a path, and then access the file system without properly checking where that path actually ends up. A seemingly harmless feature for downloading documents, uploading images, importing files, or selecting a model can end up becoming an entry point.
The INCIBE-CERT study also notes that Path Traversal appears in MITRE’s CWE classification and is related to the access-control issues covered by OWASP. Its persistence shows that modernizing an architecture doesn’t automatically eliminate basic programming errors.
From ../ to Reading Files Outside the Allowed Directory
The classic example is still useful for understanding the flaw.
Say an application stores documents in /var/www/html/documentos/ and receives, via HTTP, the name of the file it should serve. If the program concatenates both strings directly, the user ends up controlling part of the path that the operating system will later resolve.
On Unix and Linux, ../ represents the parent directory. Several consecutive sequences of it can make a relative path escape the intended folder. INCIBE calls this variant relative Path Traversal (CWE-23). There’s also absolute Path Traversal (CWE-36), where an attacker tries to supply a full path directly.
The classic /etc/passwd example is often used because it makes the problem easy to visualize on Linux. If the server process has read permissions and the application doesn’t properly control the path, a manipulated request could get the program to read that file instead of the intended document.
That doesn’t mean Path Traversal grants root access or remote code execution by itself.
Its scope depends on the process’s permissions and the operations available to it. The risk grows when the exposed files contain information that can be used to continue the attack.
A .env file, for example, can store an application’s secrets. A configuration file might contain database credentials. Logs can reveal internal information, and certain files can expose users, paths, services, or operating parameters.
INCIBE therefore considers follow-on scenarios such as access to sensitive information, privilege escalation, and, when Path Traversal is combined with other weaknesses, remote code execution (RCE).
The distinction matters from a technical standpoint: Path Traversal is the mechanism that lets an attacker break through the file system’s intended boundary; the downstream impact depends on what sits on the other side and what permissions the application has.
Cloud, Containers, and AI Don’t Make the Problem Go Away
The most current part of the report comes when INCIBE moves beyond the scenario of a conventional web application.
The agency explicitly points to microservices, containers, cloud platforms, REST APIs, and AI-powered solutions as new environments where paths still need to be handled correctly. That risk is one reason security vendors have started building safeguards specifically for AI agents’ access to enterprise systems, rather than just for the applications themselves.
The reason is simple. Even as the architecture changes, applications still use file systems.
A machine learning service may need to locate models and datasets. An AI platform may manage checkpoints, temporary files, or artifact repositories. An API may retrieve locally stored documents. A microservice may process files uploaded by another component.
Whenever external input directly or indirectly influences one of those paths, an attack surface appears that needs to be controlled.
Containers add an extra layer of isolation, but they don’t turn a vulnerable application into a secure one either. If a compromised process can read certain secrets, mounted volumes, or configuration files within its environment, Path Traversal can be used to reach them.
That’s why INCIBE’s recommendations include restricting the file system to only the resources strictly needed, applying least privilege, and properly isolating the components of distributed or container-based architectures.
It’s a relevant idea for cloud-native architectures: mitigation shouldn’t rely solely on the code that processes the path. The consequences can also be limited by reducing what the process is able to read or modify. Cloud storage systems face that same pressure — Ceph, for one, has had to patch its own CephX and RADOS Gateway vulnerabilities this year, a reminder that access-control flaws don’t disappear just because the storage layer moved to the cloud.
Canonicalize First, Validate Second
One common defensive mistake is turning the protection into a race to spot suspicious strings.
Blocking ../ may look sufficient until different encodings, separators, normalizations, or framework and operating-system behaviors come into play.
As part of its security testing, the report describes using URL or Unicode encodings to check whether filters can be bypassed. It also looks at special characters and historical truncation techniques used against weak controls.
That’s why a more solid strategy is to first determine which resource can be requested and what the real path is that the system will ultimately use.
INCIBE recommends using allowlists whenever possible. If an application only needs to serve a specific set of documents, it can be much safer to work with pre-authorized identifiers or names than to accept any string sent by the client.
Denylists try to recognize everything that could be dangerous. Allowlists flip that logic: they only accept inputs the application already knows about in advance.
When an application needs to work with more flexible paths, canonicalization comes into play.
The goal is to resolve the requested path into its final representation before granting access. It can then be checked that the destination still sits inside the allowed directory.
That way, a string that appears to start from /var/www/html/documentos/ but actually resolves to a location outside it should be rejected before the file is opened. INCIBE illustrates this approach using PHP’s realpath(), though the principle applies to other languages and frameworks too.
SAST and DAST Can Find Two Different Sides of the Same Flaw
The report also frames Path Traversal from the standpoint of the development cycle.
Static Application Security Testing (SAST) lets you review code without running it and locate flows where user-supplied data ends up reaching file operations.
Here, patterns of particular interest include direct path concatenation and calls to read or open functions whose arguments depend on external input.
Dynamic Application Security Testing (DAST) takes a different angle. The application actually runs, and tests manipulate URL parameters, forms, or other inputs to see how the server really responds.
INCIBE adds penetration testing as a third way to evaluate the flaw in a scenario closer to a real attack.
The three approaches complement each other. SAST can uncover potentially dangerous code even before deployment. DAST lets you check the observable behavior of a running application. Pentesting can study how that flaw interacts with permissions, configurations, and other vulnerabilities.
The study also uses labs from PortSwigger’s Web Security Academy and Burp Suite to walk through practical detection and exploitation cases in a controlled environment. One of them looks at how a function used to load images ends up returning a file located outside the expected location.
Zip Slip Takes Path Traversal Inside Compressed Archives
The problem doesn’t necessarily need a visible URL parameter either.
INCIBE covers Zip Slip, a variant that shows up when extracting ZIP, TAR, JAR, and other compressed archives.
Each entry inside a compressed archive can carry information about the path it should be extracted to. If an application trusts that path and doesn’t check the final destination, a manipulated entry could try to write outside the extraction directory.
Depending on the permissions available, that could affect configuration files, libraries, executables, or other resources.
Even though the vector is different, INCIBE identifies the same underlying error: failing to properly validate a path before using it to access the file system. The mitigation again comes down to resolving and canonicalizing the destination, checking that it stays within the authorized location, and running the process with the fewest privileges possible.
This variant is especially relevant for modern services that ingest packages, datasets, plugins, models, backups, or artifacts generated by other systems.
The Last Line of Defense Is Permissions and Monitoring
Secure development should prevent directory traversal from happening in the first place. Even so, limiting privileges reduces what can happen when that first line of defense fails.
INCIBE recommends configuring the web server to restrict directories, disabling unnecessary features, and limiting the process’s access to only the resources it actually needs.
The agency also suggests logging and monitoring file access. A SIEM (Security Information and Event Management) system can help spot anomalous behavior or repeated attempts to access unexpected paths.
Path Traversal illustrates a familiar problem in software security: a modern architecture can still inherit very old vulnerabilities if external data ends up becoming implicit instructions for accessing the system.
Cloud, Kubernetes, containers, or artificial intelligence change where files are located and what they contain. They don’t change the basic rule: an application shouldn’t trust a path just because it arrived through an apparently legitimate API.
Frequently Asked Questions
What’s the difference between relative and absolute Path Traversal?
The relative variant uses references to parent directories to try to escape the intended location. The absolute variant tries to supply a full path directly to another resource on the system. INCIBE maps these to CWE-23 and CWE-36 respectively.
Can Path Traversal happen inside a container?
Yes. Isolation can limit the impact, but a vulnerable application could still access files available to its process inside the container or in the volumes it has mounted. INCIBE recommends combining path validation, isolation, and least privilege.
Is it enough to just block the ../ string?
No, that’s not sufficient on its own. Paths can be represented and processed in different ways, so it’s safer to use allowlists, canonicalize the destination, and check that it stays within the authorized directory.
What tools help detect Path Traversal?
INCIBE covers SAST analysis, DAST testing, and penetration testing. In the study’s practical examples, it also uses Burp Suite and labs from PortSwigger’s Web Security Academy to analyze requests and responses in a controlled environment.
