Envoy is a cloud-native edge/middle/service proxy. Prior to versions 1.34.1, 1.33.3, 1.32.6, and 1.31.8, Envoy's URI template matcher incorrectly excludes the character from a set of valid characters in the URI path. As a result URI path containing the character will not match a URI template expressions. This can result in bypass of RBAC rules when configured using the uritemplate permissions. This vulnerability is fixed in Envoy versions v1.34.1, v1.33.3, v1.32.6, v1.31.8. As a workaround, configure additional RBAC permissions using urlpath with saferegex expression.

Impact A user with access to a Kubernetes cluster where Envoy Gateway is installed can use a path traversal attack to execute Envoy Admin interface commands on proxies managed by Envoy Gateway. The admin interface can be used to terminate the Envoy process and extract the Envoy configuration (possibly containing confidential data).

For example, the following command, if run from within the Kubernetes cluster, can be used to get the configuration dump of the proxy: curl --path-as-is http://<Proxy-Service-ClusterIP>:19001/stats/prometheus/../../configdump Patches 1.2.6

Workarounds The EnvoyProxy API can be used to apply a bootstrap config patch that restricts access strictly to the prometheus stats endpoint. Find below an example of such a bootstrap patch.

apiVersion: gateway.envoyproxy.io/v1alpha1 kind: EnvoyProxy metadata: name: custom-proxy-config namespace: default spec: bootstrap: type: JSONPatch jsonPatches: - op: "add" path: "/staticresources/listeners/0/filterchains/0/filters/0/typedconfig/normalizepath" value: true - op: "replace" path: "/staticresources/listeners/0/filterchains/0/filters/0/typedconfig/routeconfig/virtualhosts/0/routes/0/match" value: path: "/stats/prometheus" headers: - name: ":method" exactmatch: GET

References - Envoy Admin Interface: https://www.envoyproxy.io/docs/envoy/latest/operations/admin - Envoy Configuration Best Practices: https://www.envoyproxy.io/docs/envoy/latest/configuration/bestpractices/edge

Envoy is a cloud-native high-performance edge/middle/service proxy. In affected versions sendOverloadError is going to assume the active request exists when envoy.loadshedpoints.http1serverabortdispatch is configured. If activerequest is nullptr, only onMessageBeginImpl() is called. However, the onMessageBeginImpl will directly return ok status if the stream is already reset leading to the nullptr reference. The downstream reset can actually happen during the H/2 upstream reset. As a result envoy may crash. This issue has been addressed in releases 1.32.3, 1.31.5, 1.30.9, and 1.29.12. Users are advised to upgrade. Users unable to upgrade may disable http1serverabortdispatch load shed point and/or use a high threshold.

Envoy is a cloud-native high-performance edge/middle/service proxy. In affected versions envoy does not properly handle http 1.1 non-101 1xx responses. This can lead to downstream failures in networked devices. This issue has been addressed in versions 1.31.5 and 1.32.3. Users are advised to upgrade. There are no known workarounds for this issue.

Envoy is a cloud-native high-performance edge/middle/service proxy. When additional address are not ip addresses, then the Happy Eyeballs sorting algorithm will crash in data plane. This issue has been addressed in releases 1.32.2, 1.31.4, and 1.30.8. Users are advised to upgrade. Users unable to upgrade may disable Happy Eyeballs and/or change the IP configuration.

End of life: 1/16/2025, Latest version: 1.29.12

End of life: 1/16/2025, Latest version: 1.29.12

Envoy is a cloud-native high-performance edge/middle/service proxy. Envoy will crash when the http async client is handling sendLocalReply under some circumstance, e.g., websocket upgrade, and requests mirroring. The http async client will crash during the sendLocalReply() in http async client, one reason is http async client is duplicating the status code, another one is the destroy of router is called at the destructor of the async stream, while the stream is deferred deleted at first. There will be problems that the stream decoder is destroyed but its reference is called in router.onDestroy(), causing segment fault. This will impact extauthz if the upgrade and connection header are allowed, and request mirrorring. This issue has been addressed in versions 1.31.2, 1.30.6, 1.29.9, and 1.28.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Envoy is a cloud-native high-performance edge/middle/service proxy. A vulnerability has been identified in Envoy that allows malicious attackers to inject unexpected content into access logs. This is achieved by exploiting the lack of validation for the REQUESTEDSERVERNAME field for access loggers. This issue has been addressed in versions 1.31.2, 1.30.6, 1.29.9, and 1.28.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Envoy is a cloud-native high-performance edge/middle/service proxy. A security vulnerability in Envoy allows external clients to manipulate Envoy headers, potentially leading to unauthorized access or other malicious actions within the mesh. This issue arises due to Envoy's default configuration of internal trust boundaries, which considers all RFC1918 private address ranges as internal. The default behavior for handling internal addresses in Envoy has been changed. Previously, RFC1918 IP addresses were automatically considered internal, even if the internaladdressconfig was empty. The default configuration of Envoy will continue to trust internal addresses while in this release and it will not trust them by default in next release. If you have tooling such as probes on your private network which need to be treated as trusted (e.g. changing arbitrary x-envoy headers) please explicitly include those addresses or CIDR ranges into internaladdressconfig. Successful exploitation could allow attackers to bypass security controls, access sensitive data, or disrupt services within the mesh, like Istio. This issue has been addressed in versions 1.31.2, 1.30.6, 1.29.9, and 1.28.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Envoy is a cloud-native high-performance edge/middle/service proxy. Envoy's 1.31 is using oghttp as the default HTTP/2 codec, and there are potential bugs around stream management in the codec. To resolve this Envoy will switch off the oghttp2 by default. The impact of this issue is that envoy will crash. This issue has been addressed in release version 1.31.2. All users are advised to upgrade. There are no known workarounds for this issue.

Envoy is a cloud-native high-performance edge/middle/service proxy. A vulnerability has been identified in Envoy that allows malicious attackers to inject unexpected content into access logs. This is achieved by exploiting the lack of validation for the REQUESTEDSERVERNAME field for access loggers. This issue has been addressed in versions 1.31.2, 1.30.6, 1.29.9, and 1.28.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.

Envoy is a cloud-native high-performance edge/middle/service proxy. Jwt filter will lead to an Envoy crash when clear route cache with remote JWKs. In the following case: 1. remote JWKs are used, which requires async header processing; 2. clearroutecache is enabled on the provider; 3. header operations are enabled in JWT filter, e.g. header to claims feature; 4. the routing table is configured in a way that the JWT header operations modify requests to not match any route. When these conditions are met, a crash is triggered in the upstream code due to nullptr reference conversion from route(). The root cause is the ordering of continueDecoding and clearRouteCache. This issue has been addressed in versions 1.31.2, 1.30.6, and 1.29.9. Users are advised to upgrade. There are no known workarounds for this vulnerability.

End of life: 10/19/2024, Latest version: 1.28.7

End of life: 10/19/2024, Latest version: 1.28.7

Inadequate Encryption Strength vulnerability allow an authenticated attacker to execute arbitrary OS Commands via encrypted package upload.This issue affects Envoy: 4.x and 5.x

A flaw was found in Envoy. It is possible to modify/manipulate headers from external clients when pass-through routes are used for the ingress gateway. A malicious user could use this flaw to forge what is logged by Envoy as a requested path, as well as cause the Envoy proxy to make requests to internal-only services or potentially arbitrary external systems.

Envoy is a cloud-native, open source edge and service proxy. Prior to versions 1.30.4, 1.29.7, 1.28.5, and 1.27.7. Envoy references already freed memory when route hash policy is configured with cookie attributes. Note that this vulnerability has been fixed in the open as the effect would be immediately apparent if it was configured. Memory allocated for holding attribute values is freed after configuration was parsed. During request processing Envoy will attempt to copy content of de-allocated memory into request cookie header. This can lead to arbitrary content of Envoy's memory to be sent to the upstream service or abnormal process termination. This vulnerability is fixed in Envoy versions v1.30.4, v1.29.7, v1.28.5, and v1.27.7. As a workaround, do not use cookie attributes in route action hash policy.

Envoy is a cloud-native, open source edge and service proxy. A crash was observed in EnvoyQuicServerStream::OnInitialHeadersComplete() with following call stack. It is a use-after-free caused by QUICHE continuing push request headers after StopReading() being called on the stream. As after StopReading(), the HCM's ActiveStream might have already be destroyed and any up calls from QUICHE could potentially cause use after free.

Envoy is a cloud-native, open source edge and service proxy. There is a crash at QuicheDataReader::PeekVarInt62Length(). It is caused by integer underflow in the QuicStreamSequencerBuffer::PeekRegion() implementation.

Envoy is a cloud-native, open source edge and service proxy. There is a use-after-free in HttpConnectionManager (HCM) with EnvoyQuicServerStream that can crash Envoy. An attacker can exploit this vulnerability by sending a request without FIN, then a RESETSTREAM frame, and then after receiving the response, closing the connection.

Envoy is a cloud-native, open source edge and service proxy. Due to how Envoy invoked the nlohmann JSON library, the library could throw an uncaught exception from downstream data if incomplete UTF-8 strings were serialized. The uncaught exception would cause Envoy to crash.

Envoy is a cloud-native, open source edge and service proxy. Envoy exposed an out-of-memory (OOM) vector from the mirror response, since async HTTP client will buffer the response with an unbounded buffer.

Envoy is a cloud-native, open source edge and service proxy. Envoyproxy with a Brotli filter can get into an endless loop during decompression of Brotli data with extra input.

Envoy is a cloud-native, open-source edge and service proxy. In versions 1.29.0 and 1.29.1, theEnvoy HTTP/2 protocol stack is vulnerable to the flood of CONTINUATION frames. Envoy's HTTP/2 codec does not reset a request when header map limits have been exceeded. This allows an attacker to send an sequence of CONTINUATION frames without the ENDHEADERS bit set causing unlimited memory consumption. This can lead to denial of service through memory exhaustion. Users should upgrade to versions 1.29.2 to mitigate the effects of the CONTINUATION flood. Note that this vulnerability is a regression in Envoy version 1.29.0 and 1.29.1 only. As a workaround, downgrade to version 1.28.1 or earlier or disable HTTP/2 protocol for downstream connections.

Envoy incorrectly accepts HTTP 200 response for entering upgrade mode

[I've seen multiple news articles & blogs in the wake of the coordinated disclosure today, but no postings here yet, so lets start fixing that.]

Google, Cloudflare, AWS, and others released details today of a protocol-level issue in HTTP/2 being exploited in recent months for denial-of-service attacks:

https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ https://aws.amazon.com/blogs/security/how-aws-protects-customers-from-ddos-events/

This attack works via the multiplexed streams feature of HTTP/2, in which the client repeatedly makes a request for a new stream, and then immediately sends a RSTSTREAM frame to cancel them, resulting in the server doing lots of extra work to set up and tear down the streams, while not hitting any server-side limit on a maximum number of active streams per connection.

CVE-2023-44487 was issued to track this issue across implementations: https://www.cve.org/CVERecord?id=CVE-2023-44487

A script to check for affected implemenations has been posted at: https://github.com/bcdannyboy/CVE-2023-44487

Information I've found so far on open source implementations (most via the current listings in the CVE) include:

- Apache httpd: https://chaos.social/@icing/111210915918780532

- caddy: https://github.com/caddyserver/caddy/issues/5877

- envoy: https://github.com/envoyproxy/envoy/pull/30055

- golang: https://github.com/golang/go/issues/63417 https://groups.google.com/g/golang-announce/c/iNNxDTCjZvo

- h2o: https://github.com/h2o/h2o/security/advisories/GHSA-2m7v-gc89-fjqf https://github.com/h2o/h2o/pull/3291

- haproxy: https://github.com/haproxy/haproxy/issues/2312

- hyper: https://seanmonstar.com/post/730794151136935936/hyper-http2-rapid-reset-unaffected

- jetty: https://github.com/eclipse/jetty.project/issues/10679 https://github.com/eclipse/jetty.project/releases/tag/jetty-12.0.2 https://github.com/eclipse/jetty.project/releases/tag/jetty-11.0.17 https://github.com/eclipse/jetty.project/releases/tag/jetty-10.0.17 https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.53.v20231009

- netty: https://github.com/netty/netty/commit/58f75f665aa81a8cbcf6ffa74820042a285c5e61

- nghttp2: https://github.com/nghttp2/nghttp2/pull/1961 https://github.com/nghttp2/nghttp2/releases/tag/v1.57.0

- nginx: https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/ https://mailman.nginx.org/pipermail/nginx-devel/2023-October/S36Q5HBXR7CAIMPLLPRSSSYR4PCMWILK.html

- nodejs: https://github.com/nodejs/node/pull/50121

- proxygen: https://github.com/facebook/proxygen/pull/466

- swift-nio-http2: https://forums.swift.org/t/swift-nio-http2-security-update-cve-2023-44487-http-2-dos/67764

- tomcat: https://tomcat.apache.org/security-11.html#FixedinApacheTomcat11.0.0-M12 https://tomcat.apache.org/security-10.html#FixedinApacheTomcat10.1.14 https://tomcat.apache.org/security-9.html#FixedinApacheTomcat9.0.81 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.94

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

Envoy is an open source edge and service proxy designed for cloud-native applications. Prior to versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12, the CORS filter will segfault and crash Envoy when the origin header is removed and deleted between decodeHeadersand encodeHeaders. Versions 1.27.0, 1.26.4, 1.25.9, 1.24.10, and 1.23.12 have a fix for this issue. As a workaround, do not remove the origin header in the Envoy configuration.

If origin header is configured to be removed with requestheaderstoremove: origin, CORS filter will segfault and crash Envoy when the origin header is removed and deleted between decodeHeaders and encodeHeaders.

Envoy allows mixed-case schemes in HTTP/2, however, some internal scheme checks in Envoy are case-sensitive, leading to incorrect handling of requests and responses with mixed case schemes. For example, if a request with mixed scheme http is sent to the OAuth2 filter, it will fail the exact-match checks for http, and inform the remote endpoint the scheme is https, thus potentially bypassing OAuth2 checks specific to HTTP requests.