Filtered by vendor Envoyproxy
Subscribe
Total
69 CVE
| CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
|---|---|---|---|---|---|
| CVE-2021-29258 | 1 Envoyproxy | 1 Envoy | 2021-05-27 | 5.0 MEDIUM | 7.5 HIGH |
| An issue was discovered in Envoy 1.14.0. There is a remotely exploitable crash for HTTP2 Metadata, because an empty METADATA map triggers a Reachable Assertion. | |||||
| CVE-2020-35470 | 1 Envoyproxy | 1 Envoy | 2020-12-16 | 5.8 MEDIUM | 8.8 HIGH |
| Envoy before 1.16.1 logs an incorrect downstream address because it considers only the directly connected peer, not the information in the proxy protocol header. This affects situations with tcp-proxy as the network filter (not HTTP filters). | |||||
| CVE-2020-35471 | 1 Envoyproxy | 1 Envoy | 2020-12-16 | 5.0 MEDIUM | 7.5 HIGH |
| Envoy before 1.16.1 mishandles dropped and truncated datagrams, as demonstrated by a segmentation fault for a UDP packet size larger than 1500. | |||||
| CVE-2019-15225 | 1 Envoyproxy | 1 Envoy | 2020-08-24 | 5.0 MEDIUM | 7.5 HIGH |
| In Envoy through 1.11.1, users may configure a route to match incoming path headers via the libstdc++ regular expression implementation. A remote attacker may send a request with a very long URI to result in a denial of service (memory consumption). This is a related issue to CVE-2019-14993. | |||||
| CVE-2020-15104 | 1 Envoyproxy | 1 Envoy | 2020-07-21 | 5.5 MEDIUM | 5.4 MEDIUM |
| In Envoy before versions 1.12.6, 1.13.4, 1.14.4, and 1.15.0 when validating TLS certificates, Envoy would incorrectly allow a wildcard DNS Subject Alternative Name apply to multiple subdomains. For example, with a SAN of *.example.com, Envoy would incorrectly allow nested.subdomain.example.com, when it should only allow subdomain.example.com. This defect applies to both validating a client TLS certificate in mTLS, and validating a server TLS certificate for upstream connections. This vulnerability is only applicable to situations where an untrusted entity can obtain a signed wildcard TLS certificate for a domain of which you only intend to trust a subdomain of. For example, if you intend to trust api.mysubdomain.example.com, and an untrusted actor can obtain a signed TLS certificate for *.example.com or *.com. Configurations are vulnerable if they use verify_subject_alt_name in any Envoy version, or if they use match_subject_alt_names in version 1.14 or later. This issue has been fixed in Envoy versions 1.12.6, 1.13.4, 1.14.4, 1.15.0. | |||||
| CVE-2020-8660 | 1 Envoyproxy | 1 Envoy | 2020-07-13 | 5.0 MEDIUM | 5.3 MEDIUM |
| CNCF Envoy through 1.13.0 TLS inspector bypass. TLS inspector could have been bypassed (not recognized as a TLS client) by a client using only TLS 1.3. Because TLS extensions (SNI, ALPN) were not inspected, those connections might have been matched to a wrong filter chain, possibly bypassing some security restrictions in the process. | |||||
| CVE-2020-12603 | 1 Envoyproxy | 1 Envoy | 2020-07-09 | 5.0 MEDIUM | 7.5 HIGH |
| Envoy version 1.14.2, 1.13.2, 1.12.4 or earlier may consume excessive amounts of memory when proxying HTTP/2 requests or responses with many small (i.e. 1 byte) data frames. | |||||
| CVE-2020-8663 | 1 Envoyproxy | 1 Envoy | 2020-07-08 | 5.0 MEDIUM | 7.5 HIGH |
| Envoy version 1.14.2, 1.13.2, 1.12.4 or earlier may exhaust file descriptors and/or memory when accepting too many connections. | |||||
| CVE-2019-15226 | 1 Envoyproxy | 1 Envoy | 2019-10-17 | 7.8 HIGH | 7.5 HIGH |
| Upon receiving each incoming request header data, Envoy will iterate over existing request headers to verify that the total size of the headers stays below a maximum limit. The implementation in versions 1.10.0 through 1.11.1 for HTTP/1.x traffic and all versions of Envoy for HTTP/2 traffic had O(n^2) performance characteristics. A remote attacker may craft a request that stays below the maximum request header size but consists of many thousands of small headers to consume CPU and result in a denial-of-service attack. | |||||