CVE-2026-47221: Envoy HTTP 303 Redirect Null Pointer Dereference DoS Vulnerability

Technical summary

The vulnerability is a null pointer dereference (CWE-476) in Envoy's router filter when handling HTTP 303 (See Other) internal redirects. The code path assumes a request body buffer exists for all requests undergoing 303 redirect processing when internal_redirect_policy includes 303 in redirect_response_codes. However, for body-less requests (POST, PUT, DELETE, PATCH without Content-Length or request body), no buffer is allocated during request initialization. When the upstream server responds with HTTP 303 and the redirect handler attempts to drain the (non-existent) body buffer, a null pointer dereference occurs, triggering a segmentation fault that terminates the Envoy process. The vulnerability requires both a specific configuration (internal redirect policy with 303 enabled) and an upstream that returns 303, but no authentication is needed. Affected versions span 1.18.0 to 1.35.12, 1.36.8, 1.37.4, and 1.38.2. Patches exist in versions 1.35.13, 1.36.9, 1.37.5, and 1.38.3.

Business impact

Envoy is a critical infrastructure component in Kubernetes, service mesh deployments (Istio, Consul Connect), and cloud-native architectures. A crash vulnerability directly translates to loss of traffic routing and API gateway functionality. For organizations relying on Envoy for ingress control, east-west service communication, or edge proxy duties, exploitation results in complete outage of affected traffic paths. The impact scales with deployment: a single vulnerable Envoy instance affects all workloads behind it, and in load-balanced scenarios, attackers can knock out instances sequentially. Recovery requires manual intervention and restart, during which connections are lost. This is especially dangerous in zero-trust or service mesh contexts where Envoy is the security enforcement point. No data breach occurs, but availability impact is total and immediate.

Affected systems

Envoy versions from 1.18.0 up to (and including) 1.35.12, 1.36.8, 1.37.4, and 1.38.2 are vulnerable. The vulnerability is patched in 1.35.13, 1.36.9, 1.37.5, and 1.38.3. Only Envoy instances with internal_redirect_policy configured to include HTTP 303 in redirect_response_codes are affected; default configurations without explicit 303 redirect handling are not vulnerable. Additionally, the upstream server must actually respond with HTTP 303 for the crash to occur. Exposure is highest in organizations using Envoy with service mesh (Istio, Consul), API gateway setups, or custom internal redirect policies. Projects embedding Envoy as a dependency and not updating to patched versions also remain at risk.

Exploitability

Exploitability is moderate in specific configurations and high once those conditions are met. An attacker must know or guess that the target Envoy instance has internal_redirect_policy with 303 enabled—this is not always obvious from external observation but may be inferred through targeted HTTP requests or reconnaissance. No authentication is required; the attacker sends a simple POST, PUT, DELETE, or PATCH request with no body to a Envoy route that will trigger a 303 response from the upstream. The attack is deterministic: if the conditions align, every such request crashes Envoy. Exploitation requires network access to the Envoy instance (typically not public-facing, but accessible within the organization or from the internet if exposed). The attack is repeatable and can be automated to cause sustained denial of service. There is no known public exploit code in the wild as of the advisory date, and no active KEV listing, but the simplicity of the trigger makes exploitation a moderate concern once patches are available and organizations begin awareness.

Remediation

Upgrade affected Envoy instances to patched versions: 1.35.13 or later (if on 1.35.x), 1.36.9 or later (if on 1.36.x), 1.37.5 or later (if on 1.37.x), or 1.38.3 or later (if on 1.38.x). Organizations should also review internal_redirect_policy configurations and confirm whether 303 redirects are truly necessary for their use cases; if not, remove 303 from redirect_response_codes to immediately eliminate the vulnerability until patching is complete. For Envoy deployments in Kubernetes or service mesh, consult your distribution's release notes (Istio, Consul, etc.) for patched versions and upgrade schedules. If immediate patching is not feasible, consider network-level mitigations: limit upstream servers' ability to send 303 responses, or restrict traffic patterns that would trigger the vulnerable code path (though these are incomplete workarounds).

Patch guidance

Patches are available in Envoy 1.35.13, 1.36.9, 1.37.5, and 1.38.3. Identify your current Envoy version (envoy --version) and upgrade within your release track. If you are running an LTS or stable release, verify that your distribution (Istio, Consul, Kubernetes gateway implementations, etc.) has released a patched container image or binary before upgrading. Test the patched version in a non-production environment first, especially if you rely on internal redirect policies for critical traffic flows. Rolling updates are recommended to avoid complete service interruption. If you cannot upgrade immediately, audit your route configurations to disable 303 in redirect_response_codes where safe to do so, and monitor logs for any crash events (segmentation faults in Envoy logs) that may indicate exploitation attempts.

Detection guidance

Monitor Envoy access logs and error logs for segmentation faults, core dumps, or unexpected process exits correlated with HTTP 303 responses. If using systemd or container orchestration, watch for Envoy process restarts with non-zero exit codes (particularly SIGSEGV, signal 11). Correlation between incoming POST/PUT/DELETE/PATCH requests with no body and upstream 303 responses, followed by Envoy restarts, is a strong indicator of exploitation. In Prometheus or similar observatories, create alerts for increases in Envoy process restarts or failed health checks on instances with internal_redirect_policy enabled. Intrusion detection signatures can look for repeated requests to the same path from the same source, especially if they precede Envoy crashes; this pattern suggests an attacker testing for the vulnerability. Network segmentation and access controls that limit which clients can send requests to Envoy are preventive controls.

Why prioritize this

Although CVSS 5.9 (MEDIUM) reflects limited attack complexity and availability impact without confidentiality or integrity loss, the real-world risk to Envoy deployments is elevated. Envoy is foundational infrastructure; its crash is not a degradation but a complete outage. The ease of exploitation (simple HTTP request, no special tools) and lack of authentication requirements make this a 'high-likelihood, high-impact' scenario despite the moderate CVSS score. Organizations running service meshes, API gateways, or ingress controllers on Envoy should prioritize this patch in the same tier as severity-critical issues for infrastructure. Conversely, teams using Envoy only as a sidecar proxy in non-critical paths or with default configs (no 303 redirects) can defer slightly, but should not ignore it.

Risk score, explained

CVSS 5.9 reflects: Network-accessible attack vector (AV:N), high attack complexity (AC:H, because internal redirect policy and 303 upstream response must both be configured/triggered), no privileges required (PR:N), no user interaction (UI:N), scope unchanged, no confidentiality or integrity impact (C:N, I:N), but high availability impact (A:H). The AC:H elevates the base score below 7.0. However, in real deployments where the prerequisites are met, the effective score is higher due to the certainty of exploitation and severity of the impact. The CVSS does not account for Envoy's critical infrastructure role or the attacker's ability to cause a complete outage without authentication.

Frequently asked questions