A security vulnerability has been discovered in how the input.parsed_path field is constructed. HTTP request paths are treated as full URIs when parsed; interpreting leading path segments prefixed with double slashes (//) as authority components, and therefore dropping them from the parsed path. This creates a path interpretation mismatch between authorization policies and backend servers, enabling attackers to bypass access controls by crafting requests where the authorization filter evaluates a different path than the one ultimately served.
Attack example
HTTP request:
GET //admin/users HTTP/1.1
Host: example.com
Policy sees:
The leading //admin path segment is interpreted as an authority component, and dropped from input.parsed_path field:
{
"parsed_path": ["users"]
}
Backend receives:
//admin/users path, normalized to /admin/users.
Affected Request Pattern Examples
| Request path | input.parsed_path | input.attributes.request.http.path | Discrepancy |
| - | - | - | - |
| / | [""] | / | ✅ None |
| //foo | [""] | //foo| ❌ Mismatch |
| /admin | ["admin"] | /admin | ✅ None |
| /admin/users | ["admin", "users"] | /admin/users | ✅ None |
| //admin/users | ["users"] | //admin/users | ❌ Mismatch |
Impact
Users are impacted if all the following conditions apply:
- Protected resources are path-hierarchical (e.g.,
/admin/users vs /users)
- Authorization policies use
input.parsed_path for path-based decisions
- Backend servers apply lenient path normalization
Patches
Go: v1.13.2-envoy-2
Docker: ,