CVE-2026-73552 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, 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.
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 such as Role-Based Access Control or RBAC. The vulnerability described herein resides within the HTTP RBAC implementation of Envoy versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1. This flaw stems from a fundamental mismatch in how header values are processed during security policy evaluation versus route matching. Specifically, while the system accepts RFC-compliant opaque header bytes for RBAC checks, it evaluates safe_regex patterns using RE2 library semantics that enforce UTF-8 subject constraints. This discrepancy creates an inconsistency between the logical interpretation of the request by the access control layer and the actual routing logic applied downstream.
The technical core of this vulnerability lies in how regular expression matching handles invalid or non-UTF-8 sequences within header values. When a client submits a header containing prohibited markers alongside unrelated obs-text octets, the RE2 engine's FullMatch function returns false due to UTF-8 validation failures rather than logical pattern mismatch. In standard security logic, a failure to match a deny rule should result in denial or further evaluation of allow rules. However, because the regex engine treats the invalid subject as a non-match for the specific safe_regex constraint, the RBAC policy interprets this as a negative outcome that does not trigger the intended block. Consequently, requests containing these malformed headers bypass the restrictive policies designed to deny them, effectively allowing unauthorized access or data exfiltration paths that were supposed to be closed.
This behavior represents a significant security control failure where byte-oriented route matchers can still observe and process the marker bytes even though the RBAC layer failed to block them based on regex semantics. The scope of this issue is limited primarily to plain positive ALLOW regexes, which normally operate with a fail-closed mechanism but are undermined here by the UTF-8 validation error. Other matcher types such as exact, prefix, suffix, and contains do not exhibit this subject-domain failure because they rely on different matching logic that does not depend on RE2's strict UTF-8 interpretation in the same manner. This selective vulnerability means that attackers can craft specific HTTP headers with carefully constructed invalid byte sequences to evade detection by regex-based allow lists while still being routed to protected backend services, thereby bypassing intended access restrictions.
From a classification perspective, this issue aligns with CWE-20 Improper Input Validation and CWE-862 Missing Authorization, as the system fails to correctly validate input against security policies due to implementation-specific parsing errors. In terms of MITRE ATT&CK mapping, this vulnerability facilitates lateral movement or unauthorized access by allowing an attacker to bypass authentication or authorization controls through header manipulation, which can be categorized under T1078 Valid Accounts if used for privilege escalation or generally as a technique to evade detection mechanisms within the application layer. The impact is severe because it undermines the integrity of RBAC policies that are often relied upon to enforce least-privilege access in microservices architectures.
To mitigate this vulnerability, organizations running affected versions of Envoy must upgrade immediately to version 1.36.10 or later for the 1.36 branch, 1.37.6 or later for the 1.37 branch, 1.38.4 or later for the 1.38 branch, and 1.39.1 or later for the 1.39 branch. These releases contain patches that correct the handling of opaque header bytes to ensure consistent evaluation across both RBAC policy checks and route matching logic. Until upgrades are performed, administrators should consider implementing additional input validation at the network perimeter using Web Application Firewalls configured to reject headers containing non-UTF-8 sequences or invalid octets that could trigger this specific regex failure mode. Regular auditing of access logs for requests with malformed header values can also help in detecting potential exploitation attempts while mitigation strategies are being deployed.