CVSS: 5.3EPSS: 0%CPEs: 16EXPL: 0CVE-2019-11046 – Buffer underflow in bc_shift_addsub
https://notcve.org/view.php?id=CVE-2019-11046
In PHP versions 7.2.x below 7.2.26, 7.3.x below 7.3.13 and 7.4.0, PHP bcmath extension functions on some systems, including Windows, can be tricked into reading beyond the allocated space by supplying it with string containing characters that are identified as numeric by the OS but aren't ASCII numbers. This can read to disclosure of the content of some memory locations. En PHP versiones 7.2.x por debajo de 7.2.26, versiones 7.3.x por debajo de 7.3.13 y 7.4.0, las funciones de extensión bcmath de PHP en algunos sistemas, incluyendo Windows, pueden ser engañadas para que lean más allá del espacio asignado al suministrarle cadenas que contengan caracteres que el sistema operativo identifica como numéricos pero no son números ASCII. Esto puede ser leído para revelar el contenido de algunas ubicaciones de memoria. • http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00036.html https://bugs.php.net/bug.php?id=78878 https://lists.debian.org/debian-lts-announce/2019/12/msg00034.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/N7GCOAE6KVHYJ3UQ4KLPLTGSLX6IRVRN https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XWRQPYXVG43Q7DXMXH6UVWMKWGUW552F https://seclists.org/bugtraq/2020/Feb/27 https://seclists.org/bugtraq/2020/Feb/31 ht • CWE-125: Out-of-bounds Read •
CVSS: 5.9EPSS: 0%CPEs: 16EXPL: 1CVE-2019-11045 – DirectoryIterator class silently truncates after a null byte
https://notcve.org/view.php?id=CVE-2019-11045
In PHP versions 7.2.x below 7.2.26, 7.3.x below 7.3.13 and 7.4.0, PHP DirectoryIterator class accepts filenames with embedded \0 byte and treats them as terminating at that byte. This could lead to security vulnerabilities, e.g. in applications checking paths that the code is allowed to access. En PHP versiones 7.2.x por debajo de 7.2.26, versiones 7.3.x por debajo de 7.3.13 y 7.4.0, la clase DirectoryIterator de PHP acepta nombres de archivo con \0 byte insertado y los trata como terminando en ese byte. Esto podría conllevar a vulnerabilidades de seguridad, por ejemplo en aplicaciones que comprueban las rutas a las que se permite acceder al código. • http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00036.html https://bugs.php.net/bug.php?id=78863 https://lists.debian.org/debian-lts-announce/2019/12/msg00034.html https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/N7GCOAE6KVHYJ3UQ4KLPLTGSLX6IRVRN https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XWRQPYXVG43Q7DXMXH6UVWMKWGUW552F https://seclists.org/bugtraq/2020/Feb/27 https://seclists.org/bugtraq/2020/Feb/31 ht • CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection') CWE-170: Improper Null Termination •
CVSS: 7.5EPSS: 0%CPEs: 6EXPL: 1CVE-2019-11044 – link() silently truncates after a null byte on Windows
https://notcve.org/view.php?id=CVE-2019-11044
In PHP versions 7.2.x below 7.2.26, 7.3.x below 7.3.13 and 7.4.0 on Windows, PHP link() function accepts filenames with embedded \0 byte and treats them as terminating at that byte. This could lead to security vulnerabilities, e.g. in applications checking paths that the code is allowed to access. En PHP versiones 7.2.x por debajo de 7.2.26, versiones 7.3.x por debajo de 7.3.13 y 7.4.0 en Windows, la función PHP link() acepta nombres de archivo con /0 byte insertado y los trata como terminando en ese byte. Esto podría conllevar a vulnerabilidades de seguridad, por ejemplo en aplicaciones que comprueban las rutas a las que se permite acceder al código. • https://bugs.php.net/bug.php?id=78862 https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/N7GCOAE6KVHYJ3UQ4KLPLTGSLX6IRVRN https://lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/XWRQPYXVG43Q7DXMXH6UVWMKWGUW552F https://security.netapp.com/advisory/ntap-20200103-0002 https://www.tenable.com/security/tns-2021-14 • CWE-170: Improper Null Termination •
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') •