### [CVE-2019-16786](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-16786)
![](https://img.shields.io/static/v1?label=Product&message=Waitress&color=blue)
![](https://img.shields.io/static/v1?label=Version&message=%3C%3D%201.3.1%3C%3D%201.3.1%20&color=brighgreen)
![](https://img.shields.io/static/v1?label=Vulnerability&message=CWE-444%20Inconsistent%20Interpretation%20of%20HTTP%20Requests%20('HTTP%20Request%20Smuggling')&color=brighgreen)

### Description

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.

### POC

#### Reference
- https://www.oracle.com/security-alerts/cpuapr2022.html

#### Github
- https://github.com/Live-Hack-CVE/CVE-2019-16786