There are packages installed that are affected by a vulnerability referenced in the following CVE:

  - Faye before version 1.4.0, there is a lack of certification validation in TLS handshakes. Faye uses em-
    http-request and faye-websocket in the Ruby version of its client. Those libraries both use the
    `EM::Connection#start_tls` method in EventMachine to implement the TLS handshake whenever a `wss:` URL is
    used for the connection. This method does not implement certificate verification by default, meaning that
    it does not check that the server presents a valid and trusted TLS certificate for the expected hostname.
    That means that any `https:` or `wss:` connection made using these libraries is vulnerable to a man-in-
    the-middle attack, since it does not confirm the identity of the server it is connected to. The first
    request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket.
    Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both
    libraries to support TLS verification before Faye could claim to do the same. Your client would still be
    insecure if its initial HTTPS request was verified, but later WebSocket connections were not. This is
    fixed in Faye v1.4.0, which enables verification by default. For further background information on this
    issue, please see the referenced GitHub Advisory. (CVE-2020-15134)

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且廠商未提供可用的修補程式。

  - Faye 1.4.0版之前的 TLS 交握缺少憑證驗證。Faye 在其 Ruby 版用戶端中使用 em-http-request 和 faye-websocket。每當將 `wss:` URL 用於連線時這些程式庫都會使用 EventMachine 中的 `EM::Connection#start_tls` 方法實作 TLS 交握。此方法預設不會實作憑證驗證這表示它不會檢查伺服器是否針對預期的主機名稱顯示有效且受信任的 TLS 憑證。
    這表示使用這些程式庫建立的任何「https:」或「wss:」連線都容易受到攔截式攻擊影響因為它不會確認所連線的伺服器的身分。Faye 用戶端所提出的第一個要求一律透過一般 HTTP 傳送但是之後的訊息可能會透過 WebSocket 傳送。
    因此容易受到與這些基礎程式庫相同的問題影響而且我們需要兩個程式庫都支援 TLS 驗證Faye 才能宣告這麼做。如果驗證了初始 HTTPS 要求但未驗證之後的 WebSocket 連線則您的用戶端仍會不安全。此問題已在 Faye v1.4.0 中修正預設為啟用驗證。如需有關此問題的進一步背景資訊請參閱提及的 GitHub 公告。 (CVE-2020-15134)

請注意，Nessus 的判定取決於廠商所報告的套件是否存在。

Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 在 1.4.0版之前的 Faye TLS 握手中缺少证书验证。Faye 在其客户端的 Ruby 版本中使用 em-http-request 和 faye-websocket。每当“wss:”URL 用于连接时这些库都使用 EventMachine 中的“EM::Connection#start_tls”方法实现 TLS 握手。默认情况下此方法不会实现证书验证这意味着它不会检查服务器是否为预期主机名提供有效且受信任的 TLS 证书。
    这意味着使用这些库建立的任何“https:”或“wss:”连接容易受到中间人攻击因为它不会确认其所连接服务器的身份。Faye 客户端发出的第一个请求始终通过普通 HTTP 发送，但后续的消息可能通过 WebSocket 发送。
    因此它和这些底层库一样容易受到同样问题的影响我们需要这两个库都支持 TLS 验证Faye 才可以声称这样做。如果其初始 HTTPS 请求得到了验证但后续的 WebSocket 连接则未得到验证则您的客户端仍然是不安全的。Faye v1.4.0 中已修复此问题默认启用验证。如需有关此问题的更多背景信息请参阅引用的 GitHub 公告。 (CVE-2020-15134)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - バージョン 1.4.0より前の Faye には、TLS ハンドシェイクに証明書検証がありません。Faye は、そのクライアントの Ruby バージョンで em-http-request と faye-websocket を使用します。これらのライブラリは両方とも、EventMachine の「EM::Connection#start_tls」メソッドを使用して、「wss:」URL が接続に使用されるたびに TLS ハンドシェイクを実装します。このメソッドは、デフォルトで証明書の検証を実装しません。つまり、サーバーが、期待されるホスト名に対する有効で信頼できる TLS 証明書を提示することをチェックしません。
    これは、これらのライブラリを使用して行われる「https:」または「wss:」接続は、接続されているサーバーの ID を確認しないので、中間者攻撃に対して脆弱であることを意味します。Fayeクライアントが行う最初のリクエストは常に通常のHTTP経由で送信されますが、その後のメッセージはWebSocket経由で送信される場合があります。
    したがって、これらの基盤となるライブラリが同じ問題に対して脆弱であり、Faye が同じことを要求する前に、両方のライブラリが TLS 検証に対応する必要がありました。最初の HTTPS リクエストが検証されたが、その後の WebSocket 接続が検証されなかった場合、クライアントは依然として安全ではありません。これは Faye v1.4.0 で修正されており、デフォルトで検証が有効になります。この問題の詳細については、参照されているGitHubアドバイザリを参照してください。CVE-2020-15134

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - Faye before version 1.4.0, there is a lack of certification validation in TLS handshakes. Faye uses em-     http-request and faye-websocket in the Ruby version of its client. Those libraries both use the     `EM::Connection#start_tls` method in EventMachine to implement the TLS handshake whenever a `wss:` URL is     used for the connection. This method does not implement certificate verification by default, meaning that     it does not check that the server presents a valid and trusted TLS certificate for the expected hostname.
    That means that any `https:` or `wss:` connection made using these libraries is vulnerable to a man-in-     the-middle attack, since it does not confirm the identity of the server it is connected to. The first     request a Faye client makes is always sent via normal HTTP, but later messages may be sent via WebSocket.
    Therefore it is vulnerable to the same problem that these underlying libraries are, and we needed both     libraries to support TLS verification before Faye could claim to do the same. Your client would still be     insecure if its initial HTTPS request was verified, but later WebSocket connections were not. This is     fixed in Faye v1.4.0, which enables verification by default. For further background information on this     issue, please see the referenced GitHub Advisory. (CVE-2020-15134)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Published	Updated	Severity
409641	SCA: security update for faye (GHSA-3q49-h8f9-9fr9)	Tenable Cloud Security	SCA Checks	1/23/2025	7/2/2026	high
409641	SCA: security update for faye (GHSA-3q49-h8f9-9fr9)	Tenable Self-Hosted Container Security	SCA Checks	1/23/2025	7/2/2026	high
257281	Linux Distros 未修補的弱點：CVE-2020-15134	Nessus	Misc.	8/27/2025	2/3/2026	high
257281	Linux Distros 未修补的漏洞：CVE-2020-15134	Nessus	Misc.	8/27/2025	2/3/2026	high
257281	Linux Distros のパッチ未適用の脆弱性: CVE-2020-15134	Nessus	Misc.	8/27/2025	2/3/2026	high
257281	Linux Distros Unpatched Vulnerability : CVE-2020-15134	Nessus	Misc.	8/27/2025	2/3/2026	high

Detections

Analytics

Plugins Search

high

high

high

high

high

high