pysec-2019-137
Vulnerability from pysec
Published
2019-12-20 23:15
Modified
2020-02-25 17:15
Details

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.




{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "waitress",
        "purl": "pkg:pypi/waitress"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "f11093a6b3240fc26830b6111e826128af7771c3"
            }
          ],
          "repo": "https://github.com/Pylons/waitress",
          "type": "GIT"
        },
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "0.1",
        "0.2",
        "0.3",
        "0.4",
        "0.5",
        "0.6",
        "0.6.1",
        "0.7",
        "0.8",
        "0.8.1",
        "0.8.2",
        "0.8.3",
        "0.8.4",
        "0.8.5",
        "0.8.6",
        "0.8.7",
        "0.8.8",
        "0.8.9",
        "0.8.10",
        "0.8.11b0",
        "0.9.0b0",
        "0.9.0b1",
        "0.9.0",
        "1.0a1",
        "1.0a2",
        "1.0.0",
        "1.0.1",
        "1.0.2",
        "1.1.0",
        "1.2.0b1",
        "1.2.0b2",
        "1.2.0b3",
        "1.2.0",
        "1.2.1",
        "1.3.0b0",
        "1.3.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2019-16786",
    "GHSA-g2xc-35jw-c63p"
  ],
  "details": "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.",
  "id": "PYSEC-2019-137",
  "modified": "2020-02-25T17:15:00Z",
  "published": "2019-12-20T23:15:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://github.com/Pylons/waitress/security/advisories/GHSA-g2xc-35jw-c63p"
    },
    {
      "type": "FIX",
      "url": "https://github.com/Pylons/waitress/commit/f11093a6b3240fc26830b6111e826128af7771c3"
    },
    {
      "type": "WEB",
      "url": "https://docs.pylonsproject.org/projects/waitress/en/latest/#security-fixes"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/GVDHR2DNKCNQ7YQXISJ45NT4IQDX3LJ7/"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/LYEOTGWJZVKPRXX2HBNVIYWCX73QYPM5/"
    },
    {
      "type": "ADVISORY",
      "url": "https://access.redhat.com/errata/RHSA-2020:0720"
    }
  ]
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading...

Loading...

Loading...

Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.