CVE-2026-48521: Envoy Proxy NULL Pointer Dereference in HTTP/3 Connection Pool Allocation

Summary

CVE-2026-48521 is a medium-severity vulnerability in Envoy, an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.36.10, 1.37.6, 1.38.4, and 1.39.1, Envoy’s ProdClusterManagerFactory::allocateConnPool dereferences transport_socket_options while selecting an HTTP/3 connection pool without first checking whether the pointer is null. Under specific conditions involving HTTP/3 enabled protocol sets and contexts that return no transport-socket options, routine traffic can crash an Envoy worker thread. The issue is fixed in versions 1.36.10, 1.37.6, 1.38.4, and 1.39.1.

Technical Analysis

Envoy manages upstream connections through cluster connection pools. When a request needs to be proxied to an upstream host, Envoy selects an appropriate connection pool based on the configured protocol. With the introduction and expansion of HTTP/3 (QUIC-based) support, Envoy added logic to allocate HTTP/3 connection pools alongside the existing HTTP/1.1 and HTTP/2 pools.

The vulnerable code path resides in ProdClusterManagerFactory::allocateConnPool. This method is responsible for choosing which type of connection pool to create or reuse for a given upstream connection. When the protocol set includes HTTP/3 and the code determines that an HTTP/3 connection pool is appropriate, it dereferences a pointer called transport_socket_options. The problem is that this dereference occurs without a preceding null check.

Under normal circumstances for most traffic, transport_socket_options is populated and valid. However, certain LoadBalancerContext implementations used by synthetic, mirror, health-check, and async-client calls can return no transport-socket options. This means the pointer can be null in those specific contexts. When the auto_config mode is in use and HTTP/3 is enabled in the protocol set, routine traffic that reaches one of those contexts triggers the dereference of a null pointer, resulting in a crash of the Envoy worker process.

The scope boundary is important to understand. The affected branch requires two conditions to be met simultaneously: HTTP/3 must be present in the protocol set, and the context must be one that supplies no transport-socket options. If either condition is absent, the vulnerable code path is not reached. This explains why the vulnerability has a CVSS score of 5.9 with a high attack complexity: an attacker cannot simply send any request and expect a crash. The deployment must be configured with auto_config and HTTP/3, and the traffic must route through one of the specific context types that omit transport-socket options.

The CVSS vector string is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H. Breaking this down: the attack vector is network-based, meaning it can be triggered remotely. The attack complexity is high, reflecting the specific configuration and traffic conditions required. No privileges are needed and no user interaction is required. The scope is unchanged. The impact is confidentiality none, integrity none, and availability high. This is a denial-of-service vulnerability: it does not allow data theft or modification, but it can crash worker threads and degrade or eliminate service availability.

The CWE classification is CWE-476, which is the standard category for NULL pointer dereference vulnerabilities. This is a well-understood class of bug where a program attempts to read or write memory through a pointer that is null, leading to undefined behavior and typically a segmentation fault or access violation that terminates the process.

Affected Software and Versions

The vulnerability affects Envoy proxy prior to the following fixed versions:

Envoy versions prior to 1.36.10
Envoy versions prior to 1.37.6
Envoy versions prior to 1.38.4
Envoy versions prior to 1.39.1

The issue is fixed in versions 1.36.10, 1.37.6, 1.38.4, and 1.39.1. Users running any release branch older than these fixed versions should upgrade to the corresponding patched release for their branch.

Impact

The primary impact of CVE-2026-48521 is denial of service. When the vulnerability is triggered, an Envoy worker thread crashes. Envoy typically runs with multiple worker threads, so a single crash may not immediately take down the entire proxy. However, repeated triggering of the bug can crash multiple workers sequentially, eventually exhausting all worker threads and causing a complete service outage.

The availability impact is rated high in the CVSS scoring, reflecting the potential for significant service disruption. Since Envoy is commonly deployed as an edge proxy or service mesh sidecar in cloud-native environments, a crash can affect large numbers of downstream services and users. Traffic that was in flight on the crashed worker is lost, and clients may experience connection resets, timeouts, or errors until the worker is restarted or traffic is redistributed.

There is no confidentiality or integrity impact. The vulnerability does not allow an attacker to read sensitive data, inject malicious content, or modify traffic. The damage is limited to availability, but in production environments that rely on Envoy for critical routing and load balancing, even a temporary availability degradation can have serious operational consequences.

The high attack complexity rating means that exploitation requires specific conditions. Not all Envoy deployments are vulnerable. Only those with auto_config enabled and HTTP/3 in the protocol set, combined with traffic reaching synthetic, mirror, health-check, or async-client contexts, are at risk. This narrows the exposed population but does not eliminate the risk for deployments that match the vulnerable configuration profile.

Exploitation Scenario

Consider an organization that has deployed Envoy as an edge proxy with auto_config mode and HTTP/3 enabled in the upstream protocol set. The configuration includes mirror traffic policies that send shadow copies of requests to alternate upstream clusters for testing or analysis. Mirror traffic is one of the context types whose LoadBalancerContext implementation can return no transport-socket options.

Under this configuration, when a client request arrives and is mirrored to an upstream cluster, the mirror request flows through the connection pool allocation logic. Because HTTP/3 is in the protocol set and auto_config is active, the code attempts to select an HTTP/3 connection pool for the mirror request. The allocateConnPool method dereferences transport_socket_options without checking for null. Since the mirror context provides no transport-socket options, the pointer is null, and the worker thread crashes.

A similar scenario applies to health-check traffic. Envoy periodically sends health check requests to upstream hosts to determine their availability. If health-check contexts also return no transport-socket options and HTTP/3 is enabled, the periodic health check can trigger the crash. In this case, the crash may occur without any external attacker action at all, simply as a result of routine internal health checking.

Async-client calls represent another vector. Components within Envoy or extensions that use the async client API may issue internal requests that flow through the vulnerable path. If those calls use contexts without transport-socket options and HTTP/3 is enabled, the crash can be triggered by internal operations rather than external traffic.

An external attacker who knows or suspects that a target Envoy deployment uses HTTP/3 with auto_config and mirror policies could craft requests designed to trigger the mirror path. By sending repeated requests, the attacker could cause repeated worker crashes, degrading the service over time. However, the attacker would need knowledge of the target’s configuration, which contributes to the high attack complexity rating.

Detection and Mitigation

Detecting exploitation of this vulnerability involves monitoring Envoy worker processes for unexpected crashes. Key indicators include:

Worker process segfaults or abnormal terminations logged in system logs or Envoy’s own logging output.
Crash signatures pointing to ProdClusterManagerFactory::allocateConnPool or related connection pool allocation functions.
Sudden drops in active worker count or increases in worker restart events.
Client-facing errors such as connection resets, 502 or 503 responses, or timeouts that correlate with worker crash events.

Organizations should review their Envoy configurations to determine whether they are running a vulnerable version and whether HTTP/3 with auto_config is enabled. If HTTP/3 is not in use or auto_config is not enabled, the vulnerable code path is not reachable, and the risk is significantly reduced.

The primary mitigation is upgrading to a fixed version. Envoy 1.36.10, 1.37.6, 1.38.4, and 1.39.1 contain the fix for this issue. Administrators should identify their current release branch and upgrade to the corresponding patched release.

If immediate upgrading is not feasible, temporary mitigations may include:

Disabling HTTP/3 in upstream protocol sets where it is not required, which prevents the vulnerable code path from being reached.
Disabling or reconfiguring mirror, health-check, or async-client features that use contexts returning no transport-socket options, if operationally acceptable.
Switching from auto_config to explicit protocol configuration that does not include HTTP/3, if the deployment does not require HTTP/3 connectivity.
Increasing worker count and enabling automatic worker restart to improve resilience against individual worker crashes, though this does not prevent the underlying bug from being triggered.

Monitoring and alerting should be configured to detect worker crashes promptly so that operators can respond quickly if the vulnerability is triggered before the upgrade is completed.

Bug Bounty Angle

For bug bounty researchers and security engineers, CVE-2026-48521 illustrates the value of auditing code paths that handle optional or nullable parameters. The vulnerability is a classic NULL pointer dereference, but its subtlety lies in the interaction between multiple subsystems: HTTP/3 connection pool allocation, transport socket options, and specific LoadBalancerContext implementations.

Researchers investigating Envoy or similar proxy software should pay attention to:

Code paths that differ based on protocol selection, especially newer protocols like HTTP/3 that may have less mature integration with existing infrastructure.
Pointer dereferences that assume non-null values without explicit checks, particularly when the pointer originates from a context or interface that has multiple implementations with varying behavior.
Interactions between features that are independently tested but may produce unexpected combinations when used together, such as mirror traffic combined with HTTP/3.
Internal traffic sources like health checks and async clients that may exercise different code paths than normal proxy traffic and can reveal bugs invisible to standard functional testing.

The vulnerability also highlights the importance of fuzzing and stress testing with diverse configuration combinations. A bug that only manifests when HTTP/3, auto_config, and a specific context type coincide may not be found through testing with a single representative configuration. Researchers who systematically vary configuration parameters and traffic types are more likely to discover such issues.

From a bounty perspective, denial-of-service vulnerabilities in critical infrastructure components like Envoy are valuable findings. While they may not command the highest payouts compared to remote code execution or data exfiltration bugs, they represent real risk to production systems and are taken seriously by maintainers. The responsible disclosure of this issue through GitHub security advisories demonstrates the productive collaboration between researchers and the Envoy project.

Frequently Asked Questions

What versions of Envoy are affected by CVE-2026-48521?

Envoy versions prior to 1.36.10, 1.37.6, 1.38.4, and 1.39.1 are affected. The issue is fixed in those four versions respectively.

What conditions are required for the vulnerability to be triggered?

The vulnerable code path requires HTTP/3 in the protocol set with auto_config enabled, and traffic must reach a context such as synthetic, mirror, health-check, or async-client calls that returns no transport-socket options.

Does this vulnerability allow remote code execution or data theft?

No. The vulnerability is a NULL pointer dereference that results in a worker thread crash. It impacts availability only, with no confidentiality or integrity impact.