Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-46821

CVE-2025-46821: Envoyproxy Envoy Auth Bypass Vulnerability

CVE-2025-46821 is an authentication bypass flaw in Envoyproxy Envoy caused by URI template matcher incorrectly handling the asterisk character, allowing RBAC rule bypasses. This article covers technical details, affected versions, impact, and mitigation strategies.

Published:

CVE-2025-46821 Overview

CVE-2025-46821 is a Role-Based Access Control (RBAC) bypass vulnerability in Envoy, a cloud-native edge, middle, and service proxy. The flaw exists in Envoy's URI template matcher, which incorrectly excludes the * character from the set of valid URI path characters. URI paths containing * fail to match uri_template expressions, allowing attackers to circumvent RBAC rules configured with uri_template permissions. The issue affects Envoy versions prior to 1.34.1, 1.33.3, 1.32.6, and 1.31.8. This is tracked under CWE-186 (Overly Restrictive Regular Expression).

Critical Impact

Attackers can bypass RBAC policies by crafting request URIs containing * characters, potentially reaching protected upstream endpoints without proper authorization.

Affected Products

  • Envoy versions prior to 1.31.8
  • Envoy versions prior to 1.32.6 and 1.33.3
  • Envoy version 1.34.0 (fixed in 1.34.1)

Discovery Timeline

  • 2025-05-07 - CVE-2025-46821 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-46821

Vulnerability Analysis

Envoy exposes a uri_template matcher used inside RBAC filter policies to authorize requests based on URI path patterns. The matcher validates each character of an incoming URI path against an allowlist of characters considered valid within a URI segment. The allowlist omits the asterisk (*) character, even though * is a valid character in RFC 3986 URI paths and is routinely accepted by upstream services.

When a request path contains *, the matcher treats the path as invalid and returns no match. Downstream RBAC logic interprets the no-match result as "policy not applicable," so the request bypasses the intended authorization decision. The vulnerability produces limited integrity impact because attackers can only reach endpoints that the target service already exposes, but authorization enforcement is skipped.

Exploitation requires no authentication and no user interaction. The attack vector is remote and network-based, targeting any Envoy deployment that relies on uri_template permissions for access control.

Root Cause

The root cause is an incomplete character set in the URI template matcher's path validation logic. The allowed-character definition excludes * from the reserved and unreserved character classes normally accepted in URI path components, causing paths containing * to fail template matching outright rather than being evaluated against the template pattern.

Attack Vector

An unauthenticated remote attacker sends an HTTP request to an Envoy proxy protected by an RBAC policy that uses uri_template permissions. The attacker inserts a * character within a path segment that would otherwise match a protected template. Envoy's matcher returns no match, the RBAC filter fails to apply the deny or allow decision, and the request is routed to the upstream service without authorization enforcement.

The vulnerability manifests inside Envoy's URI template matching component. Refer to the Envoy GitHub Security Advisory GHSA-c7cm-838g-6g67 for the fix commits and matcher implementation details.

Detection Methods for CVE-2025-46821

Indicators of Compromise

  • HTTP request logs containing * characters in URI path segments targeting endpoints protected by uri_template RBAC rules.
  • Successful upstream responses for requests that should have been denied by an RBAC policy.
  • Discrepancies between Envoy access logs and downstream application authorization logs, where Envoy shows no RBAC deny for policy-protected paths.

Detection Strategies

  • Audit Envoy access logs for request paths containing * characters directed at routes governed by uri_template permissions.
  • Compare RBAC filter statistics (rbac.allowed, rbac.denied) against expected policy hit rates and investigate anomalous allow counts.
  • Deploy synthetic probes that inject * characters into protected paths to confirm whether the deployed Envoy version enforces the intended policy.

Monitoring Recommendations

  • Enable verbose Envoy access logging with the %REQ(:PATH)% and %RESPONSE_CODE% fields to capture full request URIs and outcomes.
  • Forward Envoy telemetry to a centralized analytics platform and alert on unexpected 2xx responses for RBAC-protected routes.
  • Track the running Envoy version across all data plane instances and flag any release below 1.31.8, 1.32.6, 1.33.3, or 1.34.1.

How to Mitigate CVE-2025-46821

Immediate Actions Required

  • Upgrade Envoy to version 1.34.1, 1.33.3, 1.32.6, or 1.31.8 or later, depending on the release branch in use.
  • Inventory all RBAC policies that reference uri_template and identify routes exposed to untrusted clients.
  • Review recent access logs for requests containing * in URI paths to detect prior exploitation attempts.

Patch Information

The Envoy maintainers fixed this issue in versions 1.34.1, 1.33.3, 1.32.6, and 1.31.8. Details are published in the Envoy GitHub Security Advisory GHSA-c7cm-838g-6g67. Operators using service meshes such as Istio should upgrade to a mesh release that bundles a patched Envoy build.

Workarounds

  • Replace uri_template permissions with url_path matchers using safe_regex expressions that explicitly account for the * character.
  • Add layered authorization at the upstream application to enforce policy independent of Envoy RBAC decisions.
  • Deploy a Web Application Firewall (WAF) rule to reject requests containing * in URI paths for routes that should never receive such input.
bash
# Example RBAC workaround using url_path with safe_regex
# Replace vulnerable uri_template permission with an equivalent regex
rbac:
  rules:
    action: ALLOW
    policies:
      "protected-route":
        permissions:
          - url_path:
              path:
                safe_regex:
                  regex: "^/api/v1/users/[^/*]+/profile$"
        principals:
          - authenticated:
              principal_name:
                exact: "trusted-service"

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.