CVSS: 5.3EPSS: 1%CPEs: 3EXPL: 0CVE-2023-40587 – Pyramid static view path traversal up one directory
https://notcve.org/view.php?id=CVE-2023-40587
25 Aug 2023 — Pyramid is an open source Python web framework. A path traversal vulnerability in Pyramid versions 2.0.0 and 2.0.1 impacts users of Python 3.11 that are using a Pyramid static view with a full filesystem path and have a `index.html` file that is located exactly one directory above the location of the static view's file system path. No further path traversal exists, and the only file that could be disclosed accidentally is `index.html`. Pyramid version 2.0.2 rejects any path that contains a null-byte out of ... • https://github.com/Pylons/pyramid/commit/347d7750da6f45c7436dd0c31468885cc9343c85 • CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal') •
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
31 May 2022 — 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 • 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
17 Mar 2022 — 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 advi... • https://github.com/Pylons/waitress/commit/9e0b8c801e4d505c2ffc91b891af4ba48af715e0 • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •
CVSS: 6.8EPSS: 13%CPEs: 1EXPL: 1CVE-2020-5236 – Catastrophic backtracking in regex allows Denial of Service in Waitress
https://notcve.org/view.php?id=CVE-2020-5236
04 Feb 2020 — 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 ... • https://github.com/motikan2010/CVE-2020-5236 • 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
22 Jan 2020 — 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. Wai... • https://docs.pylonsproject.org/projects/waitress/en/latest/#security-fixes • 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
26 Dec 2019 — 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 inv... • https://access.redhat.com/errata/RHSA-2020:0720 • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •
CVSS: 7.5EPSS: 0%CPEs: 6EXPL: 1CVE-2019-16785 – HTTP Request Smuggling: LF vs CRLF handling in Waitress
https://notcve.org/view.php?id=CVE-2019-16785
20 Dec 2019 — 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 potent... • https://access.redhat.com/errata/RHSA-2020:0720 • 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
20 Dec 2019 — 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-... • https://access.redhat.com/errata/RHSA-2020:0720 • CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') •