What is the CVSS score of EUVD-2026-84104?

EUVD-2026-84104 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N. EPSS exploitation probability: 0.7%.

How to fix or mitigate EUVD-2026-84104?

Within 24 hours, inventory every Envoy Proxy instance and identify any version prior to 1.36.10, 1.37.6, 1.38.4 or 1.39.1, then grep the running configuration for negative (DENY) HTTP RBAC policies that use safe_regex matchers against header values and that sit in front of byte-oriented route matchers; where that combination is found, treat the affected routes as unenforced and immediately replace the negative safe_regex matcher with an exact, prefix, suffix or contains matcher, or invert it into a positive ALLOW regex policy, which fails closed, and review access logs for those paths for anomalous or unexpected retrieval. Within 7 days, upgrade every affected instance to the vendor-released fixed versions 1.36.10, 1.37.6, 1.38.4 and 1.39.1 respectively, staging the change in non-production first and validating with regression tests that the DENY behavior is actually enforced at the route level before promoting to production; apply vendor patch across the remainder of the estate and confirm no deprecated RBAC matcher patterns survive the upgrade. Within 30 days, add configuration linting to the CI/CD pipeline that blocks safe_regex matchers inside negative policies unless an explicit exception is approved, re-baseline the proxy hardening standard against the vendor advisory, audit for other authorization-bypass patterns of the same class across the mesh and gateway tier, and fold this scenario into the vulnerability management cadence so proxy data-plane weaknesses are triaged with the same urgency as application findings. Note that the structured advisory data marks this as having no available patch while the advisory text names the fixed releases above - confirm patch availability directly with the vendor before relying on either signal.

Envoy Proxy EUVD-2026-84104

Q: Which versions of Envoy Proxy are affected by EUVD-2026-84104?

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…. A patch is available.

| CVE-2026-73552 HIGH

Improper Input Validation (CWE-20)

2026-09-21 GitHub_M

Information Disclosure Red Hat Envoy Suse Envoyproxy

7.5

CVSS 3.1 · Vendor: GitHub_M

View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

Access

Craft header preserving marker plus obs-text octet
Delivery

Send request to Envoy RBAC filter
Exploit

safe_regex RE2 UTF-8 match returns false
Execution

Negative RBAC policy no-matches, request not denied
Impact

Request reaches route intended to be denied

Vulnerability Assessment

Weakness	CWE CWE-20 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.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).

Patch available 0.7% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – 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

envoy < 1.36.10

envoy 1.38.0, < 1.38.4

envoy 1.39.0, < 1.39.1

envoy 1.37.0, < 1.37.6

Affected Packages

euvd envoy fix: 1.36.10, 1.37.6, 1.38.4, 1.39.1

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

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

vuln.today AI 7.5 HIGH

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.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Red Hat 7.5 HIGH

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

None

Availability

None

Lifecycle Timeline

Patch available

Sep 21, 2026 - 21:17 EUVD

CVE Published

Sep 21, 2026 - 19:37 cve.org

HIGH 7.5

DescriptionCVE.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

Why It Matters

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.

Business Impact: High

Compensating Controls

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

EPSS Score

0.7%

Top 50% exploitable

Prevalence

High

Envoy is a core cloud-native proxy underpinning service meshes and API gateways

Data Quality

6 sources

Confidence: High

EUVD 🇯🇵JVN

NVD

CVE.org

EPSS

Vulnrichment Vendor

GitHub

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.

SignalValue

Severity HIGH

CISA KEV No

Public POC No

EPSS 0.7%

Patch available Yes

Active threat No

Deciding rule

HIGH severity (CVSS 7.0-8.9)

What every action level means

Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.

Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.

This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.

This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.

Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision

Scheduled

Exploitation

None

System Exposure· derived

Open

Automatable

Yes

Human Impact

High

Technical Impact

Partial

Priority Score

Low Medium High Critical

KEV: 0

EPSS: +1

CVSS: +38

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

Information Disclosure MEDIUM

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.