CVE-2026-73552: 
Envoy vulnerability analysis and mitigation

CVE-2026-73552 is an HTTP RBAC authorization bypass vulnerability in Envoy Proxy, tracked under GHSA-23xh-2qxr-3xv8, where the safe_regex matcher can fail open when evaluating RFC-valid HTTP header values containing obs-text (non-UTF-8) octets. Affected versions include all Envoy releases prior to 1.36.10, 1.37.0–1.37.5, 1.38.0–1.38.3, and 1.39.0. The vulnerability was privately reported by researcher Vincent550102, published on August 26, 2026, and patched in versions 1.36.10, 1.37.6, 1.38.4, and 1.39.1. It carries a CVSS v3.1 base score of 7.5 (High) (Envoy Advisory).

The root cause is a domain and error-contract mismatch (CWE-20: Improper Input Validation) at Envoy's authorization boundary: Envoy's HeaderUtility::headerValueIsValid accepts RFC 9110-conforming obs-text octets (0x80–0xFF) via ObsTextOption::kAllow, but the RBAC safe_regex matcher passes the raw bytes to RE2's FullMatch in its default UTF-8 mode. When the header value contains an invalid UTF-8 octet (e.g., raw 0xff), RE2::FullMatch returns false — not an error — and RBAC interprets this as an ordinary policy no-match rather than an invalid-subject condition. In a negative RBAC policy (e.g., action: DENY with a positive regex, or action: ALLOW with an inverted regex), this false result causes the policy to fail open, permitting the request. Meanwhile, byte-oriented consumers such as the route HeaderMatcher contains operation (using absl::StrContains) still observe the preserved prohibited marker in the header, routing the request to the protected resource (Envoy Advisory).

Successful exploitation allows an unauthenticated remote attacker to bypass RBAC policies protecting HTTP routes and access resources that should be denied. The primary confidentiality impact is disclosure of all data accessible through the protected route; if the protected endpoint performs state-changing operations, unauthorized modifications are also possible. No availability or integrity impact (in the data-corruption sense) is claimed, and no lateral movement, admin interface access, or resource exhaustion is required — a single TLS connection and one HTTP request suffice (Envoy Advisory).

A detailed proof-of-concept (PoC) is publicly available in the Envoy security advisory, including exact exploit header bytes (22726f6c653d61646d696e222c20226e6f74653dff22), a Python PoC script (prp_rbac_invalid_utf8_opaque_header_poc.py), Docker reproduction commands, and a YAML configuration demonstrating the bypass on both HTTP/1.1 and HTTP/2. The exploit requires no authentication, no user interaction, and no special privileges — only the ability to send arbitrary HTTP headers. The EPSS score is approximately 0.00665 (low probability of near-term exploitation), and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the advisory date. The vulnerability is automatable per NVD SSVC assessment (Envoy Advisory).

1. Identify target: Locate an Envoy proxy instance running a vulnerable version (< 1.36.10, 1.37.0–1.37.5, 1.38.0–1.38.3, or 1.39.0) with the HTTP RBAC filter enabled using a safe_regex matcher in a negative policy (e.g., action: DENY with a positive regex on a header field).
2. Craft the malicious header: Construct an HTTP If-Match header containing two entity tags — the first with the prohibited ASCII marker (e.g., "role=admin") and the second with a raw obs-text octet (e.g., "note=<0xff>" where 0xff is a single raw byte). The exact field-value bytes are: 22726f6c653d61646d696e222c20226e6f74653dff22.
3. Send the request: Using a raw TLS socket (not a text-oriented HTTP client that might normalize or reject the 0xff byte), send an HTTP/1.1 or HTTP/2 request to the Envoy listener (e.g., port 10000) targeting a path covered by the RBAC policy (e.g., /content). The PoC script prp_rbac_invalid_utf8_opaque_header_poc.py (requiring hpack) constructs raw frames for both protocols.
4. RBAC bypass occurs: Envoy's HeaderUtility accepts the header (obs-text is RFC-valid). The RBAC safe_regex matcher invokes RE2::FullMatch in UTF-8 mode; the 0xff octet causes FullMatch to return false. The DENY policy treats this as a no-match and permits the request.
5. Route matcher routes to protected resource: The byte-oriented HeaderMatcher contains operation finds "role=admin" in the first entity tag and routes the request to the protected cluster/endpoint (e.g., /blockedz).
6. Access protected resource: The origin returns a 200 OK response with the protected content instead of the expected 403 RBAC: access denied (Envoy Advisory).

• Network: HTTP requests to Envoy-proxied endpoints containing If-Match (or other) headers with raw non-UTF-8 bytes (0x80–0xFF) in the field value; specifically, requests that receive 200 OK responses on routes that should return 403 RBAC: access denied.
• Logs: Envoy access logs showing 200 responses on paths protected by RBAC DENY policies with safe_regex header matchers, particularly where the If-Match header value contains non-printable or high-byte characters; absence of RBAC denial log entries for requests that include prohibited markers.
• Network: Raw TLS connections sending HTTP/1.1 or HTTP/2 frames with header field values containing byte sequences in the range 0x80–0xFF (obs-text) alongside ASCII authorization markers (e.g., role=admin).
• Configuration Audit: Envoy RBAC configurations using safe_regex matchers in action: DENY policies or action: ALLOW policies with invert_match, applied to HTTP header fields that may carry obs-text octets (Envoy Advisory).

Upgrade to Envoy versions 1.36.10, 1.37.6, 1.38.4, or 1.39.1, which fix the issue by switching the RE2 charset mode from UTF-8 to Latin1 (RE2::Options::EncodingLatin1) so that safe_regex correctly matches header values containing obs-text octets (Patch Commit). As a configuration workaround on unpatched versions, replace safe_regex patterns with RE2 byte-aware equivalents using \C* (e.g., change .*role=admin.* to \C*role=admin\C*), which restores correct 403 behavior for obs-text inputs. The behavioral change introduced by the patch can be temporarily reverted by setting the runtime guard envoy.reloadable_features.re2_use_latin1_mode to false, though this is not recommended as it re-exposes the vulnerability. Additionally, deployments can add upstream header validation to reject obs-text octets before they reach the RBAC filter (Envoy Advisory).

The vulnerability was discovered through Envoy's Google Patch Reward Program (PRP) by researcher Vincent550102, with remediation developed by Yan Avlasov (yanavlasov) and coordinated by Ryan Northey (phlax). The advisory notes a related prior issue, CVE-2026-26308 / GHSA-ghc4-35x6-crw5, which involved a different RBAC header DENY bypass via multi-value header concatenation; this CVE is distinct and reproduces on versions containing that fix. The issue was also picked up by downstream distributors including Amazon Linux (ALAS2ECS-2026-137, ALAS2023-2026-2149), openSUSE security announcements, and Istio (announcing 1.30.4), indicating broad ecosystem impact for service mesh deployments (Envoy Advisory).