CVE-2026-73553: Envoy: RBAC Authorization Bypass via Path Parameters
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 ignorepathparametersinpathmatching is enabled, Envoy's router strips the semicolon suffix before matching but the RBAC urlpath 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
envoyto a version that resolves this vulnerability.Fixed in 1.36.10 - Upgrade
Upgrade
envoyto a version that resolves this vulnerability.Fixed in 1.37.6 - Upgrade
Upgrade
envoyto a version that resolves this vulnerability.Fixed in 1.38.4 - Upgrade
Upgrade
envoyto a version that resolves this vulnerability.Fixed in 1.39.1
Event History
Frequently Asked Questions
Which deployments are affected by this authorization bypass?
A deployment is affected only when ignore_path_parameters_in_path_matching is enabled, a path-based RBAC rule is present, and the protected route matches after Envoy strips the semicolon path suffix. Configurations without this combination are not within the described scope.
What does an attacker need to exploit the issue?
An unauthenticated downstream client needs to send a request with a semicolon path parameter, such as /admin;x. This can bypass a DENY rule for /admin when routing strips the suffix and selects the protected /admin backend.
How can I remediate the issue?
Upgrade Envoy to 1.36.10, 1.37.6, 1.38.4, or 1.39.1, as applicable. If upgrading is not immediately possible, disabling ignore_path_parameters_in_path_matching removes the inconsistent path handling described in the issue.
How can I determine whether a route is exposed?
Review routes that enable ignore_path_parameters_in_path_matching and identify path-based RBAC DENY rules protecting routes such as /admin. Test whether a request formed by appending a semicolon suffix, such as /admin;x, is routed to the protected backend while avoiding the corresponding RBAC match.