dev-mend-for-github-com[bot]
commented
1 year ago :heavy_check_mark: This issue was automatically closed by Mend because the vulnerable library in the specific branch(es) was either marked as ignored or it is no longer part of the Mend inventory.
Waitress WSGI server
Library home page: https://files.pythonhosted.org/packages/e7/b6/de07299bbe1b4f43760570b6e2f0468345203b3a037f780626bd1eade2ad/waitress-1.0.2-py2.py3-none-any.whl
Path to dependency file: /requirements.txt
Path to vulnerable library: /requirements.txt
Found in HEAD commit: ed3f8f8f280c7d91c5899c6b2b58bdeb52bfa1f9
Vulnerabilities
Details
CVE-2019-16789
### Vulnerable Library - waitress-1.0.2-py2.py3-none-any.whlWaitress WSGI server
Library home page: https://files.pythonhosted.org/packages/e7/b6/de07299bbe1b4f43760570b6e2f0468345203b3a037f780626bd1eade2ad/waitress-1.0.2-py2.py3-none-any.whl
Path to dependency file: /requirements.txt
Path to vulnerable library: /requirements.txt
Dependency Hierarchy: - :x: **waitress-1.0.2-py2.py3-none-any.whl** (Vulnerable Library)
Found in HEAD commit: ed3f8f8f280c7d91c5899c6b2b58bdeb52bfa1f9
Found in base branch: main
### Vulnerability DetailsIn 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.
Publish Date: 2019-12-26
URL: CVE-2019-16789
### CVSS 3 Score Details (8.2)Base Score Metrics: - Exploitability Metrics: - Attack Vector: Network - Attack Complexity: Low - Privileges Required: None - User Interaction: None - Scope: Unchanged - Impact Metrics: - Confidentiality Impact: Low - Integrity Impact: High - Availability Impact: None
For more information on CVSS3 Scores, click here. ### Suggested FixType: Upgrade version
Origin: https://github.com/advisories/GHSA-m5ff-3wj3-8ph4
Release Date: 2019-12-26
Fix Resolution: 1.4.1
:rescue_worker_helmet: Automatic Remediation is available for this issue
CVE-2019-16786
### Vulnerable Library - waitress-1.0.2-py2.py3-none-any.whlWaitress WSGI server
Library home page: https://files.pythonhosted.org/packages/e7/b6/de07299bbe1b4f43760570b6e2f0468345203b3a037f780626bd1eade2ad/waitress-1.0.2-py2.py3-none-any.whl
Path to dependency file: /requirements.txt
Path to vulnerable library: /requirements.txt
Dependency Hierarchy: - :x: **waitress-1.0.2-py2.py3-none-any.whl** (Vulnerable Library)
Found in HEAD commit: ed3f8f8f280c7d91c5899c6b2b58bdeb52bfa1f9
Found in base branch: main
### Vulnerability DetailsWaitress 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.
Publish Date: 2019-12-20
URL: CVE-2019-16786
### CVSS 3 Score Details (7.5)Base Score Metrics: - Exploitability Metrics: - Attack Vector: Network - Attack Complexity: Low - Privileges Required: None - User Interaction: None - Scope: Unchanged - Impact Metrics: - Confidentiality Impact: None - Integrity Impact: High - Availability Impact: None
For more information on CVSS3 Scores, click here. ### Suggested FixType: Upgrade version
Origin: https://github.com/Pylons/waitress/security/advisories/GHSA-g2xc-35jw-c63p
Release Date: 2019-12-20
Fix Resolution: 1.4.0
:rescue_worker_helmet: Automatic Remediation is available for this issue
CVE-2019-16785
### Vulnerable Library - waitress-1.0.2-py2.py3-none-any.whlWaitress WSGI server
Library home page: https://files.pythonhosted.org/packages/e7/b6/de07299bbe1b4f43760570b6e2f0468345203b3a037f780626bd1eade2ad/waitress-1.0.2-py2.py3-none-any.whl
Path to dependency file: /requirements.txt
Path to vulnerable library: /requirements.txt
Dependency Hierarchy: - :x: **waitress-1.0.2-py2.py3-none-any.whl** (Vulnerable Library)
Found in HEAD commit: ed3f8f8f280c7d91c5899c6b2b58bdeb52bfa1f9
Found in base branch: main
### Vulnerability DetailsWaitress 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.
Publish Date: 2019-12-20
URL: CVE-2019-16785
### CVSS 3 Score Details (7.5)Base Score Metrics: - Exploitability Metrics: - Attack Vector: Network - Attack Complexity: Low - Privileges Required: None - User Interaction: None - Scope: Unchanged - Impact Metrics: - Confidentiality Impact: None - Integrity Impact: High - Availability Impact: None
For more information on CVSS3 Scores, click here. ### Suggested FixType: Upgrade version
Origin: https://github.com/Pylons/waitress/security/advisories/GHSA-pg36-wpm5-g57p
Release Date: 2019-12-20
Fix Resolution: 1.4.0
:rescue_worker_helmet: Automatic Remediation is available for this issue
CVE-2019-16792
### Vulnerable Library - waitress-1.0.2-py2.py3-none-any.whlWaitress WSGI server
Library home page: https://files.pythonhosted.org/packages/e7/b6/de07299bbe1b4f43760570b6e2f0468345203b3a037f780626bd1eade2ad/waitress-1.0.2-py2.py3-none-any.whl
Path to dependency file: /requirements.txt
Path to vulnerable library: /requirements.txt
Dependency Hierarchy: - :x: **waitress-1.0.2-py2.py3-none-any.whl** (Vulnerable Library)
Found in HEAD commit: ed3f8f8f280c7d91c5899c6b2b58bdeb52bfa1f9
Found in base branch: main
### Vulnerability DetailsWaitress 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.
Publish Date: 2020-01-22
URL: CVE-2019-16792
### CVSS 3 Score Details (7.5)Base Score Metrics: - Exploitability Metrics: - Attack Vector: Network - Attack Complexity: Low - Privileges Required: None - User Interaction: None - Scope: Unchanged - Impact Metrics: - Confidentiality Impact: None - Integrity Impact: High - Availability Impact: None
For more information on CVSS3 Scores, click here. ### Suggested FixType: Upgrade version
Origin: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16792
Release Date: 2020-01-22
Fix Resolution: 1.4.0
:rescue_worker_helmet: Automatic Remediation is available for this issue:rescue_worker_helmet: Automatic Remediation is available for this issue.