Page 3 of 15 results (0.008 seconds)

CVSS: 3.1EPSS: 0%CPEs: 2EXPL: 1

Istio through 1.5.1 and Envoy through 1.14.1 have a data-leak issue. If there is a TCP connection (negotiated with SNI over HTTPS) to *.example.com, a request for a domain concurrently configured explicitly (e.g., abc.example.com) is sent to the server(s) listening behind *.example.com. The outcome should instead be 421 Misdirected Request. Imagine a shared caching forward proxy re-using an HTTP/2 connection for a large subnet with many users. If a victim is interacting with abc.example.com, and a server (for abc.example.com) recycles the TCP connection to the forward proxy, the victim's browser may suddenly start sending sensitive data to a *.example.com server. • https://bugs.chromium.org/p/chromium/issues/detail?id=954160#c5 https://github.com/envoyproxy/envoy/issues/6767 https://github.com/istio/istio/issues/13589 https://github.com/istio/istio/issues/9429 •

CVSS: 7.4EPSS: 0%CPEs: 1EXPL: 0

An issue was discovered in Istio 1.3 through 1.3.6. Under certain circumstances, it is possible to bypass a specifically configured Mixer policy. Istio-proxy accepts the x-istio-attributes header at ingress that can be used to affect policy decisions when Mixer policy selectively applies to a source equal to ingress. To exploit this vulnerability, someone has to encode a source.uid in this header. This feature is disabled by default in Istio 1.3 and 1.4. • https://github.com/istio/istio/commits/master https://istio.io/news/security https://istio.io/news/security/istio-security-2020-002 • CWE-20: Improper Input Validation •

CVSS: 7.5EPSS: 0%CPEs: 4EXPL: 0

Istio versions 1.2.10 (End of Life) and prior, 1.3 through 1.3.7, and 1.4 through 1.4.3 allows authentication bypass. The Authentication Policy exact-path matching logic can allow unauthorized access to HTTP paths even if they are configured to be only accessed after presenting a valid JWT token. For example, an attacker can add a ? or # character to a URI that would otherwise satisfy an exact-path match. Las versiones Istio 1.2.10 (End of Life) y anteriores, 1.3 a 1.3.7, y 1.4 a 1.4.3 permiten la omisión de autenticación. • https://access.redhat.com/errata/RHSA-2020:0477 https://access.redhat.com/security/cve/cve-2020-8595 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2020-8595 https://github.com/istio/istio/commits/master https://istio.io/news/security https://istio.io/news/security/istio-security-2020-001 https://access.redhat.com/security/cve/CVE-2020-8595 https://bugzilla.redhat.com/show_bug.cgi?id=1798247 • CWE-285: Improper Authorization CWE-287: Improper Authentication •

CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 1

Istio 1.3.x before 1.3.5 allows Denial of Service because continue_on_listener_filters_timeout is set to True, a related issue to CVE-2019-18836. Istio versiones 1.3.x anteriores a 1.3.5, permite una Denegación de Servicio porque continue_on_listener_filters_timeout está establecido en True, un problema relacionado con CVE-2019-18836. • https://github.com/istio/istio/issues/18229 https://istio.io/news/2019/announcing-1.3.5 • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •

CVSS: 7.5EPSS: 1%CPEs: 2EXPL: 2

Envoy 1.12.0 allows a remote denial of service because of resource loops, as demonstrated by a single idle TCP connection being able to keep a worker thread in an infinite busy loop when continue_on_listener_filters_timeout is used." Envoy versión 1.12.0 permite una denegación de servicio remota debido a bucles de recursos, como es demostrado por una conexión TCP inactiva que es capaz de mantener un subproceso o hilo de trabajo en un bucle ocupado infinito cuando la función continue_on_listener_filters_timeout es usada. • https://blog.envoyproxy.io https://github.com/envoyproxy/envoy/security/advisories/GHSA-3xvf-4396-cj46 https://github.com/istio/istio/issues/18229 https://groups.google.com/forum/#%21forum/envoy-users • CWE-835: Loop with Unreachable Exit Condition ('Infinite Loop') •