CVE-2026-73511: 
Envoy vulnerability analysis and mitigation

CVE-2026-73511 is a path-matching authentication bypass vulnerability in Envoy Proxy affecting versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1. The flaw arises from a semantic mismatch between how Envoy matches HTTP request paths and how servlet backends (e.g., Apache Tomcat) resolve them, enabling unauthenticated remote attackers to bypass path-based access controls. It was disclosed on August 26, 2026 via GitHub Security Advisory GHSA-m745-gh6x-349x and published to NVD on September 21, 2026. The vulnerability carries a CVSS v3.1 base score of 5.3 (Medium) (GitHub Advisory).

The root cause is an interpretation conflict (CWE-436) combined with authentication bypass by alternate name (CWE-289) between Envoy's route matcher and RFC 3986-compliant servlet backends. By default, Envoy matches routes against the raw :path header, including any semicolon-delimited matrix parameters (e.g., /auth;x=y/). Backends like Apache Tomcat strip these parameters per path segment before resolving the resource, so /auth;x=y/ resolves to /auth/. Envoy's existing mitigation option ignore_path_parameters_in_path_matching only truncates at the first semicolon in the entire path (pre-RFC 3986 / RFC 1808 behavior via RouteMatchContext::stripPathParams), meaning it still fails to match per-segment backend behavior and can be bypassed by placing a matrix parameter on a non-terminal segment (e.g., /;x=y/auth/). Exploitation requires no authentication or user interaction and is fully network-accessible (GitHub Advisory, Patch Commit).

Successful exploitation allows an unauthenticated remote attacker to access resources protected by Envoy's path-based access controls — including RBAC HTTP filter path rules, ext_authz decisions based on request path, direct_response blocks, and routing of protected paths (e.g., /auth/, /admin/) to authenticated clusters. The primary impact is confidentiality loss (CVSS C:L), as attackers can read protected backend content without credentials. Where the bypassed path leads to an authentication or administrative endpoint, the vulnerability can serve as an initial access vector enabling further lateral movement or privilege escalation within the backend application (GitHub Advisory).

A proof-of-concept exploit with concrete curl commands and full reproduction instructions (Envoy YAML config + Tomcat Docker setup) is publicly available in the GitHub Security Advisory (GitHub Advisory). The exploit requires no authentication, no user interaction, and low attack complexity, making it trivially automatable. The EPSS score is approximately 0.0055 (0.55%), and there is currently no evidence of in-the-wild exploitation or CISA KEV catalog inclusion. No specific threat actor attribution has been reported.

1. Reconnaissance: Identify Envoy proxy instances fronting servlet-based backends (e.g., Apache Tomcat) using network scanning or application fingerprinting. Determine which paths are protected by path-based Envoy rules (e.g., /auth/, /admin/) and which are fallback routes (e.g., /).
2. Craft matrix parameter payload: Construct an HTTP request path that injects a semicolon-delimited matrix parameter into the protected path segment, e.g., /auth;x=y/. This causes Envoy's literal path matcher to see /auth;x=y/ (not matching the /auth/ rule) and fall through to the unprotected fallback route.
3. Send bypass request: Issue the request using --path-as-is to prevent client-side URL normalization:

   curl --path-as-is http://target:10000/auth;x=y/

4. Alternative bypass (with ignore_path_parameters_in_path_matching enabled): Place the matrix parameter on a non-terminal segment to exploit the over-truncation behavior:

   curl --path-as-is http://target:10000/;x=y/auth/

   Envoy truncates to / (matching the fallback), while Tomcat resolves /auth/.
5. Backend resolves protected resource: The backend (Tomcat) strips the matrix parameter per segment per RFC 3986 §3.3 semantics and serves the protected resource (e.g., returns 200 SECRET).
6. Leverage access: Use the obtained access to interact with the protected backend resource — e.g., read sensitive data, access admin panels, or establish an authenticated session for further exploitation (GitHub Advisory).

• Network: HTTP requests to Envoy-protected paths containing semicolons in path segments (e.g., /auth;, /admin;, /;param=) that would normally be blocked; use of --path-as-is-style clients that do not normalize URLs before sending.
• Logs: Envoy access logs showing requests with raw paths containing semicolons (e.g., GET /auth;x=y/ HTTP/1.1) that received non-403 responses from the backend cluster rather than a direct_response; backend (Tomcat) access logs showing requests to protected paths (e.g., /auth/) originating from Envoy's upstream IP without corresponding Envoy-side authorization events.
• Behavioral: Unexpected 200 responses from the backend for paths that should have been blocked by Envoy's route configuration; discrepancy between Envoy route match logs and backend access logs for the same request path (GitHub Advisory).

Upgrade Envoy to one of the patched versions: 1.36.10, 1.37.6, 1.38.4, or 1.39.1, which implement per-segment matrix parameter stripping (PathUtil::removePathParameters) aligned with RFC 3986 §3.3 backend behavior (GitHub Advisory, Patch Commit). As a temporary workaround if upgrading is not immediately possible: (1) implement additional access control at the backend level that does not rely solely on Envoy path-based decisions, or (2) deploy a WAF rule to reject requests containing semicolons in path segments before they reach Envoy. Note that enabling ignore_path_parameters_in_path_matching alone is not a sufficient mitigation, as it remains bypassable via non-terminal segment parameters. After upgrading, the new behavior can be temporarily reverted by setting the runtime guard envoy.reloadable_features.strip_path_parameters_per_segment to false if compatibility issues arise.

The vulnerability was reported by researcher svewi and coordinated by Envoy maintainer phlax, who published the advisory on August 26, 2026 (GitHub Advisory). The issue was picked up by downstream distributors including openSUSE security announcements and AWS Amazon Linux security advisories (ALAS2ECS-2026-137, ALAS2023-2026-2149), indicating broad ecosystem awareness. Istio also referenced the fix in its 1.30.4 release notes, reflecting the vulnerability's relevance to service mesh deployments.