When an upstream sends a 100-continue header, which is handled by HCM, this causes has_continue_header_ to be set for the shared stream state, 100-continue encode to be performed to the downstream and continue_headers_continued_ to be set for the encoder stream filter state. When a previously paused decode filter chain is resumed, there is some common logic (shared by encode/decode active stream filters) that attempts to issue do100ContinueHeaders() on the decode path.

I have a reproducer that can trip this with the grpc-web filter; you need some filter that will allow headers to be sent to the backend, do a stop iteration in decodeData() and then resume at some point later. I imagine this impacts a bunch of 3rd party filters, Lua/Wasm filters etc. as well. I initially failed to get this to work with the buffer filter, since it buffers both headers/data.

This is not considered a security vulnerability, since the crash requires either an untrusted upstream (outside of the threat model) or a very specific combination of filter chain configuration, HCM config and timing. This has been confirmed by the OSS Envoy security team as being fixable in this repo.

This was discovered by the fuzz report https://oss-fuzz.com/testcase-detail/5674283828772864, where the do100ContinueHeaders() method in ActiveStreamDecoderFilter has its NOT_REACHED panic tripped.