Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact A remote client may send a request that is exactly recvbytes (defaults to 8192) long, followed by a secondary request using HTTP pipelining. When request lookahead is disabled (default) we won't read any more requests, and when the first request fails due to a parsing error, we simply close the connection. However when request lookahead is enabled, it is possible to process and receive the first request, start sending the error message back to the client while we read the next request and queue it. This will allow the secondary request to be serviced by the worker thread while the connection should be closed. Patches Waitress 3.0.1 fixes the race condition. Workarounds Disable channelrequestlookahead, this is set to 0 by default disabling this feature. For this vulnerability this value is required to be changed from the default. For more information If you have any questions or comments about this advisory: Open an issue in https://github.com/Pylons/waitress/issues (if not…
Recommended action: Upgrade to 3.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When a remote client closes the connection before waitress has had the opportunity to call getpeername() waitress won't correctly clean up the connection leading to the main thread attempting to write to a socket that no longer exists, but not removing it from the list of sockets to attempt to process. This leads to a busy-loop calling the write function. A remote attacker could run waitress out of available sockets with very little resources required. Patches Waitress 3.0.1 contains fixes that remove the race condition. Workarounds No work-around. References - https://github.com/Pylons/waitress/issues/418 - https://github.com/Pylons/waitress/pull/435
Recommended action: Upgrade to 3.0.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Waitress 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. Patches This issue has been fixed in Waitress 2.1.2 by no longer allowing the WSGI thread to close the socket, instead it is always delegated to the main thread. Workarounds There is no work-around, however users using waitress behind a reverse proxy server are less likely to have issues if the reverse proxy always reads the full response. For more information If you have any questions or comments about this advisory: Open an issue in https://github.com/Pylons/waitress/issues (if not sensitive or security related) email the Pylons Security mailing list: pylons-project-security@googlegroups.com (if security related)
Recommended action: Upgrade to 2.1.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When using Waitress 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. - Waitress does not support chunk extensions, however it was discarding them without validating that they did not contain illegal characters Patches This has been fixed in Waitress 2.1.1 Workarounds When deploying a proxy in front of waitress, turning on any and all functionality to make sure that the request matches the RFC7230 standard. Certain proxy…
Recommended action: Upgrade to 2.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When waitress receives a header that contains invalid characters it will cause the regular expression engine to catastrophically backtrack causing the process to use 100% CPU time and blocking any other interactions. This would allow an attacker to send a single request with an invalid header and take the service offline. Invalid header example: Increasing the number of x's in the header will increase the amount of time Waitress spends in the regular expression engine. 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. Patches 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. Workarounds If you have deployed a reverse proxy in front of Waitress it may already be rejecting requests that include invalid headers. Thanks The Pylons…
Recommended action: Upgrade to 1.4.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The patches introduced to fix https://github.com/Pylons/waitress/security/advisories/GHSA-m5ff-3wj3-8ph4 were not complete and still would allow an attacker to smuggle requests/split a HTTP request with invalid data. This updates the existing CVE with ID: CVE-2019-16789 Patches Waitress version 1.4.2 has been updated to now validate HTTP headers better to avoid the issue, completely fixing all known issues with whitespace. Workarounds There are no work-arounds, upgrading to Waitress 1.4.2 is highly recommended. References See https://github.com/Pylons/waitress/security/advisories/GHSA-m5ff-3wj3-8ph4 for more information on the security issue. For more information If you have any questions or comments about this advisory: open an issue at https://github.com/Pylons/waitress/issues (if not sensitive or security related) email the Pylons Security mailing list: pylons-project-security@googlegroups.com (if security related)
Recommended action: Upgrade to 1.4.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. For clarity: 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. Patches Please upgrade to Waitress 1.4.1 which fixes this issue with stricter HTTP field validation. Waitress 1.4.1 due to this change has become much more strict in what is allowed in header values, while the maintainers don't believe that these changes will cause any issues, it may cause failures with non-conformist reverse proxies or clients, and it is…
Recommended action: Upgrade to 1.4.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. So a request with: ``` Content-Length: 10 Content-Length: 10 ``` would get transformed to: ``` Content-Length: 10, 10 ``` Which would Waitress would then internally set to `Content-Lenght: 0`. Waitress would then treat the request as having no body, thereby treating the body of the request as a new request in HTTP pipelining. Patches This issue is fixed in Waitress 1.4.0. This brings a range of changes to harden Waitress against potential HTTP request confusions, and may change the behaviour of Waitress behind non-conformist proxies. The Pylons Project recommends upgrading as soon as possible, while validating that the changes in Waitress don't cause any changes in behavior. Workarounds Various reverse proxies may have protections against sending potentially bad HTTP requests to the…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Waitress 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: 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. Patches This issue is fixed in Waitress 1.4.0. This brings a range of changes to harden Waitress against potential HTTP request confusions, and may change the behaviour of Waitress behind non-conformist proxies. Waitress will now return a 501 Not Implemented error if the Transfer-Encoding is not chunked or contains multiple elements. Waitress does not…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Waitress implemented a "MAY" part of the RFC7230 (https://tools.ietf.org/html/rfc7230#section-3.5) 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. Example: Would get treated by Waitress as if it were: This could potentially get used by attackers to split the HTTP request and smuggle a second request in the body of the first. Patches This issue is fixed in Waitress 1.4.0. This brings a range of changes to harden Waitress against potential…
Recommended action: Upgrade to 1.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.