CVE-2026-73553 in Envoy
Summary
by MITRE • 09/21/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/21/2026
Envoy serves as a critical infrastructure component for cloud-native environments, functioning as an edge and service proxy that manages traffic routing, load balancing, and security policies. A significant vulnerability was identified in versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1 regarding the handling of URL path parameters when specific configuration options are enabled. The core issue stems from an inconsistency in how different components within Envoy process the request URI. Specifically, when the ignore_path_parameters_in_path_matching option is activated, the router component strips semicolon-separated suffixes from the path before performing route matching operations. However, the Role-Based Access Control (RBAC) engine responsible for evaluating url_path matchers continues to operate on the raw, unmodified path string that includes these parameters. This divergence in canonicalization creates a critical security gap where authorization checks and routing decisions are based on different representations of the same request URI.
The operational impact of this flaw is severe, as it allows an unauthenticated or unauthorized client to bypass path-based access controls through parameter injection techniques. In a typical scenario involving administrative endpoints, such as /admin, an RBAC rule might be configured to deny access to paths starting with /admin for certain roles or users. Under normal circumstances, a request to /admin would correctly trigger this denial. However, by appending a semicolon and arbitrary parameters, such as requesting /admin;x, the router strips the ;x portion during route selection and matches it against the protected backend associated with /admin. Simultaneously, because the RBAC engine evaluates the raw path including the suffix, it fails to match the deny rule which likely targets only the clean /admin string. Consequently, the request is permitted through by the authorization layer while being routed to a sensitive internal service that should have been inaccessible.
This vulnerability aligns with CWE-284 Improper Access Control and CWE-601 URL Redirection to Untrusted Site (SPOOFING) in terms of its mechanism for bypassing security boundaries, although it is more accurately classified under logic flaws related to input canonicalization inconsistencies often seen in CWE-798 or general authorization bypass patterns. From an ATT&CK perspective, this represents a technique where attackers exploit misconfigurations or implementation errors to evade detection and gain unauthorized access, falling under the Initial Access and Privilege Escalation tactics depending on the sensitivity of the targeted endpoint. The scope of exploitation is limited by specific prerequisites: the route option must be explicitly enabled, there must be an active path-based RBAC rule in place, and the protected route must match after the stripping operation occurs. Despite these constraints, the existence of such a bypass mechanism undermines the integrity of security policies enforced at the proxy level.
To mitigate this risk, organizations running affected versions of Envoy must upgrade to version 1.36.10 or later for the 1.36 branch, 1.37.6 for the 1.37 branch, 1.38.4 for the 1.38 branch, and 1.39.1 for the 1.39 branch. These releases contain fixes that ensure consistent canonicalization between the router and RBAC components, preventing the discrepancy that allows parameter-based bypasses. In environments where immediate upgrading is not feasible due to compatibility or testing requirements, temporary mitigations should focus on tightening RBAC rules to explicitly account for potential path parameters or disabling the ignore_path_parameters_in_path_matching option if it does not conflict with other application requirements. Additionally, implementing strict input validation and monitoring for anomalous request patterns containing semicolons in URL paths can provide an additional layer of defense against exploitation attempts while permanent fixes are deployed.