CVE-2026-73552: Envoy: HTTP RBAC safe_regex can fail open on RFC-valid obs-text header values
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 saferegex 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Envoyto a version that resolves this vulnerability.Fixed in 1.36.10 - Upgrade
Upgrade
Envoyto a version that resolves this vulnerability.Fixed in 1.37.6 - Upgrade
Upgrade
Envoyto a version that resolves this vulnerability.Fixed in 1.38.4 - Upgrade
Upgrade
Envoyto a version that resolves this vulnerability.Fixed in 1.39.1
Event History
Frequently Asked Questions
Which RBAC configurations are exposed to this bypass?
The affected pattern is a negative HTTP RBAC policy using a safe_regex matcher against header values. Plain positive ALLOW regexes normally fail closed, and exact, prefix, suffix, and contains matchers are not shown to be affected by this subject-domain mismatch.
What does an attacker need to exploit the issue?
An unauthenticated downstream client must be able to send a request with an RFC-valid opaque header value containing both a prohibited marker and an unrelated obs-text octet. The bypass depends on a byte-oriented route matcher still recognizing the prohibited marker after the negative regex policy treats the invalid UTF-8 subject as a no-match.
Which Envoy versions contain fixes?
The issue is fixed in Envoy 1.36.10, 1.37.6, 1.38.4, and 1.39.1. Versions before those releases are affected.
What can be done before upgrading?
Avoid relying on negative safe_regex RBAC policies for header-based denial where untrusted clients can supply opaque header bytes. Use exact, prefix, suffix, or contains matching where it meets the policy requirement, as these matchers are not shown to have this failure.