envoyproxy Envoy Path Canonicalization Mismatch Enables RBAC Authorization Bypass

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1, When ignore_path_parameters_in_path_matching is enabled, Envoy's router strips the semicolon suffix before matching but the RBAC url_path matcher evaluates the raw path. A downstream request such as /admin;x can therefore miss a DENY rule for /admin while the router still selects the protected /admin backend. The inconsistent canonicalization allows an unauthenticated client to bypass path-based authorization. The relevant scope boundary is that the route option and a path-based RBAC rule must both be present, and the protected route must match after stripping. This issue is fixed in versions 1.36.10, 1.37.6, 1.38.4, and 1.39.1.

The structured CVE facts identify these affected branches:

• envoyproxy/envoy < 1.36.10.
• envoyproxy/envoy >= 1.37.0, < 1.37.6.
• envoyproxy/envoy >= 1.38.0, < 1.38.4.
• envoyproxy/envoy >= 1.39.0, < 1.39.1.

The relevant configuration scope is a route with ignore_path_parameters_in_path_matching enabled, a path-based RBAC url_path policy, and a protected route that matches after the path parameter is removed. The GitHub advisory also uses a broader < 1.40.0 affected label and states that all releases supporting the option are affected. That broad label is not fully consistent with the advisory's patched-version list or with the structured branch ranges above, so releases outside the explicit ranges should be verified separately rather than inferred from the broad label.

envoyproxy Envoy processes the request path inconsistently between routing and RBAC when ignore_path_parameters_in_path_matching is enabled. The router matches a path with the semicolon suffix removed, while the RBAC url_path matcher evaluates the raw path. Consequently, a request such as GET /admin;x can fail to match a DENY policy for /admin while still matching the protected route after the suffix is removed.

The defect is a canonicalization conflict between envoy.filters.http.router and envoy.filters.http.rbac, consistent with CWE-436. Exploitation requires all of the following: the route option must be enabled, an RBAC policy must use a path-based url_path rule, and the protected route must match after path-parameter removal. The vendor advisory identifies the router-side processing as sanitizedPath() and stripPathParams, while RBAC retains the semicolon portion when evaluating the raw path. The vendor does not identify normalizePath or mergeSlashes as effective ways to reconcile the two path views.

The issue is reachable over the network by an unauthenticated downstream client and does not require user interaction. An attacker must supply a path containing a suitable path parameter, but exploitation depends on the precise route and RBAC configuration, so not every Envoy deployment is exposed.

The vendor advisory includes proof-of-concept material for the bypass, establishing that public exploitation material exists. The available evidence does not establish active exploitation in the wild or identify a campaign, victim, or breach associated with this issue.

The technical outcome is that a path-based RBAC DENY rule can fail to apply while the router still selects the protected route. An unauthenticated client may therefore cross the Envoy authorization boundary and reach upstream resources or operations that the path policy was intended to protect.

The primary consequences are loss of confidentiality and integrity within the permissions exposed by the protected backend; the issue is not described as an availability vulnerability. The precise organisational impact depends on the endpoints, data, and additional authorization controls at the upstream service. Exposure is not universal because the route option, RBAC path rule, and post-stripping route match must align.

A request that evades a path-based authorization rule may reach a backend that was intended to be protected by Envoy. Depending on the backend's data and operations, this could expose protected information or permit unauthorized actions if no additional authorization layer blocks the request.

The issue crosses the access-control boundary between Envoy and the upstream service. It does not by itself grant administrative privileges inside Envoy. Deployments that do not enable the relevant route option, do not use path-based RBAC, or do not have a protected route that matches after canonicalization do not meet the documented conditions.

1. Upgrade each affected branch to its confirmed fixed release: 1.36.10, 1.37.6, 1.38.4, or 1.39.1. Do not assume that a fix for one branch covers another branch.
2. If an upgrade is not immediately possible, treat the vendor advisory as providing no confirmed configuration-only workaround for this issue. Do not rely on normalizePath or mergeSlashes alone, because they do not remove path parameters in the way required to align router and RBAC behavior.
3. Review routes and policies that combine ignore_path_parameters_in_path_matching with path-based RBAC. If the design must be changed before patching, validate every protected route and confirm that authorization and route selection use the same canonical path.
4. After upgrading, run a regression test in a controlled environment using ordinary paths and paths with semicolon suffixes. Confirm that the authorization policy is applied and that the request cannot reach a protected backend unexpectedly.
5. Check downstream distributions and vendor-packaged Envoy builds separately, because their package versions may not map directly to the upstream version.

1. Inventory Envoy deployments and determine the running branch, prioritizing instances in front of sensitive or authorization-protected backends.
2. Inspect route configuration for ignore_path_parameters_in_path_matching: true.
3. Inspect envoy.filters.http.rbac policies for url_path matchers, especially exact-path, prefix, or other path-based DENY and ALLOW rules.
4. In a controlled test environment, compare authorization and routing for normal paths and equivalent paths with a semicolon suffix. Compare both the authorization result and the selected route or upstream. Do not treat rejection of ordinary requests as proof that path-parameter variants are safe.
5. Where access logging is enabled, correlate the raw path such as %REQ(:PATH)% with %ROUTE_NAME%, %UPSTREAM_CLUSTER%, %RESPONSE_CODE%, and the RBAC result. These are investigation signals, not vendor-confirmed indicators of compromise.