Re: Path Normalization Bypass via URL-Encoded Traversal in Envoy Edge Proxy

[Yan Avlasov]

Hello Zhafran. Thanks for the responsible report. The issue here is that VRP config for the edge proxy does not enable normalize_path as recommended in the Envoy best practices: https://www.envoyproxy.io/docs/envoy/latest/configuration/best_practices/edge

I will update the VRP config so that it has normalize_path enabled. Otherwise the prefix based routing will not work well.

Yan

On Mon, Jan 12, 2026 at 7:26 PM ZHAFRAN DZAKY <zakza...@gmail.com> wrote:

Detail

A path normalization bypass vulnerability exists in the Edge Envoy routing configuration used in the Google VRP Envoy test environment.

The Edge Envoy proxy is configured to allow requests only for paths matching the /content/* prefix and to deny access to restricted paths such as /blockedz Direct requests to /blockedz correctly return an HTTP 403 Forbidden response.

However, when URL-encoded path traversal sequences such as %2e%2e (encoded ..) are included in the request path, the Edge Envoy fails to properly normalize the path before performing route matching. As a result, the proxy incorrectly treats the encoded traversal as part of the allowed /content/* path and forwards the request to the upstream Origin Envoy.

This behavior allows attackers to access restricted upstream endpoints by bypassing the intended routing policy.

PoC
Expected behavior

curl -k -i https://localhost:10000/blockedz

 
Response:

HTTP/1.1 403 Forbidden
denied

Bypass using single URL encoding

curl -k -i https://localhost:10000/content/%2e%2e/blockedz

Response:

HTTP/1.1 200 OK
content-type: text/plain
normal

 The request is incorrectly routed to the upstream service, despite resolving to a restricted path.

Attack Scenario

An unauthenticated remote attacker sends a crafted HTTP request to the Edge Envoy proxy using URL-encoded traversal sequences.

Because the Edge Envoy does not fully normalize the request path before applying routing rules, the malicious request matches an allowed route and is forwarded upstream. The upstream service then resolves the path to a restricted endpoint, granting unauthorized access.

In a real-world deployment, this type of attack could be used to:

• Access internal or administrative endpoints

• Reach services intended to be isolated behind routing boundaries

• Bypass security controls that rely solely on prefix-based routing- 

Impact

• Unauthorized access to upstream-only endpoints

• Violation of security assumptions enforced by Envoy routing rules

• Increased risk of exposure for internal APIs or protected services

• Potential stepping stone for further attacks depending on upstream functionality

Conclusion

The vulnerability is caused by incomplete path normalization in the Edge Envoy proxy prior to route matching. URL-encoded traversal sequences are not resolved before routing decisions are made, allowing restricted paths to be accessed through crafted requests.

This issue demonstrates that relying on prefix-based routing without strict canonicalization of request paths can lead to serious security bypasses. Proper normalization and validation of URL paths should be enforced before applying routing policies to ensure consistent and secure request handling.

--
You received this message because you are subscribed to the Google Groups "envoy-security" group.
To unsubscribe from this group and stop receiving emails from it, send an email to envoy-securit...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/envoy-security/CAGd3HqPRCKYpf86Ay%2BRoRFR%3D8R4JTHkDh1Ld3XeTPyFeCmCMrw%40mail.gmail.com.

[Yan Avlasov]

I have create https://github.com/envoyproxy/envoy/pull/42973 to update VRP edge config.