Re: Double URL Decoding Mismatch Between Edge and Origin Envoy Enables Routing Bypass

[Yan Avlasov]

Hi Zhafran. Thanks for the responsible report.

Note that interpreting %25 sequence as the % character for comparing URI paths, is not standard compliant per https://datatracker.ietf.org/doc/html/rfc3986#section-2.4 As such Envoy does not try to decode it even with path normalization enabled. For this exploit to be variable a web server or an intermediary have to be non compliant. In general we do consider such cases to be a security vulnerability, unless it affects frequently used implementations.

If you know specific implementations that decode %25 please let us know. Otherwise we can include it in the planned sanitization filter that addresses such edge cases.

Yan

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

Detail

A double URL decoding mismatch exists between the Edge Envoy and the upstream Origin Envoy in the Google VRP Envoy test environment.

The Edge Envoy proxy is configured to only forward requests whose paths match the /content/* prefix. Requests to restricted paths such as /blockedz are explicitly denied at the Edge layer and return an HTTP 403 Forbidden response.

When a request contains double-encoded path traversal sequences, such as %252e%252e (double-encoded ..) or %252f (double-encoded /), the Edge Envoy performs a single URL decode before evaluating the routing policy. After this first decode, the path still appears to match the /content/* prefix and is therefore forwarded to the upstream Origin Envoy.

The upstream Origin Envoy then performs an additional URL decode, fully resolving the traversal sequence and transforming the request path into a restricted endpoint such as /blockedz. Because routing decisions have already been made at the Edge layer, the request is processed successfully by the upstream service.

This results in a routing policy bypass caused by inconsistent URL decoding behavior across proxy layers

PoC

Expected behavior

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

 
Response:

HTTP/1.1 403 Forbidden
denied

Bypass using double URL encoding

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

 Response:

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

Alternative payload 

curl -k -i https://localhost:10000/content/%252fblockedz

Response: 

HTTP/1.1 200 OK

These requests are incorrectly forwarded to the upstream service due to decoding inconsistencies.

Attack Scenario 

An unauthenticated remote attacker sends a specially crafted HTTP request containing double-encoded path traversal sequences to the Edge Envoy proxy.

Because the Edge Envoy only decodes the request path once before performing route matching, the malicious request is treated as a valid /content/* request and forwarded upstream. The Origin Envoy then decodes the path again, resolving it to a restricted endpoint.

This allows the attacker to access upstream-only routes that should be unreachable through the Edge proxy. In real-world deployments, this could enable attackers to:

• Reach internal services protected behind Envoy routing rules

• Access administrative or management endpoints

• Bypass security boundaries assumed to be enforced at the Edge layer

The attack does not require authentication, special headers, or any prior knowledge of internal infrastructure.

Impact

• Routing restrictions enforced by the Edge Envoy can be bypassed

• Inconsistent canonicalization breaks security assumptions between proxy layers

• Potential exposure of internal or sensitive upstream services

• Increased risk of lateral movement within microservice architectures
  

Conclusion

This vulnerability is caused by inconsistent URL decoding behavior between the Edge Envoy and the upstream Origin Envoy. Routing decisions are made by the Edge Envoy before full normalization of the request path, allowing double-encoded traversal sequences to bypass security controls.

To prevent this class of vulnerability, Envoy deployments should ensure consistent and complete URL normalization across all proxy layers prior to applying routing policies. Security-sensitive routing decisions should be based on fully canonicalized request paths to avoid mismatches between Edge and upstream components.

--
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/CAGd3HqOGzUU0fJuzYLXB-Y3Yy1zSbu8aNcr%3DNcvHye26Rhf6ug%40mail.gmail.com.