Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
7 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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):…
Recommended action: Upgrade to 1.37.1, 1.36.5, 1.35.9 or 1.34.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Envoy’s mTLS certificate matcher for matchtypedsubjectaltnames 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: clientevil with OTHERNAME BMPSTRING = "evil" clientnull with OTHERNAME BMPSTRING = "victim\0evil" Configure Envoy with requireclientcertificate: true and a matchtypedsubjectaltnames entry for the OTHERNAME OID with matcher.exact: "victim". Connect without a client cert → connection rejected. Connect with clientevil → connection rejected. Connect with clientnull → connection accepted (but shouldn't!). Impact An attacker who can…
Recommended action: Upgrade to 1.36.3, 1.35.7, 1.34.11 or 1.33.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.reloadablefeatures.rejectearlyconnectdata 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.…
Recommended action: Upgrade to 1.36.3, 1.35.7, 1.34.11 or 1.33.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Envoy crashes when JWT authentication is configured with the remote JWKS fetching, allowmissingorfailed 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 allowmissingorfailed or allowmissing is enabled The client send 2 Authorization headers the remote JWKS fetching failed There will be crash Impact DoS and Crash Mitigation Disable the allowmissingorfailed or allowmissing
Recommended action: Upgrade to 1.36.3, 1.35.7, 1.34.11 or 1.33.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/envoyproxy/envoy >= 1.35.0, <= 1.35.0; >= 1.34.0, < 1.34.5
Fixed in
1.35.11.34.5· Vendor fix available
Issue
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.reloadablefeatures.dfpclusterresolveshosts 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.reloadablefeatures.dfpclusterresolveshosts runtime flag to…
Recommended action: Upgrade to 1.35.1 or 1.34.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Envoy's extproc HTTP filter is at risk of crashing if a local reply is sent to the external server due to the filter's life time issue. A known situation is the fail of a websocket handshake will trigger a local reply leading to the crash of Envoy. PoC If both websocket and extproc are enabled, a failed handshake will trigger a local reply, thus extproc will crash. Mitigation 1. Disable websocket traffic 2. Change the websocket response from backend to always return 101 Switch protocol based on RFC. 3. Apply the patch and the extproc filter will not send the local reply that is generated by Envoy to the extproc server for processing. 4. Apply the patch that the router will cancel the upstream requests when sending a local reply. Impact Denial of service Reporter Vasilios Syrakis Fernando Cainelli
Recommended action: Upgrade to 1.33.1, 1.32.4, 1.31.6 or 1.30.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Envoy 1.9.0 and before does not normalize HTTP URL paths. A remote attacker may craft a relative path, e.g., something/../admin, to bypass access control, e.g., a block on /admin. A backend server could then interpret the non-normalized path and provide an attacker access beyond the scope provided for by the access control policy.
Recommended action: Upgrade to 1.9.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.