CVSS: 8.8EPSS: 0%CPEs: 7EXPL: 0CVE-2020-6425 – chromium-browser: Insufficient policy enforcement in extensions
https://notcve.org/view.php?id=CVE-2020-6425
Insufficient policy enforcement in extensions in Google Chrome prior to 80.0.3987.149 allowed an attacker who convinced a user to install a malicious extension to bypass site isolation via a crafted Chrome Extension. Una aplicación de política insuficiente en extensions de Google Chrome versiones anteriores a 80.0.3987.149, permitió a un atacante que convenció a un usuario para instalar una extensión maliciosa omitir el aislamiento del sitio por medio de una Extensión de Chrome diseñada. • http://lists.opensuse.org/opensuse-security-announce/2020-03/msg00037.html https://chromereleases.googleblog.com/2020/03/stable-channel-update-for-desktop_18.html https://crbug.com/1031670 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2DDNOAGIX5D77TTHT6YPMVJ5WTXTCQEI https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/6IOHSO6BUKC6I66J5PZOMAGFVJ66ZS57 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/JWANFIR3 • CWE-20: Improper Input Validation •
CVSS: 8.2EPSS: 0%CPEs: 6EXPL: 0CVE-2019-16789 – HTTP Request Smuggling in Waitress: Invalid whitespace characters in headers
https://notcve.org/view.php?id=CVE-2019-16789
In Waitress through version 1.4.0, if a proxy server is used in front of waitress, an invalid request may be sent by an attacker that bypasses the front-end and is parsed differently by waitress leading to a potential for HTTP request smuggling. Specially crafted requests containing special whitespace characters in the Transfer-Encoding header would get parsed by Waitress as being a chunked request, but a front-end server would use the Content-Length instead as the Transfer-Encoding header is considered invalid due to containing invalid characters. If a front-end server does HTTP pipelining to a backend Waitress server this could lead to HTTP request splitting which may lead to potential cache poisoning or unexpected information disclosure. This issue is fixed in Waitress 1.4.1 through more strict HTTP field validation. En Waitress versiones hasta 1.4.0, si un servidor proxy es usado frente a waitress, un atacante puede enviar una petición no comprobada que omita el front-end y que waitress analiza de manera diferente conllevando a un posible trafico no autorizado de peticiones HTTP. • https://access.redhat.com/errata/RHSA-2020:0720 https://docs.pylonsproject.org/projects/waitress/en/latest/#security-fixes https://github.com/Pylons/waitress/commit/11d9e138125ad46e951027184b13242a3c1de017 https://github.com/github/advisory-review/pull/14604 https://lists.debian.org/debian-lts-announce/2022/05/msg00011.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GVDHR2DNKCNQ7YQXISJ45NT4IQDX3LJ7 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedorapr • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •
CVSS: 7.5EPSS: 2%CPEs: 6EXPL: 1CVE-2019-16785 – HTTP Request Smuggling: LF vs CRLF handling in Waitress
https://notcve.org/view.php?id=CVE-2019-16785
Waitress through version 1.3.1 implemented a "MAY" part of the RFC7230 which states: "Although the line terminator for the start-line and header fields is the sequence CRLF, a recipient MAY recognize a single LF as a line terminator and ignore any preceding CR." Unfortunately if a front-end server does not parse header fields with an LF the same way as it does those with a CRLF it can lead to the front-end and the back-end server parsing the same HTTP message in two different ways. This can lead to a potential for HTTP request smuggling/splitting whereby Waitress may see two requests while the front-end server only sees a single HTTP message. This issue is fixed in Waitress 1.4.0. Waitress versión hasta 1.3.1, implementó una parte "MAY" del RFC7230 que declara: "Aunque el terminador de línea para los campos de línea de inicio y encabezado es la secuencia CRLF, un receptor PUEDE reconocer un LF único como un terminador de línea e ignorar cualquier CR anterior". • https://access.redhat.com/errata/RHSA-2020:0720 https://docs.pylonsproject.org/projects/waitress/en/latest/#security-fixes https://github.com/Pylons/waitress/commit/8eba394ad75deaf9e5cd15b78a3d16b12e6b0eba https://github.com/Pylons/waitress/security/advisories/GHSA-pg36-wpm5-g57p https://lists.debian.org/debian-lts-announce/2022/05/msg00011.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GVDHR2DNKCNQ7YQXISJ45NT4IQDX3LJ7 https://lists.fedoraproject.org/archives/list/package • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •
CVSS: 7.5EPSS: 0%CPEs: 6EXPL: 0CVE-2019-16786 – HTTP Request Smuggling: Invalid Transfer-Encoding in Waitress
https://notcve.org/view.php?id=CVE-2019-16786
Waitress through version 1.3.1 would parse the Transfer-Encoding header and only look for a single string value, if that value was not chunked it would fall through and use the Content-Length header instead. According to the HTTP standard Transfer-Encoding should be a comma separated list, with the inner-most encoding first, followed by any further transfer codings, ending with chunked. Requests sent with: "Transfer-Encoding: gzip, chunked" would incorrectly get ignored, and the request would use a Content-Length header instead to determine the body size of the HTTP message. This could allow for Waitress to treat a single request as multiple requests in the case of HTTP pipelining. This issue is fixed in Waitress 1.4.0. • https://access.redhat.com/errata/RHSA-2020:0720 https://docs.pylonsproject.org/projects/waitress/en/latest/#security-fixes https://github.com/Pylons/waitress/commit/f11093a6b3240fc26830b6111e826128af7771c3 https://github.com/Pylons/waitress/security/advisories/GHSA-g2xc-35jw-c63p https://lists.debian.org/debian-lts-announce/2022/05/msg00011.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/GVDHR2DNKCNQ7YQXISJ45NT4IQDX3LJ7 https://lists.fedoraproject.org/archives/list/package • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •
CVSS: 8.8EPSS: 0%CPEs: 11EXPL: 0CVE-2019-13730 – chromium-browser: Type Confusion in V8
https://notcve.org/view.php?id=CVE-2019-13730
Type confusion in JavaScript in Google Chrome prior to 79.0.3945.79 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. Una confusión de tipo en JavaScript en Google Chrome versiones anteriores a la versión 79.0.3945.79, permitió a un atacante remoto explotar potencialmente una corrupción de la pila por medio de una página HTML especialmente diseñada. • http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00032.html http://lists.opensuse.org/opensuse-security-announce/2019-12/msg00036.html https://access.redhat.com/errata/RHSA-2019:4238 https://chromereleases.googleblog.com/2019/12/stable-channel-update-for-desktop.html https://crbug.com/1028862 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/2Z5M4FPUMDNX2LDPHJKN5ZV5GIS2AKNU https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/m • CWE-787: Out-of-bounds Write CWE-843: Access of Resource Using Incompatible Type ('Type Confusion') •