CVE-2026-26308: Envoyproxy Envoy Auth Bypass Vulnerability

CVE-2026-26308 Overview

CVE-2026-26308 is an authorization bypass vulnerability in the Envoy proxy Role-Based Access Control (RBAC) filter. The flaw exists in how Envoy validates HTTP headers when multiple values are present for the same header name. Instead of validating each header value individually, Envoy concatenates all values into a single comma-separated string before matching. Attackers exploit this behavior to bypass RBAC Deny rules by sending duplicate headers, obscuring malicious values from exact-match policies. The vulnerability affects Envoy versions prior to 1.37.1, 1.36.5, 1.35.8, and 1.34.13. The issue is classified under CWE-863: Incorrect Authorization.

Critical Impact
Remote unauthenticated attackers can bypass RBAC Deny policies in Envoy, gaining unauthorized access to protected upstream services and resources.

Affected Products

Envoy proxy versions prior to 1.34.13
Envoy proxy versions 1.35.0 through 1.35.7, 1.36.0 through 1.36.4
Envoy proxy versions 1.37.0 (fixed in 1.37.1)

Discovery Timeline

2026-03-10 - CVE-2026-26308 published to NVD
2026-03-11 - Last updated in NVD database

Technical Details for CVE-2026-26308

Vulnerability Analysis

The Envoy RBAC filter enforces authorization decisions based on attributes of incoming HTTP requests, including header values. Operators commonly define Deny rules that reject requests containing specific header values. The filter relies on exact-match logic to determine whether an incoming header value matches a policy condition.

The vulnerability stems from how Envoy handles repeated headers. HTTP allows the same header field name to appear multiple times in a request. When this occurs, Envoy concatenates all values into a single comma-separated string before performing the policy match. An exact-match Deny rule looking for the string admin will not match a concatenated value such as admin,user or user,admin. The request bypasses the deny rule and reaches the upstream service.

This affects deployments that use Envoy as an authorization enforcement point in service mesh, API gateway, or edge proxy configurations. The fix changes the RBAC filter to evaluate each header value independently rather than against the concatenated representation.

Root Cause

The root cause is an inconsistency between HTTP header semantics and the matching logic in the RBAC filter. The filter assumes a single canonical value per header but receives a joined string when duplicate headers are present. Policy authors writing exact-match conditions have no way to anticipate the concatenation behavior, producing a gap between intended and actual enforcement.

Attack Vector

An unauthenticated remote attacker crafts an HTTP request that includes the targeted header name twice. One copy carries an arbitrary value, and the other carries the value the RBAC policy is designed to block. Because the concatenated string does not equal any single configured deny value, the request is permitted. The attacker reaches resources that the policy was intended to protect, achieving unauthorized read or limited write access on the upstream service.

The vulnerability is network-reachable, requires no privileges, and requires no user interaction. The vulnerability is described in prose because no public proof-of-concept code is referenced in the advisory. See the GitHub Security Advisory GHSA-ghc4-35x6-crw5 for vendor details.

Detection Methods for CVE-2026-26308

Indicators of Compromise

HTTP requests containing duplicate occurrences of the same header name, particularly headers referenced in RBAC policies such as x-user, x-role, or authorization.
Access log entries showing successful requests to endpoints that should be blocked by a configured Deny rule.
Upstream service activity from identities or paths that RBAC policies are designed to reject.

Detection Strategies

Inspect Envoy access logs for requests where header values appear as comma-separated lists when policy logic expects a single token.
Correlate authorization decisions logged by the RBAC filter with upstream response codes to identify requests that should have been denied.
Run synthetic probes that send duplicate headers against test routes to confirm whether deployed Envoy versions exhibit the bypass behavior.

Monitoring Recommendations

Enable verbose RBAC filter logging to capture matched and unmatched policy decisions for forensic review.
Forward Envoy access and audit logs to a centralized analytics platform and alert on duplicate-header patterns targeting sensitive routes.
Track Envoy build versions across the fleet to identify proxies still running affected releases.

How to Mitigate CVE-2026-26308

Immediate Actions Required

Upgrade Envoy to 1.37.1, 1.36.5, 1.35.8, or 1.34.13 depending on the deployed minor release.
Audit existing RBAC policies that rely on exact header matches and identify routes exposed to untrusted clients.
Review recent access logs for evidence of duplicate-header requests against protected endpoints.

Patch Information

The vendor fixed the issue in Envoy versions 1.37.1, 1.36.5, 1.35.8, and 1.34.13. The corrective change is available in the upstream commit b6ba0b2294b98484fb0ed8556897d1073cc27867. Full details and version mapping are published in the Envoy Security Advisory GHSA-ghc4-35x6-crw5.

Workarounds

Place an upstream component that normalizes or rejects duplicate occurrences of headers consumed by RBAC policies before traffic reaches Envoy.
Rewrite RBAC policies to use safe_regex matchers that detect target values within concatenated strings instead of relying on exact matches.
Restrict client-supplied headers at the ingress boundary so untrusted callers cannot submit the header names that drive authorization decisions.

bash

# Example: strip and re-add a sensitive header at the ingress listener
# so downstream RBAC policies see a single, server-controlled value.
http_filters:
  - name: envoy.filters.http.header_to_metadata
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.header_to_metadata.v3.Config
      request_rules:
        - header: x-role
          on_header_present:
            key: role
            type: STRING
          remove: true