Percent-Encoded Path Traversal

How percent-encoded path traversal works

Percent-encoded path traversal is a normalization bypass. The attacker sends encoded separators or dot segments, such as %2e and %2f, so the application sees a harmless-looking path before decoding, while the server or filesystem later interprets it as a real traversal sequence.

That mismatch matters because security checks are often performed on the raw request, not the canonical path that the storage layer eventually uses. When decoding happens in a different layer, or at a different point in the request pipeline, the application may fail to notice that the path escapes the intended web root.

The result is not limited to one encoding style. Defenders should think in terms of canonicalisation, because traversal may appear through mixed encodings, double decoding, or alternate path representations that survive initial validation.

Why encoded traversal is dangerous

Encoded traversal can expose configuration files, source code, logs, backup archives, and other sensitive resources that were never meant to be web-accessible. Path Traversal Guide covers the broader file-access failure modes behind these attacks, including archive extraction and tooling cases.

It is especially dangerous when an application builds file paths from user input, then tries to block dangerous segments with simple string matching. Encoding gives the attacker a way to hide the true meaning of the request until after the check has already happened.

This is why path traversal often pairs with local file inclusion, forced browsing, or other file-access flaws. Once the attacker can steer the resolver outside the expected directory, the security boundary becomes the server’s path handling logic rather than the web application’s intended access rules.

For a broader catalogue of web attack patterns, Web Application Attacks Guide is a useful companion reference because it places traversal alongside related input-handling failures.

How organisations check exposure

Exposure review starts with identifying every endpoint that accepts a path, filename, archive member name, template reference, or download parameter. The question is not just whether the feature exists, but whether the application decodes, normalises, and validates input in the same order as the underlying platform.

Teams should test public-facing and internal routes, especially file download handlers, document viewers, image proxies, build tools, and any API that maps input to the filesystem. They should also review vendor advisories and framework documentation because traversal bugs often arise from framework defaults, helper functions, or middleware assumptions rather than obvious custom code.

Operationally, logs matter. Requests containing encoded separators, repeated dots, unusual slash forms, or decode-and-resolve mismatches are common indicators that traversal testing or exploitation is underway. Web Server Access Log Detection Guide is relevant here because access logs are often the first place these probes become visible.

For teams working in access-control-heavy application design, OWASP Top 10 A01 Guide helps connect traversal to the wider problem of broken server-side enforcement.

Prevention and remediation patterns

The safest pattern is to resolve paths once, using platform-safe file APIs, and compare the canonical result against an allowed base directory. Validation should happen after decoding and normalisation, not before, and it should be based on allowlists and root confinement rather than blacklist fragments.

Where patching or refactoring is not immediate, compensating controls should reduce blast radius. That includes restricting filesystem permissions, isolating the web process from sensitive directories, disabling unnecessary file-serving features, and preventing the application from reaching secrets, backups, or administrative paths in the first place.

In platform-specific code, secure defaults matter. Go Secure Coding Guide and Kotlin and Android Secure Coding Guide both reflect the same principle in different stacks: treat user-controlled paths as untrusted data until the final file operation is safely bounded.

Where reverse proxies or gateways rewrite paths, NGINX Security Hardening Guide is relevant because path handling can change before the request reaches the application.

Detection and post-incident review

Detection should look for both probing and confirmed access. Repeated requests with encoded dots or slashes, attempts to reach parent directories, and unexpected retrieval of static files from sensitive locations are all strong indicators. Review should extend beyond the vulnerable request itself, because successful traversal may lead to credential theft, source disclosure, or access to configuration material that enables later compromise.

After patching, organisations should check whether the attack exposed sessions, API keys, database passwords, private keys, or other sensitive file-backed material. If the traversal reached secrets, the incident response should include rotation and validation of anything that could have been read, not just the code fix. The review should also confirm that logs captured the full request path and decoding behaviour needed for forensic reconstruction.

Where accessible, filesystem and web-server telemetry should be correlated. Path Traversal Guide and Web Server Access Log Detection Guide together support that review by connecting exploit mechanics to observable request patterns and server-side evidence.

Related resources from NHI Mgmt Group

• Why do path traversal bugs create identity and secrets risk?
• What do security teams get wrong about path traversal in file upload handlers?
• Where do path traversal flaws become especially dangerous in command tooling?
• What breaks when a container download endpoint allows path traversal?