Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-21T21:17:09.637Z",
  "pubdate": "2026-09-21T21:17:09.637Z",
  "executiveSummary": "Envoy is susceptible to a security bypass vulnerability in its RBAC (Role-Based Access Control) mechanism, specifically when configured with 'ignore_path_parameters_in_path_matching'.\nThis vulnerability stems from inconsistent canonicalization of request paths between the Envoy router and the RBAC engine, allowing an unauthenticated attacker to evade path-based access control policies.\nThe flaw affects Envoy versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1.\nThe security impact allows an attacker to access protected backend resources that were intended to be restricted by DENY rules.\nSuccessful exploitation requires the target to have both a route configuration that ignores path parameters and an RBAC policy targeting a specific path.\nThe exploit can be triggered by a remote, unauthenticated client by crafting a URI with semicolon-delimited parameters that deceive the RBAC engine while being transparently normalized by the router.",
  "technicalDetails": "The vulnerability resides in the discrepancy between how the Envoy router component and the RBAC url_path matcher interpret request URIs when the configuration setting 'ignore_path_parameters_in_path_matching' is enabled.\nWhen this configuration is active, the Envoy router is designed to strip semicolon-based path parameters (e.g., /admin;x) to normalize the request path before determining the appropriate backend route. This enables the router to correctly match the normalized path (e.g., /admin) to its respective route entry.\nHowever, the RBAC url_path matcher does not perform this same normalization step; it evaluates the raw path of the incoming request. Consequently, if an administrator has defined an RBAC policy to DENY access to '/admin', an incoming request targeting '/admin;x' will not match the DENY rule because the RBAC engine sees the literal string '/admin;x' instead of the canonical '/admin'.\nThe exploitation flow proceeds as follows: First, the attacker identifies a backend endpoint protected by an RBAC rule defined by a path pattern. Second, the attacker crafts a malicious request by appending a semicolon and an arbitrary string to the restricted path (e.g., /admin;x). Third, the request hits the Envoy proxy; the router strips the ';x' suffix, identifies the target as the protected backend, and routes the request accordingly. Fourth, the RBAC engine receives the request, compares the raw path '/admin;x' against the restricted rule '/admin', fails to find a match, and erroneously allows the request.\nThis inconsistent canonicalization bypasses security boundaries because the proxy effectively switches from a security-enforcement mode to a routing mode based on two different interpretations of the same HTTP resource. The vulnerability is restricted to environments where the route option and the path-based RBAC rule coexist, effectively creating a 'blind spot' in the security policy enforcement chain.\nAffected versions include all releases prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1. The vulnerability does not require authentication or elevated privileges, making it a critical concern for edge deployments exposed to the public internet."
}