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, Envoy HTTP RBAC accepts RFC-valid opaque header bytes but evaluates safe_regex values with RE2's UTF-8 subject semantics. A downstream client can preserve a prohibited marker and add an unrelated obs-text octet, causing RE2::FullMatch to return false and a negative RBAC policy to treat the invalid subject as an ordinary no-match. A byte-oriented route matcher can still observe the marker, allowing the request to reach a route intended to be denied. The relevant scope boundary is that plain positive ALLOW regexes normally fail closed, and exact, prefix, suffix, and contains matchers are not shown to have this subject-domain failure. 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-21T20:17:28.900Z",
  "pubdate": "2026-09-21T20:17:28.900Z",
  "executiveSummary": "Envoy is susceptible to a security bypass vulnerability within its HTTP Role-Based Access Control (RBAC) mechanism. The issue stems from a mismatch in how the proxy handles opaque header bytes versus the underlying RE2 regex engine's UTF-8 subject semantics.\nSpecifically, when using negative RBAC policies involving safe_regex matchers, an attacker can craft requests with opaque header bytes that bypass restriction filters. By appending an obs-text octet, a client can force RE2::FullMatch to return false, causing the RBAC policy to treat a prohibited header as a non-match.\nThis vulnerability allows an attacker to bypass intended access control policies, potentially granting unauthorized access to restricted routes. The flaw affects Envoy versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1. Exposure is localized to configurations utilizing negative regex-based RBAC policies. Mitigation requires updating to the patched versions provided by the vendor.",
  "technicalDetails": "The vulnerability resides in the interaction between Envoy's HTTP RBAC implementation and the RE2 regex engine. Envoy processes incoming headers as opaque bytes, which may include RFC-valid but non-UTF-8 characters. However, the safe_regex implementation within Envoy invokes RE2::FullMatch, which enforces UTF-8 subject semantics on the provided input.\nThe root cause is a semantic mismatch during the evaluation of negative RBAC policies. When an attacker includes a prohibited marker within a header value, the RBAC policy should logically trigger a block. By appending an 'obs-text' octet—a non-UTF-8 compliant byte sequence—to the header, the attacker forces the regex engine to fail the match condition. Because the subject is interpreted as invalid UTF-8, the RE2 engine returns false, leading the negative RBAC logic to incorrectly conclude that the header does not match the prohibited pattern.\nThe attack flow proceeds as follows: 1) An attacker identifies a target route protected by a negative RBAC policy using regex. 2) The attacker crafts a request containing a prohibited string (the marker) required for the RBAC block. 3) The attacker modifies the header by appending a specific obs-text octet. 4) Envoy's RBAC filter evaluates the header; the RE2 regex engine encounters the invalid UTF-8 sequence and fails the match, bypassing the intended security policy. 5) Downstream, the request is processed by a byte-oriented route matcher. Because this downstream component evaluates the bytes directly rather than through the UTF-8-constrained regex engine, it observes the original marker and routes the request to the restricted resource, effectively completing the bypass.\nThis vulnerability is restricted to the specific interaction between negative regex matchers and header parsing. It does not affect exact, prefix, suffix, or contains matchers, as these operate on byte-level comparisons rather than regex engine semantics. Furthermore, positive ALLOW regexes are reported to fail closed, limiting the scope of the exploit to restrictive (negative) policy enforcement. Successful exploitation results in unauthorized access to restricted backend routes, potentially leading to unauthorized data exposure or administrative action execution if the protected routes lack additional application-layer authentication."
}