Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 717966 (CVE-2019-16785, CVE-2019-16786, CVE-2019-16789, CVE-2020-5236) - <dev-python/waitress-1.4.3: Multiple vulnerabilities (CVE-2019-{16785,16786,16789}, CVE-2020-5236)
Summary: <dev-python/waitress-1.4.3: Multiple vulnerabilities (CVE-2019-{16785,16786,1...
Alias: CVE-2019-16785, CVE-2019-16786, CVE-2019-16789, CVE-2020-5236
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: Normal minor (vote)
Assignee: Gentoo Security
Whiteboard: B3 [noglsa cve]
Depends on:
Reported: 2020-04-17 23:58 UTC by GLSAMaker/CVETool Bot
Modified: 2020-06-20 01:35 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---
nattka: sanity-check+


Note You need to log in before you can comment on or make changes to this bug.
Description GLSAMaker/CVETool Bot gentoo-dev 2020-04-17 23:58:12 UTC
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.
Comment 1 GLSAMaker/CVETool Bot gentoo-dev 2020-04-17 23:59:40 UTC
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.
Comment 2 GLSAMaker/CVETool Bot gentoo-dev 2020-04-18 00:00:32 UTC
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.
Comment 3 GLSAMaker/CVETool Bot gentoo-dev 2020-04-18 00:03:05 UTC
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.
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-06-13 17:02:51 UTC
@maintainer(s), ready for stabilisation?
Comment 5 Agostino Sarubbo gentoo-dev 2020-06-15 15:04:31 UTC
arm stable
Comment 6 Agostino Sarubbo gentoo-dev 2020-06-15 15:06:57 UTC
ppc stable
Comment 7 Agostino Sarubbo gentoo-dev 2020-06-15 15:09:02 UTC
ppc64 stable
Comment 8 Agostino Sarubbo gentoo-dev 2020-06-15 15:10:19 UTC
s390 stable
Comment 9 Agostino Sarubbo gentoo-dev 2020-06-15 15:12:44 UTC
sparc stable
Comment 10 Agostino Sarubbo gentoo-dev 2020-06-17 07:08:08 UTC
amd64 stable
Comment 11 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2020-06-17 14:24:26 UTC
* arm64 stable
* ALLARCHES => x86, hppa stable

@maintainer(s), please cleanup
Comment 12 Larry the Git Cow gentoo-dev 2020-06-20 01:35:34 UTC
The bug has been referenced in the following commit(s):

commit 96c5ad38d3d1e1c0e054d2924aad09d4fed212bd
Author:     Aaron Bauman <>
AuthorDate: 2020-06-20 01:34:54 +0000
Commit:     Aaron Bauman <>
CommitDate: 2020-06-20 01:34:54 +0000

    dev-python/waitress: drop vulnerable
    Signed-off-by: Aaron Bauman <>

 dev-python/waitress/Manifest              |  1 -
 dev-python/waitress/waitress-1.3.1.ebuild | 21 ---------------------
 2 files changed, 22 deletions(-)