遠端主機上安裝的 curl 版本為早於 8.7.1 的版本。因此，它受到 SSA:2024-087-01 公告中提及的多個弱點影響。

  - 當通訊協定選取參數選項停用所有通訊協定而不新增任何通訊協定時，由於移除通訊協定的邏輯錯誤，一組預設的通訊協定會保留在允許的設定中。下列命令會使用已明確停用的純文字通訊協定，對 curl.se 執行要求。curl --proto -all、-http http://curl.se 只有在所選通訊協定集停用了整組可用通訊協定時，才會出現此缺陷，而這組通訊協定本身就是沒有實際用途的命令，因此不太可能在實際情況中發生。因此，curl 安全團隊已將此評估為低嚴重性錯誤。(CVE-2024-2004)

  - 構建為使用 wolfSSL 時，libcurl 在某些情況下會略過 QUIC 連線的憑證驗證。如果告知使用未知/錯誤的密碼或曲線，錯誤路徑會意外略過驗證並傳回 OK，因而忽略任何憑證問題。(CVE-2024-2379)

  - 當應用程式告知 libcurl 它想要允許 HTTP/2 伺服器推送，且針對推送接收的標頭數量超過允許的上限 (1000) 時，libcurl 會中止伺服器推送。中止時，libcurl 意外未釋放所有先前配置的標頭，而是洩漏了記憶體。
    此外，這種錯誤條件會失敗，且無任何訊息，因此應用程式不容易檢測到。
    (CVE-2024-2398)

  - 構建為使用 mbedTLS 時，libcurl 不會檢查連線至指定為 IP 位址的主機之 TLS 連線的伺服器憑證。當指定的主機名稱以 IP 位址提供時，libcurl 會錯誤地避免使用設定主機名稱函式，因此完全略過憑證檢查。這會影響 TLS 通訊協定 (HTTPS、FTPS、IMAPS、POPS3、SMTPS 等) 的所有使用方式。(CVE-2024-2466)

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

偵測

Slackware Linux 15.0 最新版 curl 多個弱點 (SSA：2024-087-01)

high Nessus Plugin ID 192632

版本 1.0