CVE-2025-64527: Envoyproxy Envoy DOS Vulnerability

CVE-2025-64527 Overview

CVE-2025-64527 is a null pointer dereference vulnerability [CWE-476] in Envoy, a high-performance edge, middle, and service proxy widely deployed in service mesh architectures. The flaw affects the JSON Web Token (JWT) authentication filter when configured with remote JSON Web Key Set (JWKS) fetching. An attacker who can send authenticated requests with multiple JWT tokens can trigger an Envoy process crash when the remote JWKS fetch fails. The vulnerability stems from a re-entry bug in JwksFetcherImpl that corrupts internal state during asynchronous callback handling. Successful exploitation results in denial of service against Envoy proxy instances handling JWT-authenticated traffic.

Critical Impact
Remote attackers with low privileges can crash Envoy proxy instances, disrupting service availability for all traffic routed through the affected proxy.

Affected Products

Envoy versions prior to 1.33.12
Envoy versions prior to 1.34.10
Envoy versions prior to 1.35.6 and prior to 1.36.2

Discovery Timeline

2025-12-03 - CVE-2025-64527 published to NVD
2026-09-25 - Last updated in NVD database

Technical Details for CVE-2025-64527

Vulnerability Analysis

The vulnerability resides in Envoy's JWT authentication filter, specifically in the JwksFetcherImpl class responsible for retrieving remote JWKS data. When operators configure the filter with allow_missing_or_failed enabled, Envoy continues processing requests even when individual JWT validations fail. This mode allows multiple JWT tokens per request, with each token requiring its own JWKS fetch to validate the signature.

The crash occurs under a specific sequence of asynchronous events. When the first token's JWKS fetch fails, the onJwksError() callback runs synchronously and begins processing the second token. Processing the second token invokes fetch() on the same fetcher object, re-entering the fetcher while the original callback has not yet completed. The original callback then calls reset(), which clears the receiver_ and request_ members that now belong to the second fetch operation.

When the asynchronous HTTP response for the second fetch arrives, Envoy dereferences the cleared pointers and the process crashes. The result is a denial of service affecting all traffic traversing the Envoy instance.

Root Cause

The root cause is unsafe re-entry into JwksFetcherImpl::fetch() from within its own error callback. The fetcher object was not designed to be re-used before its current operation finished unwinding. The reset() call unconditionally clears state that may belong to a newly initiated fetch, producing a null pointer dereference [CWE-476] when the second fetch completes.

Attack Vector

Exploitation requires an attacker to send an HTTP request containing multiple JWT tokens in the configured header locations. The target Envoy must be configured with JWT authentication, remote JWKS fetching, and allow_missing_or_failed enabled. The attacker must also be able to induce a JWKS fetch failure, which can occur when the remote JWKS endpoint is unreachable, slow, or returns an error. No authentication to the Envoy admin interface is required, and no user interaction is needed.

See the Envoy GitHub Security Advisory GHSA-mp85-7mrq-r866 for upstream technical details.

Detection Methods for CVE-2025-64527

Indicators of Compromise

Unexpected Envoy worker process crashes or restarts coinciding with inbound requests containing multiple Authorization or custom JWT headers.
Spikes in failed outbound JWKS fetch requests from Envoy to configured identity providers immediately before a crash.
Repeated short-interval client requests from a single source containing multiple JWT tokens targeting JWT-protected routes.

Detection Strategies

Monitor Envoy stats for server.live transitions and http.jwt_authn.jwks_fetch_failed counter increases.
Correlate Envoy process restart events with access logs showing requests carrying more than one JWT token.
Alert on crash loops in Envoy pods within Kubernetes or service mesh deployments where the JWT authentication filter is enabled.

Monitoring Recommendations

Centralize Envoy access logs and admin stats into a SIEM for correlation of crash events with request patterns.
Track upstream JWKS endpoint availability and latency, since fetch failures are a precondition for exploitation.
Establish baseline rates of JWT authentication failures and alert on anomalies.

How to Mitigate CVE-2025-64527

Immediate Actions Required

Upgrade Envoy to version 1.33.12, 1.34.10, 1.35.6, 1.36.2, or later as soon as practical.
Audit JWT authentication filter configurations across all Envoy deployments and identify those with allow_missing_or_failed enabled.
Verify high availability of upstream JWKS endpoints to reduce the likelihood of fetch failures that enable the crash condition.

Patch Information

The Envoy maintainers released fixed versions 1.33.12, 1.34.10, 1.35.6, and 1.36.2. Refer to the Envoy GitHub Security Advisory GHSA-mp85-7mrq-r866 for the authoritative patch notes and backport information.

Workarounds

Disable allow_missing_or_failed in JWT authentication filter configurations where business requirements allow strict single-token validation.
Switch from remote JWKS fetching to a local JWKS configuration, which removes the asynchronous fetch path that triggers the bug.
Restrict the number of JWT tokens accepted per request at an upstream gateway or WAF layer before traffic reaches Envoy.

bash

# Example: disable allow_missing_or_failed in Envoy JWT authentication filter
# envoy.yaml snippet (illustrative)
http_filters:
  - name: envoy.filters.http.jwt_authn
    typed_config:
      "@type": type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication
      providers:
        provider1:
          issuer: https://issuer.example.com
          remote_jwks:
            http_uri:
              uri: https://issuer.example.com/.well-known/jwks.json
              cluster: jwks_cluster
              timeout: 5s
      rules:
        - match:
            prefix: /
          requires:
            provider_name: provider1
            # Avoid allow_missing_or_failed until patched versions are deployed