This update for python-waitress to 1.4.3 fixes the following security issues :

  - CVE-2019-16785: HTTP request smuggling through LF vs     CRLF handling (bsc#1161088).

  - CVE-2019-16786: HTTP request smuggling through invalid     Transfer-Encoding (bsc#1161089).

  - CVE-2019-16789: HTTP request smuggling through invalid     whitespace characters (bsc#1160790).

  - CVE-2019-16792: HTTP request smuggling by sending the     Content-Length header twice (bsc#1161670).

This update was imported from the SUSE:SLE-15:Update update project.

According to the versions of the python-waitress package installed, the EulerOS Virtualization for ARM 64 installation on the remote host is affected by the following vulnerabilities :

  - 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.(CVE-2019-16786)

  - 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.(CVE-2019-16785)

  - 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.(CVE-2019-16789)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote Redhat Enterprise Linux 8 host has a package installed that is affected by multiple vulnerabilities as referenced in the RHSA-2020:0720 advisory.

    Waitress is a pure Python WSGI server which supports HTTP/1.0 and HTTP/1.1.

    Security Fix(es):

    * HTTP request smuggling through LF vs CRLF handling (CVE-2019-16785)

    * HTTP request smuggling through invalid Transfer-Encoding (CVE-2019-16786)

    * HTTP Request Smuggling through Invalid whitespace characters in headers     (CVE-2019-16789)

    For more details about the security issue(s), including the impact, a CVSS     score, acknowledgments, and other related information, refer to the CVE     page listed in the References section.

Tenable has extracted the preceding description block directly from the Red Hat Enterprise Linux security advisory.

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

python-waitressの1.4.3へのこの更新では、次のセキュリティ問題が修正されています：

  - CVE-2019-16785：LFとCRLFの処理によるHTTPリクエストスマグリング（bsc#1161088）。

  - CVE-2019-16786：無効なTransfer-EncodingによるHTTPリクエストスマグリング（bsc#1161089）。

  - CVE-2019-16789：無効な空白文字によるHTTPリクエストスマグリング（bsc#1160790）。

  - CVE-2019-16792：Content-Lengthヘッダーを2回送信することによるHTTPリクエストスマグリング（bsc#1161670）。

この更新はSUSEからインポートされました：SLE-15: 更新プロジェクトを更新します。

远程 Redhat Enterprise Linux 8 主机上安装的程序包受到 RHSA-2020: 0720 公告提及的漏洞的影响。

  - waitress：通过 LF 与 CRLF 处理的 HTTP 请求走私 (CVE-2019-16785)

  - waitress：通过无效的传输编码的 HTTP 请求走私 (CVE-2019-16786)

  - waitress：通过标头中的无效空白字符的 HTTP 请求走私 (CVE-2019-16789)

请注意，Nessus 尚未测试这些问题，而是只依据应用程序自我报告的版本号进行判断。

遠端 Debian 9 主機上安裝的多個套件受到 dla-3000 公告中提及的多個弱點影響。

  -Waitress 1.3.1 及之前版本實作了 RFC7230 的 MAY 部分，其中指出：雖然 start-line 和 header 欄位的行結束字元是序列 CRLF，但接收方可以將單一 LF 識別為行結束字元並忽略前面的任何 CR。遺憾的是，如果前端伺服器使用 LF 剖析 header 欄位的方式與使用 CRLF 剖析 header 欄位的方式不同，將會導致前端和後端伺服器以兩種不同的方式剖析相同的 HTTP 訊息。這可能導致 HTTP 要求走私/分割，進而導致 Waitress 看到兩個要求，而前端伺服器只能看到一則 HTTP 訊息。此問題已在 Waitress 1.4.0 中修正。(CVE-2019-16785)

  - Waitress 1.3.1 及之前版本會剖析 Transfer-Encoding 標頭，並且只尋找單一字串值，如果該值先前未進行區塊分割，則將找不到該值並改用 Content-Length 標頭。
    根據 HTTP 標準，Transfer-Encoding 應該是以逗號分隔的清單，最內層的編碼在前，接著是其他任何傳輸編碼，最後是區塊編碼。透過
    「Transfer-Encoding: gzip, chunked」傳送的要求會不正確地遭到忽略，且這個要求會改用 Content-Length 標頭來判斷 HTTP 訊息的內文大小。在使用 HTTP 管道的情況下，這可能允許 Waitress 將單一要求視為多個要求。此問題已在 Waitress 1.4.0 中修正。(CVE-2019-16786)

  - 在 Waitress 1.4.0 及之前版本中，如果在 Waitress 之前使用 Proxy 伺服器，攻擊者可能會繞過前端來傳送無效要求，並且 Waitress 將會以不同方式剖析該要求，進而可能導致走私要求問題。Waitress 會將傳輸編碼標頭中包含特殊空白字元的特別建構要求剖析成區塊要求，但由於傳輸編碼標頭含有無效字元，該標頭被視為無效，因此前端伺服器會使用內容長度標頭。如果前端伺服器對後端 Waitress 伺服器執行 HTTP 管道作業，則可能導致 HTTP 要求分割，進而可能造成快取毒害或非預期的資訊洩漏問題。此問題已透過執行更嚴格的 HTTP 欄位驗證，在 Waitress 1.4.1 及之前版本中進行修正。
    (CVE-2019-16789)

  - Waitress 1.3.1 及之前版本允許透過兩次傳送 Content-Length 標頭來實現要求走私。
    Waitress 會對雙重 Content-Length 標頭進行標頭折疊，而且由於無法將現在的逗號分隔值轉換為整數，因此會在內部將 Content-Length 設為 0。如果在單一要求中傳送兩個 Content-Length 標頭，Waitress 會將該要求視為沒有內文，進而將該要求的內文視為 HTTP 管道中的一個新要求。此問題已在 Waitress 1.4.0 中修正。
    (CVE-2019-16792)

  -Waitress 是適用於 Python 2 和 3 的 Web 伺服器閘道介面伺服器。在未正確驗證傳入 HTTP 要求符合 RFC7230 標準的代理伺服器後使用 2.1.0 版和更舊版本時，Waitress 和前端代理伺服器可能會就要求應在何處開始和結束發生分歧。這會允許透過前端代理伺服器將要求走私給服務生，然後再採取行動。有兩種類型的弱點可能導致本公告中已解決的要求走私弱點：使用 Python 的 `int()` 將字串剖析為整數，導致將 `+10` 剖析為 `10`，或將 `0x01` 剖析為 `1`，其中標準指定字串應僅包含數字或十六進位數字；
    Waitress 不支援區塊延伸模組，但它會在未驗證區塊延伸模組不包含非法字元的情況下予以捨棄。已在 Waitress 2.1.1 中修正此弱點。現也已提供因應措施。在 waitress 前面部署代理伺服器時，開啟所有功能以確保要求符合 RFC7230 標準。不過，某些 Proxy 伺服器可能不提供此功能，建議使用者升級至 waitress 最新版本。
    (CVE-2022-24761)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼。

遠端 Redhat Enterprise Linux 8 主機上安裝的套件受到 RHSA-2020: 0720 公告中提及的多個弱點影響。

  - waitress：透過 LF 與 CRLF 處理執行 HTTP 要求走私攻擊 (CVE-2019-16785)

  - waitress：透過無效的 Transfer-Encoding 執行 HTTP 要求走私攻擊 (CVE-2019-16786)

  - waitress：透過標頭中無效的空白字元執行 HTTP 要求走私攻擊 (CVE-2019-16789)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

リモートの Redhat Enterprise Linux 8 ホストにインストールされているパッケージは、RHSA-2020: 0720 のアドバイザリに記載されている複数の脆弱性の影響を受けます。

  - waitress: LF と CRLF の処理による HTTP リクエストスマグリング (CVE-2019-16785)

  - waitress: 無効な Transfer-Encoding による HTTP リクエストスマグリング (CVE-2019-16786)

  - waitress: ヘッダー内の無効な空白文字による HTTP リクエストスマグリング (CVE-2019-16789)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションの自己報告されたバージョン番号にのみ依存しています。

Update to 1.4.3, fixing CVE-2019-16786 CVE-2019-16785 CVE-2019-16789 and adding various other hardening features.

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora update system website.
Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

远程 Debian 9 主机上安装的多个程序包受到 dla-3000 公告中提及的多个漏洞影响。

  -Waitress 1.3.1 及之前版本实现了 RFC7230 的 MAY 部分，其中指出：尽管 start-line 和 header 字段的行结束符是序列 CRLF，但接收方可以将单个 LF 识别为行结束符并忽略任何前面的 CR。遗憾的是，如果前端服务器使用 LF 解析 header 字段的方式与使用 CRLF 解析 header 字段的方式不同，则可能导致前端和后端服务器以两种不同的方式解析相同的 HTTP 消息。这有可能导致 HTTP 请求走私/拆分问题，从而使 Waitress 看到两个请求，而前端服务器只能看到一则 HTTP 消息。此问题已在 Waitress 1.4.0 中解决。(CVE-2019-16785)

  - Waitress 1.3.1 及之前版本将解析 Transfer-Encoding 标头，并且仅查找单个字符串值，但如果该值之前未分块，则将无法找到该值并改为使用 Content-Length 标头。
    根据 HTTP 标准，Transfer-Encoding 应该是一个以逗号分隔的列表，最内层的编码在前，随后是进一步处理的传输编码，最后则是分块编码。通过“
    Transfer-Encoding: gzip, chunked”方式发送的请求会被错误地忽略，并且该请求会转而使用 Content-Length 标头来确定 HTTP 消息的正文大小。若是使用 HTTP 管道，这可能会允许 Waitress 将单个请求视为多个请求。此问题已在 Waitress 1.4.0 中解决。(CVE-2019-16786)

  - 在 Waitress 1.4.0 及之前版本中，如果在 Waitress 之前使用了代理服务器，则绕过前端的攻击者可以发送一个无效请求，而 Waitress 将以不同方式解析该请求，从而可能导致 HTTP 请求走私问题。Transfer-Encoding 标头中包含特殊空白字符的特别构建请求将被 waitress 解析为分块请求，但是前端服务器会使用 Content-Length，因为 Transfer-Encoding 标头因包含无效字符而被视为无效。如果前端服务器对后端 Waitress 服务器执行 HTTP 管道操作，这可能导致 HTTP 请求拆分，继而可能引起缓存中毒或非预期的信息泄露问题。此问题已在 Waitress 1.4.1 及之前版本中，通过更严格的 HTTP 字段验证进行修复。
    (CVE-2019-16789)

  - Waitress 1.3.1 及之前版本允许通过发送两次 Content-Length 标头造成请求走私。
    Waitress 会对双重 Content-Length 标头执行标头折叠操作，并且由于无法将现在的逗号分隔值转换为整数，因此系统会将 Content-Length 在内部设置为 0。如果在单个请求中发送两个 Content-Length 标头，Waitress 会将该请求视为无正文，从而在 HTTP 管道中将此请求的正文视为新请求。此问题已在 Waitress 1.4.0 中解决。
    (CVE-2019-16792)

  -Waitress 是用于 Python 2 和 3 的 Web 服务器网关接口服务器。当在未正确验证传入 HTTP 请求是否符合 RFC7230 标准的代理后面使用 Waitress 2.1.0 及更低版本时，Waitress 和前端代理可能会就请求的开始位置和结束位置产生分歧。这将允许通过前端代理将请求走私给 waitress，以及执行更多恶意操作。此公告已解决两类可导致请求走私的漏洞：使用 Python 的“int()”将字符串解析为整数，导致将“+10”解析为“10”或将“0x01”解析为“1”，其中标准指定字符串应仅包含数字或十六进制数字；
    Waitress 不支持区块扩展，但它在未验证区块扩展中不包含非法字符的情况下便将其丢弃。已在 Waitress 2.1.1 中修正此漏洞。现在也提供变通方案。在 waitress 前面部署代理时，开启所有功能以确保请求符合 RFC7230 标准。但某些代理服务器可能不提供此功能，因此建议用户升级到最新版 Waitress。
    (CVE-2022-24761)

请注意，Nessus 尚未测试这些问题，而是只依靠应用程序自我报告的版本号来判断。

1.4.3に更新してください。CVE-2019-16786 CVE-2019-16785 CVE-2019-16789を修正し、さまざまな他の強化機能を追加します

注意：Tenable Network Securityは、前述の記述ブロックをFedora更新システムのWebサイトから直接抽出しています。
Tenableでは、新たな問題を持ち込まずに、できる限り自動的に整理して書式設定するようにしています。

リモートの Debian 9 ホストには、dla-3000 のアドバイザリに記載された複数の脆弱性の影響を受けるパッケージがインストールされています。

  - バージョン 1.3.1までの Waitress は RFC7230の MAY 部分を実装し、次のように述べています: start-line およびヘッダーフィールドの行終端子は CRLF シーケンスですが、受信者の MAY は単一の LF を行終端子として認識し、先行する CR を無視します。残念ながら、フロントエンドサーバーが CRLF のヘッダーフィールドと同じ方法で LF のヘッダーフィールドを解析しない場合、フロントエンドサーバーとバックエンドサーバーが 2 つの異なる方法で同じ HTTP メッセージを解析する可能性があります。これにより、HTTP リクエストスマグリング/スプリットが発生する可能性があります。これにより、フロントエンドサーバーが単一の HTTP メッセージのみを表示しているにもかかわらず、Waitres が 2 つのリクエストを表示する可能性があります。この問題は Waitress 1.4.0で修正されています。(CVE-2019-16785)

  - バージョン 1.3.1までの Waitress は、Transfer-Encoding ヘッダーを解析し、単一の文字列値のみを検索します。その値がチャンクされていない場合、その文字列は通過し、代わりに Content-Length ヘッダーを使用します。
    HTTP の標準によると、Transfer-Encoding はコンマ区切りのリストであり、最も内側のエンコーディングが最初で、その後に転送コーディングが続き、チャンクで終了する必要があります。送信したリクエスト:
    Transfer-Encoding: gzip、chunked が誤って無視され、リクエストが HTTP メッセージの本文サイズを決定する代わりに Content-Length ヘッダーを使用します。: これにより、Waitress が HTTP パイプラインの場合に単一のリクエストを複数のリクエストとして処理する可能性があります。この問題は Waitress 1.4.0で修正されています。(CVE-2019-16786)

  バージョン 1.4.0までの Waitress では、waitress の前でプロキシサーバーが使用される場合、フロントエンドを回避して waitress によって異なる方法で解析される無効なリクエストが攻撃者によって送信されて、HTTP リクエストスマグリングが発生する可能性があります。Transfer-Encodingヘッダーに特別な空白文字を含むように特別に細工されたリクエストが、Waitressによってチャンクリクエストとして解析されるものの、無効な文字が含まれるTransfer-Encodingヘッダーが無効と見なされて、代わりにContent-Lengthがフロントエンドサーバーによって使用される可能性があります。フロントエンドサーバーがバックエンドの waitress サーバーに対する HTTP パイプライン処理を実行する場合、これが HTTP リクエストを分割することになり、キャッシュポイズニングまたは予期しない情報漏洩が発生する可能性があります。この問題は、より厳密な HTTP フィールドの検証により、Waitress 1.4.1で修正されました。
    (CVE-2019-16789)

  - バージョン 1.3.1までの Waitress では、Content-Length ヘッダーを2回送信することによる HTTP リクエストスマグリングが発生します。
    Waitress は、二重の Content-Length ヘッダーを折り返すため、コンマ区切りの値を整数にキャストできないため、Content-Length を内部で 0 に設定します。2 つの Content-Length ヘッダーが単一のリクエストで送信された場合、Waitres はリクエストに本文がないものとして処理し、リクエストの本文を HTTP パイプライン処理の新しいリクエストとして処理します。この問題は Waitress 1.4.0で修正されています。
    (CVE-2019-16792)

  - Waitress は、Python 2 および 3 用の Web Server Gateway Interface サーバーです。着信 HTTP リクエストが RFC7230標準と一致することを適切に検証しないプロキシの背後で Waitress バージョン 2.1.0以前を使用すると、Waitress およびフロントエンドプロキシは、リクエストの開始点と終了点について一致しない可能性があります。これにより、リクエストがフロントエンドプロキシを介してウェイトレスにスマグリングされ、その後の動作が可能になります。リクエストのスマグリングを引き起こす可能性がある 2 つのクラスの脆弱性があり、このアドバイザリで対処されています。文字列を整数に解析するための Python の「int()」の使用により、「+ 10」は「10」として解析され、「0x01」は「1」として解析されます。ここでは、標準として、文字列は数字または16進数のみでなければなりません。
    さらに、Waitress はチャンク拡張をサポートしていませんが、不正な文字が含まれていないことを検証せずにそれらを破棄していました。この脆弱性は Waitress 2.1.1でパッチが適用されています。回避策が利用可能です。waitress の前にプロキシを展開する場合、すべての機能をオンにして、リクエストが RFC7230標準に一致することを確認します。ただし、特定のプロキシサーバーにはこの機能がない場合があるため、代わりに最新バージョンの waitres にアップグレードすることが推奨されます。
    (CVE-2022-24761)

Nessus はこれらの問題をテストしておらず、代わりにアプリケーションの自己報告されたバージョン番号にのみ依存しています。

According to the versions of the python-waitress package installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - 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.(CVE-2019-16786)

  - 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.(CVE-2019-16785)

  - 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.(CVE-2019-16789)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote Debian 9 host has packages installed that are affected by multiple vulnerabilities as referenced in the dla-3000 advisory.

  - 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. (CVE-2019-16785)

  - 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. (CVE-2019-16786)

  - 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.
    (CVE-2019-16789)

  - Waitress 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.
    (CVE-2019-16792)

  - Waitress is a Web Server Gateway Interface server for Python 2 and 3. When using Waitress versions 2.1.0     and prior 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;
    and Waitress does not support chunk extensions, however it was discarding them without validating that     they did not contain illegal characters. This vulnerability has been patched in Waitress 2.1.1. A     workaround is available. 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 servers may not have this     functionality though and users are encouraged to upgrade to the latest version of waitress instead.
    (CVE-2022-24761)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	名稱	產品	系列	已發布	已更新	嚴重性
142917	openSUSE Security Update : python-waitress (openSUSE-2020-1922)	Nessus	SuSE Local Security Checks	2020/11/17	2024/2/8	high
140997	EulerOS Virtualization for ARM 64 3.0.6.0 : python-waitress (EulerOS-SA-2020-2049)	Nessus	Huawei Local Security Checks	2020/9/29	2024/2/16	high
170307	RHEL 8 : python-waitress (RHSA-2020:0720)	Nessus	Red Hat Local Security Checks	2023/1/23	2024/6/3	high
142917	openSUSEセキュリティ更新プログラム：python-waitress（openSUSE-2020-1922）	Nessus	SuSE Local Security Checks	2020/11/17	2024/2/8	high
170307	RHEL 8：python-waitres（RHSA-2020：0720)	Nessus	Red Hat Local Security Checks	2023/1/23	2024/6/3	high
161188	Debian DLA-3000-1：waitress - LTS 安全性更新	Nessus	Debian Local Security Checks	2022/5/13	2023/10/27	high
170307	RHEL 8：python-waitress (RHSA-2020: 0720)	Nessus	Red Hat Local Security Checks	2023/1/23	2024/6/3	high
170307	RHEL 8: python-waitress (RHSA-2020: 0720)	Nessus	Red Hat Local Security Checks	2023/1/23	2024/6/3	high
134057	Fedora 30 : python-waitress (2020-bdcc8ffc24)	Nessus	Fedora Local Security Checks	2020/2/26	2024/3/26	high
142944	openSUSE Security Update : python-waitress (openSUSE-2020-1911)	Nessus	SuSE Local Security Checks	2020/11/17	2024/2/8	high
161188	Debian DLA-3000-1：waitress - LTS 安全更新	Nessus	Debian Local Security Checks	2022/5/13	2023/10/27	high
134097	Fedora 31：python-waitress（2020-65a7744e38）	Nessus	Fedora Local Security Checks	2020/2/27	2024/3/25	high
161188	Debian DLA-3000-1：waitress - LTS セキュリティ更新	Nessus	Debian Local Security Checks	2022/5/13	2023/10/27	high
134057	Fedora 30：python-waitress（2020-bdcc8ffc24）	Nessus	Fedora Local Security Checks	2020/2/26	2024/3/26	high
142944	openSUSEセキュリティ更新プログラム：python-waitress（openSUSE-2020-1911）	Nessus	SuSE Local Security Checks	2020/11/17	2024/2/8	high
139982	EulerOS 2.0 SP8 : python-waitress (EulerOS-SA-2020-1879)	Nessus	Huawei Local Security Checks	2020/8/28	2024/2/22	high
134097	Fedora 31 : python-waitress (2020-65a7744e38)	Nessus	Fedora Local Security Checks	2020/2/27	2024/3/25	high
161188	Debian DLA-3000-1 : waitress - LTS security update	Nessus	Debian Local Security Checks	2022/5/13	2023/10/27	high

偵測

搜尋 Plugin

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high

high