opa-envoy-plugin has an Authorization Bypass via Double-Slash Path Misinterpretation in `input.parsed_path`

opa-envoy-plugun is a plugin to enforce OPA policies with Envoy. Versions prior to 1.13.2-envoy-2 have a vulnerability 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. Version 1.13.2-envoy-2 fixes the issue.

opa-envoy-plugun is a plugin to enforce OPA policies with Envoy. Versions prior to 1.13.2-envoy-2 have a vulnerability 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. Version 1.13.2-envoy-2 fixes the issue.

opa-envoy-plugun is a plugin to enforce OPA policies with Envoy. Versions prior to 1.13.2-envoy-2 have a vulnerability 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. Version 1.13.2-envoy-2 fixes the issue.

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](https://datatracker.ietf.org/doc/html/rfc3986#section-3.2) 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: ```json { "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: 1. Protected resources are path-hierarchical (e.g., `/admin/users` vs `/users`) 2. Authorization policies use `input.parsed_path` for path-based decisions 3. Backend servers apply lenient path normalization ### Patches Go: `v1.13.2-envoy-2` Docker: `1.13.2-envoy-2`, `1.13.2-envoy-2-static` ### Workarounds Users who cannot immediately upgrade opa-envoy-plugin are recommended to apply one, or more, of the workarrounds described below. #### 1. Enable the `merge_slashes` Envoy configuration option As per [Envoy best practices](https://www.envoyproxy.io/docs/envoy/v1.37.0/configuration/best_practices/edge.html), enabling the [merge_slashes](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto#envoy-v3-api-field-extensions-filters-network-http-connection-manager-v3-httpconnectionmanager-merge-slashes) configuration option in Envoy will remove redundant slashes from the request path before filtering is applied, effectively mitigating the `input.parsed_path` issue described in this advisory. #### 2. Use `input.attributes.request.http.path` instead of `input.parsed_path` in policies The `input.attributes.request.http.path` field contains the unprocessed, raw request path. Users are recommended to update any policy using `input.parsed_path` to instead use the `input.attributes.request.http.path` field. ##### Example #### ```rego package example # Use instead of input.parsed_path parsed_path := split( # tokenize into array trim_left( # drop leading slashes urlquery.decode(input.attributes.request.http.path), # url-decode the path "/", ), "/", ) ```

opa-envoy-plugin has an Authorization Bypass via Double-Slash Path Misinterpretation in input.parsed_path in github.com/open-policy-agent/opa-envoy-plugin