Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft header preserving marker plus obs-text octet
-
DeliverySend request to Envoy RBAC filter
-
Exploitsafe_regex RE2 UTF-8 match returns false
-
ExecutionNegative RBAC policy no-matches, request not denied
-
ImpactRequest reaches route intended to be denied
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A05:2025 - Injection
ASVS 5.0
V2 - Validation and Business Logic Input validation, allowlisting
|
| Exploitation Conditions | Requires an Envoy deployment (versions prior to 1.36.10/1.37.6/1.38.4/1.39.1) whose HTTP RBAC filter uses a NEGATIVE (DENY) policy evaluating a safe_regex matcher against header values, combined with a byte-oriented route matcher that still observes the raw header bytes. Exploitation does NOT work against positive ALLOW regexes (which fail closed) or against exact, prefix, suffix, or contains matchers, which are not shown to have this subject-domain failure. The attacker needs no authentication or user interaction (PR:N/UI:N) and only needs to inject an obs-text octet (e.g. 0xFF) alongside a prohibited marker into a request header; the limiting factor is entirely the specific safe_regex-in-negative-policy configuration, not attacker privilege. The default-on runtime guard envoy.reloadable_features.re2_use_latin1_mode remediates it once upgraded, and can be reverted to reintroduce the old behavior. |
| Impact | This is a genuine access-control bypass in Envoy's HTTP RBAC filter, but its real-world exploitability is tightly gated by configuration. The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, 7.5 HIGH) reflects a network-reachable, unauthenticated attacker (PR:N/UI:N) able to reach a route that a policy intended to deny. However, exploitation only works when the deployment uses a NEGATIVE (DENY) RBAC policy that evaluates a safe_regex header matcher AND a byte-oriented route matcher observes the same header - positive ALLOW regexes fail closed and exact/prefix/suffix/contains matchers are not affected, so many RBAC deployments are not vulnerable. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data; the issue was privately reported (GitHub_M) and fixed with vendor test cases rather than surfacing from in-the-wild activity. Net: a real priority for organizations running affected Envoy versions with safe_regex-based DENY rules, but not a mass-exploited or automatable threat on the current evidence. The C:H rating with I:N/A:N is defensible for a route-reachability bypass, though a reached 'denied' route could in principle expose write functionality - vendor scoped impact to confidentiality only. |
| Exploit ScenarioDerived | An attacker sends a normal HTTP request to an Envoy-fronted service but appends an unrelated obs-text octet (e.g. 0xFF) to a header value while preserving the prohibited marker. RE2's UTF-8 subject semantics cause FullMatch to return false, so the negative RBAC policy treats the header as an ordinary no-match and does not deny, while a byte-oriented route matcher still routes the request to the restricted backend. No public proof-of-concept is identified; the vendor's committed test cases (e.g. matching against 'w\xFEw.cncf.io') demonstrate the mechanism. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 21, 2026
An access-control bypass in Envoy Proxy (all versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1) allows unauthenticated remote clients to reach routes that HTTP RBAC policies were configured to deny, resulting in disclosure of protected content. The flaw only materializes when a NEGATIVE (DENY) policy uses a safe_regex matcher against header values and a byte-oriented route matcher independently reads the raw header bytes; positive ALLOW regexes fail closed and exact, prefix, suffix, and contains matchers are unaffected. No public exploit code has been identified at time of analysis, and the vendor has released fixed versions, so real-world risk is driven almost entirely by whether a deployment uses that specific safe_regex-in-negative-policy configuration.
RemediationAI
Vendor-released patch: upgrade to Envoy 1.36.10, 1.37.6, 1.38.4, or 1.39.1, which switch safe_regex evaluation to Latin1 charset mode via commit 5650cb9770d4420ec2bcbed8b90be06f564ecc07 (see advisory GHSA-23xh-2qxr-3xv8 and the four release tags in the references). The fix is controlled by the runtime guard envoy.reloadable_features.re2_use_latin1_mode, which is enabled by default in patched builds - verify it has not been overridden to false, since setting it to false reintroduces the vulnerable UTF-8 subject semantics. For deployments that cannot upgrade immediately, avoid negative (DENY) RBAC policies that evaluate safe_regex against header values and replace them with exact, prefix, suffix, or contains matchers, or restructure the policy so the protected paths are governed by positive ALLOW rules, which fail closed; the trade-off is that these matcher types are less expressive than regex and the policy must be reviewed for equivalent coverage. No vendor workaround beyond policy restructuring and the runtime guard is identified in the available data.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
The root cause is improper input validation (CWE-20) at the boundary between HTTP header semantics and RE2's subject encoding assumptions. HTTP header field values are RFC-valid opaque byte strings that may contain obs-text octets (0x80-0xFF) and are not guaranteed to be UTF-8, but Envoy's safe_regex matcher was constructed with RE2's default UTF-8 subject mode. When a downstream client appends an unrelated obs-text octet to a header while preserving a prohibited marker, the subject becomes invalid UTF-8, so RE2::FullMatch returns false. In a negative RBAC policy, that false result is interpreted as an ordinary no-match - i.e., the marker was not seen - while a byte-oriented route matcher still observes the marker and routes the request to a destination intended to be denied. The upstream fix in commit 5650cb9770d4420ec2bcbed8b90be06f564ecc07 switches the safe_regex character set from UTF-8 to Latin1 via a new RE2::Options with EncodingLatin1, so every byte value maps to a character and matching no longer fails on non-UTF-8 subjects. This behavioral change is gated by the runtime feature guard envoy.reloadable_features.re2_use_latin1_mode, which defaults to enabled in patched builds and can be set to false to temporarily restore the old UTF-8 behavior. Added tests (SafeRegexValueLatin1, SafeRegexValueUtf8, RequestedServerNameNonUtf8) confirm the difference in subject-domain handling.
Know when Envoy gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
Unauthenticated network attacker crafts a header to bypass a DENY RBAC policy (PR:N/UI:N/AC:L); vendor scopes impact to reaching a protected route so C:H, I:N/A:N, S:U.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
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.
Technical POC Analysis
Advisory: GHSA-23xh-2qxr-3xv8.
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
Envoy Proxy, the traffic-routing component that sits at the front door of many service-mesh and API-gateway deployments, has an access-control gap that can let requests reach protected routes which policy was meant to deny, exposing content the organization believed was restricted. The exposure is not universal: it only materializes in deployments that combine a negative (DENY) RBAC policy using a safe_regex header matcher with a byte-oriented route matcher, so the real question for leadership is a targeted configuration-inventory question rather than a fleet-wide emergency. Where that pattern exists, the affected routes have effectively been unprotected for the duration of the flaw, and the impacted parties are whoever was relying on those routes being gated.
Structured patch data indicates no vendor patch is currently available, though the advisory text names fixed releases 1.36.10, 1.37.6, 1.38.4 and 1.39.1 - validate and apply those as the primary remediation. Until upgrades are complete: replace safe_regex matchers in negative (DENY) RBAC policies with exact, prefix, suffix or contains matchers; prefer positive (ALLOW) regex policies, which fail closed; avoid pairing negative header-regex policies with byte-oriented route matchers; and add edge/WAF rules plus alerting on access to the affected routes. Exploitation status: no public exploit identified at time of analysis.
Threat Intelligence Overview
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
Envoy is an open source edge and service proxy designed for cloud-native applications. Rated critical severity (CVSS 9.8
An issue was discovered in Envoy 1.12.0. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable,
An issue was discovered in Envoy 1.12.0. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable,
Envoy is an open source edge and service proxy designed for cloud-native applications. Rated critical severity (CVSS 9.1
Envoy is an open source edge and service proxy designed for cloud-native applications. Rated critical severity (CVSS 9.1
Envoy is an open source edge and service proxy designed for cloud-native applications. Rated critical severity (CVSS 9.1
Envoy through 1.15.0 only considers the first value when multiple header values are present for some HTTP headers. Rated
When parsing HTTP/1.x header values, Envoy 1.9.0 and before does not reject embedded zero characters (NUL, ASCII 0x0). R
Envoy's RBAC filter improperly concatenates duplicate HTTP headers into comma-separated strings instead of validating ea
Envoy is a cloud-native high-performance edge/middle/service proxy. Rated high severity (CVSS 7.5), this vulnerability i
Envoy is a cloud-native high-performance edge/middle/service proxy. Rated high severity (CVSS 7.5), this vulnerability i
Same weakness CWE-20 – Improper Input Validation
View allSame technique Information Disclosure
View allVendor StatusVendor
SUSE
| Product | Status |
|---|---|
| openSUSE Tumbleweed | Fixed |
EUVD-2026-84104
NVD
CVE.org
EPSS
Vulnrichment
GitHub
Exploit-DB