CVSS: 6.5EPSS: 0%CPEs: 1EXPL: 1CVE-2022-31015 – Uncaught Exception (due to a data race) leads to process termination in Waitress
https://notcve.org/view.php?id=CVE-2022-31015
Waitress is a Web Server Gateway Interface server for Python 2 and 3. Waitress versions 2.1.0 and 2.1.1 may terminate early due to a thread closing a socket while the main thread is about to call select(). This will lead to the main thread raising an exception that is not handled and then causing the entire application to be killed. This issue has been fixed in Waitress 2.1.2 by no longer allowing the WSGI thread to close the socket. Instead, that is always delegated to the main thread. • https://github.com/Pylons/waitress/commit/4f6789b035610e0552738cdc4b35ca809a592d48 https://github.com/Pylons/waitress/issues/374 https://github.com/Pylons/waitress/pull/377 https://github.com/Pylons/waitress/security/advisories/GHSA-f5x9-8jwc-25rw • CWE-248: Uncaught Exception CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 7.5EPSS: 0%CPEs: 2EXPL: 0CVE-2022-24761 – HTTP Request Smuggling in waitress
https://notcve.org/view.php?id=CVE-2022-24761
Waitress is a Web Server Gateway Interface server for Python 2 and 3. When using Waitress versions 2.1.0 and prior behind a proxy that does not properly validate the incoming HTTP request matches the RFC7230 standard, Waitress and the frontend proxy may disagree on where one request starts and where it ends. This would allow requests to be smuggled via the front-end proxy to waitress and later behavior. There are two classes of vulnerability that may lead to request smuggling that are addressed by this advisory: The use of Python's `int()` to parse strings into integers, leading to `+10` to be parsed as `10`, or `0x01` to be parsed as `1`, where as the standard specifies that the string should contain only digits or hex digits; and Waitress does not support chunk extensions, however it was discarding them without validating that they did not contain illegal characters. This vulnerability has been patched in Waitress 2.1.1. • https://github.com/Pylons/waitress/commit/9e0b8c801e4d505c2ffc91b891af4ba48af715e0 https://github.com/Pylons/waitress/releases/tag/v2.1.1 https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36 https://lists.debian.org/debian-lts-announce/2022/05/msg00011.html https://www.debian.org/security/2022/dsa-5138 https://access.redhat.com/security/cve/CVE-2022-24761 https://bugzilla.redhat.com/show_bug.cgi?id=2065086 • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •
CVSS: 6.8EPSS: 0%CPEs: 1EXPL: 1CVE-2020-5236 – Catastrophic backtracking in regex allows Denial of Service in Waitress
https://notcve.org/view.php?id=CVE-2020-5236
Waitress version 1.4.2 allows a DOS attack When waitress receives a header that contains invalid characters. When a header like "Bad-header: xxxxxxxxxxxxxxx\x10" is received, it will cause the regular expression engine to catastrophically backtrack causing the process to use 100% CPU time and blocking any other interactions. This allows an attacker to send a single request with an invalid header and take the service offline. This issue was introduced in version 1.4.2 when the regular expression was updated to attempt to match the behaviour required by errata associated with RFC7230. The regular expression that is used to validate incoming headers has been updated in version 1.4.3, it is recommended that people upgrade to the new version of Waitress as soon as possible. • https://github.com/motikan2010/CVE-2020-5236 https://github.com/Pylons/waitress/commit/6e46f9e3f014d64dd7d1e258eaf626e39870ee1f https://github.com/Pylons/waitress/security/advisories/GHSA-73m2-3pwg-5fgc • CWE-400: Uncontrolled Resource Consumption •
CVSS: 7.5EPSS: 0%CPEs: 3EXPL: 0CVE-2019-16792 – HTTP Request Smuggling: Content-Length Sent Twice in Waitress
https://notcve.org/view.php?id=CVE-2019-16792
Waitress through version 1.3.1 allows request smuggling by sending the Content-Length header twice. Waitress would header fold a double Content-Length header and due to being unable to cast the now comma separated value to an integer would set the Content-Length to 0 internally. If two Content-Length headers are sent in a single request, Waitress would treat the request as having no body, thereby treating the body of the request as a new request in HTTP pipelining. This issue is fixed in Waitress 1.4.0. Waitress hasta la versión 1.3.1, permite el tráfico no autorizado de peticiones mediante el envío del encabezado Content-Length dos veces. • https://docs.pylonsproject.org/projects/waitress/en/latest/#security-fixes https://github.com/Pylons/waitress/commit/575994cd42e83fd772a5f7ec98b2c56751bd3f65 https://github.com/Pylons/waitress/security/advisories/GHSA-4ppp-gpcr-7qf6 https://lists.debian.org/debian-lts-announce/2022/05/msg00011.html https://www.oracle.com/security-alerts/cpuapr2022.html • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •
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') •