Path Traversal LFI Bug Bounty 2026 — Directory Traversal, proc Leaks & Log Poison | BB Day 27

What Path Traversal and LFI Actually Are (And Why They’re Still Paying Critical in 2026)

Here’s what’s happening at the server level. The application takes a filename from user input — a URL parameter, a POST field, a cookie — and passes it directly to a file-reading or file-including function without validating that the resolved path stays inside the intended directory. That’s it. The entire vulnerability class in one sentence.

Path traversal and local file inclusion are two expressions of the same root cause, but they behave differently in exploitation:

Path traversal means the application reads and returns the file contents in the HTTP response — think readFile() in Node or file_get_contents() in PHP. You get the raw content of whatever file you point it at. The payload is the classic ../../../etc/passwd sequence — each ../ climbs one directory level toward the filesystem root.

LFI (local file inclusion) means the application uses the input to include a PHP file and execute it — include(), require(), include_once(). This is more powerful because it doesn’t just read files — it runs them. That’s the primitive that enables log poisoning to RCE, which we’ll cover in full later today.

Why are these bugs still paying Critical in 2026? Three reasons I see repeatedly on engagements:

Legacy codebases never got refactored. A PHP application built in 2011 with include($_GET['page'] . '.php') might now be running inside a Docker container with a modern WAF in front — but the vulnerable code is still there, unchanged, because it’s never been touched.

Cloud file systems introduced new attack surfaces. Applications mounting S3 buckets, NFS shares, or Azure File shares often pass paths through the same kind of unvalidated parameter that classic path traversal exploits. The exploitation mechanic is identical.

Containerised apps leak more than you’d expect. In a container, /proc/self/environ is loaded with injected secrets — Kubernetes secrets, environment-variable-injected API tokens, database credentials — that never appear in the application’s config files. Path traversal into /proc gives you the container’s entire secret store.

The null byte trick (%00) used to be the way you stripped a mandatory file extension appended by the server — ../../../etc/passwd%00 would terminate the string before .php got appended. PHP fixed this in 5.3.4, but you still see it succeed on older deployments. PHP wrappers like php://filter/convert.base64-encode/resource= are the modern equivalent — they bypass extension requirements entirely and return source code base64-encoded. We’ll hit those in the filter bypass section.

Recon: How I Find Traversal Parameters Before I Ever Send a Payload

The parameter is there before you send a single ../. The recon phase is about finding it — and most hunters skip this step and go straight to spraying payloads at random endpoints. That’s why they miss it.

These are the parameter names I look for first, in order of how often I’ve seen them vulnerable in real programs:

file= · page= · template= · lang= · doc= · path= · include= · load= · read= · view= · content= · module= · conf=

Any parameter whose value currently looks like a filename — page=home, template=invoice, lang=en — is a candidate. If the server is using that value to construct a filesystem path, traversal might work.

Step 1 — Burp passive crawl. Browse the entire application with Burp Proxy active. Don’t touch anything yet. After ten minutes of normal use, open Target → Site Map, right-click the host, and filter by parameters. Look for any GET or POST parameter whose value looks like a path fragment, a filename, or a language code.

Step 2 — JavaScript endpoint mining. Download every JS file Burp captured. Grep them for the parameter names above plus string literals containing /api/, static/, assets/, or download/. JS files routinely expose internal API endpoints that never appear in the HTML — and those endpoints often have less validation than the front-facing ones.

Step 3 — Wayback Machine parameter archaeology. Historical snapshots capture URL structures that may have been removed from the live site but still work on the server. Check web.archive.org/web/*/target.com/*file=* — the asterisk wildcard in Wayback’s URL search is your best friend here.

Step 4 — Google dorks. Classic patterns that surface file-serving endpoints:

Step 5 — ffuf parameter fuzzing. When you know an endpoint exists but can’t see the parameter name, fuzz it. Use the SecLists burp-parameter-names.txt wordlist against the endpoint:

Use the SecurityElites Tools hub for additional recon resources — the WHOIS lookup and DNS tools there help you map the full scope of a target’s infrastructure before you start parameter hunting.

🛠️ EXERCISE 1 — BROWSER (20 MIN · NO INSTALL)

This is pure recon practice — no tools, no Burp, just your browser and Google. The goal is to find three live applications with file-serving parameters and confirm basic traversal response behaviour. Recon is where the bug is found or missed. Get this right and the rest of the chain is straightforward.

Filter Bypass: Every WAF and Developer Defence I’ve Broken on Path Traversal

The basic ../../../etc/passwd payload gets blocked by almost every WAF and most developer-written input filters in 2026. That’s fine. There are about a dozen encoding variants that bypass those filters, and I’ve broken each of them on real targets. Here’s the complete menu.

Why filters fail. Most filters work by looking for the string ../ or .. in the raw input. They check the raw URL-decoded value, or they decode once and check, or they strip the sequence and don’t re-validate. Each of those approaches has a bypass.

Double URL encoding. The server decodes twice — once at the WAF layer and once at the application layer. The WAF sees ..%252F, decodes %25 to %, checks for traversal — doesn’t find ../ — passes it through. The application decodes %2F to / and gets ../. Bypass complete.

Unicode/overlong encoding. The / character can be represented as %c0%af (overlong UTF-8 encoding). Older Java containers and some Python frameworks accept this. ..%c0%af..%c0%afetc%c0%afpasswd is worth trying against any Java stack.

Nested traversal sequences. If the filter strips ../ but doesn’t loop — it only removes it once — then ....// becomes ../ after the first strip. The payload ....//....//....//etc/passwd works against naive single-pass strip filters.

Absolute path injection. Skip the traversal entirely. If the application passes your input directly to an open() call without prepending a base directory, you can inject /etc/passwd directly — no ../ needed. This works more often than you’d expect on Node.js apps.

PHP wrapper bypass. When the application appends .php to your input — include($page . '.php') — the classic approach is the null byte (%00), but that’s patched in modern PHP. The modern bypass is php://filter/convert.base64-encode/resource=/etc/passwd. This ignores extension checking entirely and returns the file base64-encoded.

/proc Leaks: What the Linux Process Filesystem Hands You on a Plate

Most hunters find /etc/passwd and stop. That’s the High. The Critical is in /proc.

The Linux /proc filesystem is a virtual filesystem — it doesn’t exist on disk, it’s generated by the kernel at runtime. Every running process gets a directory at /proc/[PID]/. The web application process can always read its own files via the /proc/self/ shortcut — no PID enumeration needed. And those files contain things no one expects you to be able to read.

/proc/self/environ — This is the one I go for first, every time. It contains every environment variable the process was started with, in a null-byte-delimited string. In containerised deployments — Docker, Kubernetes, ECS — the application’s secrets are injected as environment variables. I’ve pulled AWS access keys, Stripe secret keys, Django SECRET_KEY values, database connection strings with passwords, and internal API tokens from this single file. Finding a SECRET_KEY here means you can forge any session cookie in the application. Finding an AWS key here means you’re in the cloud account.

/proc/self/cmdline — The full command line the process was invoked with, null-byte-delimited. This tells you the exact binary path, the config files it loaded, and any flags passed at startup — including database passwords passed as command-line arguments (still happens in legacy deployments).

/proc/self/fd/ — A directory of symbolic links, one per open file descriptor. /proc/self/fd/0 is stdin, /proc/self/fd/1 stdout, /proc/self/fd/2 stderr — and then the application’s actual open files start. These symlinks resolve to real filesystem paths. Enumerating /proc/self/fd/4, /proc/self/fd/5, etc. tells you exactly which log files, config files, and database socket files the application has open. This is how you find the log file path for log poisoning without guessing.

/proc/self/maps — The memory map of the process. Useful for identifying which shared libraries are loaded — relevant if you’re chaining into a binary exploitation path (rare in bug bounty, but documented).

/proc/version — Kernel version. Tells you the exact Linux kernel build. Cross-reference with public kernel exploits for privilege escalation chain research (document in report, don’t execute).

/proc/net/tcp — Active TCP connections in hex format. Shows you internal services listening on 127.0.0.1 — databases, cache servers, internal APIs — that aren’t visible from the outside. This maps the internal network for your report’s attack impact section.

The information chain from /proc/self/environ runs like this: environment variables → secret keys → session forgery / API takeover → privilege escalation. Each step in that chain raises the CVSS score. A path traversal that only reaches /etc/passwd is typically CVSS 7.5 (High). The same path traversal that reaches /proc/self/environ and yields an AWS root key is CVSS 9.8 (Critical). The Day 15 Business Logic module covers how impact chaining like this affects payout tiers — the same principle applies here.

🌐 EXERCISE 2 — PORTSWIGGER WEB SECURITY ACADEMY (35 MIN)

Log Poisoning: How LFI Becomes Remote Code Execution

This is the section that earns Critical reports. Every LFI finding starts at High — roughly CVSS 7.5 — when all you can do is read /etc/passwd. Log poisoning takes that exact same vulnerability to CVSS 9.8 and puts a webshell on the server. The chain is four steps, and I’ll walk you through each one exactly as I run it on engagements.

The chain: identify LFI → locate a readable log file → inject PHP code into a request header the server logs → include that log via LFI to trigger execution.

The most common log target is Apache’s access.log. Every request the server receives gets written there — including the User-Agent header. If the app has LFI and Apache is running, you can write PHP into the User-Agent, then include the log file, and Apache executes your code.

Other injectable log files: /var/log/auth.log (inject via SSH username field — connect with a PHP string as your username), mail logs (inject via RCPT TO), and /proc/self/fd/ entries for any log fd the process currently has open. The access.log route is fastest — the auth.log route works on servers where Apache logs are locked down to root.

PHP Wrappers: The LFI Upgrade That Most Hunters Miss

Most hunters find an LFI, read /etc/passwd, and call it High. The hunters who earn Critical bounties keep going — into PHP stream wrappers. These are built-in PHP URI schemes that transform what LFI can do. Instead of just reading static files, you can read PHP source before it executes, inject code directly, or run commands without touching the filesystem at all.

php://filter/convert.base64-encode/resource= — this is the one you’ll use most. PHP source files execute when included, so you never see the code — you only see the output. The filter wrapper reads the file, base64-encodes it, and returns the encoded string instead of executing it. You decode it locally and read the full source.

php://input — when allow_url_include is enabled, this wrapper passes your POST body directly as PHP code to execute. Send a POST request with <?php system('id'); ?> as the body and page=php://input as the parameter. Instant RCE if the server allows it.

data:// — inline data injection. data://text/plain;base64,PD9waHAgc3lzdGVtKCdpZCcpOyA/Pg== passes base64-encoded PHP inline. Works when the app includes the parameter value as a URI.

expect:// — direct command execution when the PHP expect extension is loaded. Rare in modern environments, but worth testing: page=expect://id. When it works, it’s immediate RCE with zero setup.

⚡ EXERCISE 3 — KALI TERMINAL + BURP SUITE (40 MIN)

You Just Learned the Full Path Traversal and LFI Attack Chain

Here’s what today built: a complete, end-to-end attack chain that takes a single vulnerable file parameter from information disclosure all the way to Remote Code Execution. You started with parameter discovery using ffuf, moved through filter bypass techniques, read sensitive data from /proc/self/environ, poisoned Apache’s access log with a PHP webshell, and read PHP source via stream wrappers to find hardcoded credentials.

That chain is not theoretical. I’ve run every step of it on real engagements — and the log poisoning escalation specifically has landed Critical reports on targets where the client believed their LFI was “already mitigated” because they’d blocked ../. Absolute path bypass, wrapper abuse, and fd-based log discovery are what separate a $200 Informational from a $6,500 Critical.

Day 28 goes into lateral movement — what happens after you have that initial foothold, how attackers move through a network, and how bug bounty hunters document pivot-capable findings responsibly. Keep your Bug Bounty Course progress going. The path traversal LFI bug bounty skillset you built today is one of the highest-value chains in the OWASP Top 10 — and it shows up in real programs every week.