CVE-2026-26308: 
Envoy vulnerability analysis and mitigation

CVE-2026-26308 is an RBAC Header Validation Bypass vulnerability in Envoy Proxy caused by improper multi-value HTTP header concatenation. The Envoy RBAC filter concatenates multiple values for the same header name into a single comma-separated string instead of evaluating each value individually, allowing attackers to bypass "Deny" rules using exact-match mechanisms. Affected versions include all releases prior to 1.34.13, 1.35.9, 1.36.5, and 1.37.1. The vulnerability was published on March 10, 2026, with patches released the same day. It carries a CVSS v3.1 score of 7.5 (High) per the GitHub Advisory, and 8.2 (High) per Feedly/NVD scoring (Github Advisory, Envoy Security Advisory).

The root cause is a logic flaw (CWE-863: Incorrect Authorization; CWE-20: Improper Input Validation) in Envoy's RBAC filter HeaderMatcher, which calls getAllOfHeaderAsString() to retrieve header values and concatenates them into a comma-separated string before performing exact-match evaluation. When an attacker sends a request with the same header repeated (e.g., internal: true twice), Envoy concatenates the values into "true,true", which does not match the exact string "true", causing the Deny rule to fail silently and the request to be allowed. The fix introduces a new matchesHeadersIndividually() method and a runtime feature flag (envoy.reloadable_features.rbac_match_headers_individually) that iterates over each header value separately before making an authorization decision (Envoy Security Advisory, Fix Commit).

An unauthenticated remote attacker can bypass RBAC "Deny" policies enforced via exact-match header rules, gaining unauthorized access to sensitive internal resources or administrative endpoints that should be blocked. The primary impact is high confidentiality loss (access to restricted data) and low integrity impact (unauthorized actions on protected resources), with no availability impact. Deployments using header-based access control in service mesh or API gateway configurations — particularly those relying on Envoy as an edge or sidecar proxy — are most at risk, and successful exploitation could enable lateral movement within a microservices environment (Github Advisory, Envoy Security Advisory).

A proof-of-concept is publicly available within the official security advisory, which provides concrete reproduction steps demonstrating how to trigger the bypass using duplicate HTTP headers — no additional tooling or research is required (Envoy Security Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.028% (0.003% per GitHub Advisory), indicating a low current probability of exploitation. The vulnerability is not listed in the CISA KEV catalog. Detection is available via Nessus (plugin 304594) and Qualys (362097, 362063) (Github Advisory).

1. Reconnaissance: Identify Envoy proxy deployments running versions prior to 1.34.13, 1.35.9, 1.36.5, or 1.37.1 that use RBAC filters with header-based "Deny" rules using exact-match logic (e.g., blocking requests where internal: true).
2. Identify target header and rule: Determine which HTTP header is used in the RBAC Deny policy (e.g., x-internal: true or internal: true) by reviewing exposed configuration, documentation, or probing responses.
3. Craft bypass request: Construct an HTTP request that includes the target header twice — once with the blocked value and once with any other value:

GET /restricted-resource HTTP/1.1
Host: example.com
internal: true
internal: true

4. Send the request: Transmit the crafted request to the Envoy proxy. Envoy concatenates the header values into "true,true", which does not match the exact string "true", causing the Deny rule to fail.
5. Access restricted resource: The request is forwarded to the upstream service and the attacker receives a 200 OK response, gaining unauthorized access to the protected resource (Envoy Security Advisory, Github Advisory).

• Network: HTTP requests to protected endpoints containing the same header name repeated multiple times (e.g., internal: true and internal: true or x-internal: true with an additional x-internal: <other_value>) that result in 200 OK responses instead of expected 403 Forbidden.
• Logs: Envoy access logs showing requests to restricted paths (e.g., /restricted-resource, /admin, /internal/*) with 200 response codes where RBAC Deny rules should have triggered; absence of rbac_access_denied_matched_policy in response code details for requests containing duplicate sensitive headers.
• Logs: Unusual patterns of repeated header names in raw request logs, particularly for headers used in RBAC policy definitions.
• Network: Unexpected upstream traffic to internal or administrative services originating from external-facing Envoy listeners, suggesting RBAC bypass.

Upgrade Envoy to one of the patched versions: 1.34.13, 1.35.9, 1.36.5, or 1.37.1 depending on your current release branch (Github Advisory). As an interim workaround prior to upgrading, enable the runtime feature flag envoy.reloadable_features.rbac_match_headers_individually=true to activate the per-value header matching behavior introduced in the fix (Fix Commit). Additionally, review existing RBAC policies and consider replacing exact-match rules with regex-based matchers that can handle comma-separated multi-value header strings as a defense-in-depth measure. Amazon Linux 2 ECS users should apply the ALAS2ECS-2026-100 advisory update.

The Istio project released version 1.29.1 on the same day as the Envoy advisory, referencing this CVE as part of its dependency updates (Istio Release). The vulnerability was credited to researcher Dor Konis, with remediation developed by botengyao and coordinated by phlax and agrawroh from the Envoy project (Envoy Security Advisory). Social media coverage was limited, with brief mentions on Bluesky and automated CVE tracking feeds, reflecting the niche but significant impact on service mesh deployments.