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
"/",
),
"/",
)
```

CWE-863 Incorrect Authorization