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

  - 在使用 TELNET 通訊協定進行通訊期間，curl 8.0 之前版本存在輸入驗證弱點，攻擊者可在伺服器交涉期間傳遞惡意特製的使用者名稱和 telnet 選項。
    由於缺少適當的輸入清除，攻擊者可在沒有應用程式意圖的情況下傳送內容或執行選項交涉。如果應用程式允許使用者輸入，攻擊者就可以利用此弱點，在系統上執行任意程式碼。(CVE-2023-27533)

  - curl 8.0.0 之前版本的 SFTP 實作中存在路徑遊走弱點。波浪號 (~) 除了預定用作指示使用者主目錄之相對路徑的第一個元素外，在第一個路徑元素中作為前置詞使用時，會被錯誤地取代。攻擊者可利用此弱點繞過篩選，或在以特定使用者的身分存取伺服器時，透過僞造類似 /~2/foo 的路徑來執行任意程式碼。(CVE-2023-27534)

  - libcurl 8.0.0 之前版本的連線重複使用功能中存在驗證繞過弱點，因為無法檢查 CURLOPT_GSSAPI_DELEGATION 選項中的變更，所以可使用錯誤的使用者權限重複使用之前建立的連線。此弱點會影響 krb5/kerberos/negotiate/GSSAPI 傳輸，並可能導致使用者在未經授權的情況下存取敏感資訊。如果 CURLOPT_GSSAPI_DELEGATION 選項已變更，則最安全的選項是不重複使用連線。(CVE-2023-27536)

  - 早於 v8.0.0 版的 libcurl 中存在驗證繞過弱點。儘管已修改 SSH 選項，但程式仍會重複使用先前建立的 SSH 連線，此連線本應被阻止重複使用。如果組態相符，libcurl 會維護先前使用的連線集區，以便在後續傳輸中重複使用這些連線。不過，組態檢查中忽略了兩個 SSH 設定，這使得它們可以輕鬆比對，進而可能導致重複使用不當連線。(CVE-2023-27538)

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

遠端 CentOS Linux 9 主機上安裝的套件受到 curl-7.76.1-26.el9 版本變更記錄中提及的多個弱點影響。

  - 在使用 TELNET 通訊協定進行通訊期間，curl 8.0 之前版本存在輸入驗證弱點，攻擊者可在伺服器交涉期間傳遞惡意特製的使用者名稱和 telnet 選項。
    由於缺少適當的輸入清除，攻擊者可在沒有應用程式意圖的情況下傳送內容或執行選項交涉。如果應用程式允許使用者輸入，攻擊者就可以利用此弱點，在系統上執行任意程式碼。(CVE-2023-27533)

  - curl 8.0.0 之前版本的 SFTP 實作中存在路徑遊走弱點。波浪號 (~) 除了預定用作指示使用者主目錄之相對路徑的第一個元素外，在第一個路徑元素中作為前置詞使用時，會被錯誤地取代。攻擊者可利用此弱點繞過篩選，或在以特定使用者的身分存取伺服器時，透過僞造類似 /~2/foo 的路徑來執行任意程式碼。(CVE-2023-27534)

  - libcurl 8.0.0 之前版本的 FTP 連線重複使用功能中存在驗證繞過弱點，可導致在後續傳輸期間使用錯誤的憑證。如果先前建立的連線符合目前的設定，則會保留在連線集區中供重複使用。但是，某些 FTP 設定 (如 CURLOPT_FTP_ACCOUNT、CURLOPT_FTP_ALTERNATIVE_TO_USER、CURLOPT_FTP_SSL_CCC 和 CURLOPT_USE_SSL) 並未包含在組態相符檢查中，從而導致它們太容易相符。這可引致 libcurl 在執行傳輸時使用錯誤的憑證，進而可能允許使用者在未經授權的情況下存取敏感資訊。(CVE-2023-27535)

  - libcurl 8.0.0 之前版本的連線重複使用功能中存在驗證繞過弱點，因為無法檢查 CURLOPT_GSSAPI_DELEGATION 選項中的變更，所以可使用錯誤的使用者權限重複使用之前建立的連線。此弱點會影響 krb5/kerberos/negotiate/GSSAPI 傳輸，並可能導致使用者在未經授權的情況下存取敏感資訊。如果 CURLOPT_GSSAPI_DELEGATION 選項已變更，則最安全的選項是不重複使用連線。(CVE-2023-27536)

  - 早於 v8.0.0 版的 libcurl 中存在驗證繞過弱點。儘管已修改 SSH 選項，但程式仍會重複使用先前建立的 SSH 連線，此連線本應被阻止重複使用。如果組態相符，libcurl 會維護先前使用的連線集區，以便在後續傳輸中重複使用這些連線。不過，組態檢查中忽略了兩個 SSH 設定，這使得它們可以輕鬆比對，進而可能導致重複使用不當連線。(CVE-2023-27538)

  - curl v8.1.0 之前版本中存在憑證驗證不當弱點，它支援比對 TLS 伺服器憑證中做為主體別名列出的萬用字元符號。curl 可以被構建為針對 TLS 使用自己的名稱比對函式，而不是 TLS 庫提供的函式。此私人萬用字元比對函式會錯誤比對 IDN (國際網域名稱) 主機，並因此接受本應不相符的符號。IDN 主機名稱會先轉換為 puny 程式碼，然後再用於憑證檢查。Puny 編碼名稱一律以「xn--」開頭，且不應允許進行符號比對，但 curl 中的萬用字元檢查仍可檢查「x*」，即使 IDN 名稱很可能不包含任何與「x」類似的符號，仍會被視為與「x*」一致。(CVE-2023-28321)

  - curl v8.1.0 之前版本在進行 HTTP(S) 傳輸時，如果之前曾使用相同的控點發出使用讀取回呼 (「CURLOPT_READFUNCTION」) 的「PUT」要求，則 libcurl 可能會錯誤地使用此回呼來要求要傳送的資料，即使已經設定「CURLOPT_POSTFIELDS」選項亦如此。此缺陷可能會使應用程式意外產生錯誤行為，並在第二次傳輸中傳送錯誤資料或使用釋放後的記憶體，或發生類似情況。從 PUT 變更為 POST 時 (預期如此)，重複使用的控點邏輯中存在此問題。(CVE-2023-28322)

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

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

  - 早於 v8.0.0 版的 libcurl 中存在驗證繞過弱點。儘管已修改 SSH 選項，但程式仍會重複使用先前建立的 SSH 連線，此連線本應被阻止重複使用。如果組態相符，libcurl 會維護先前使用的連線集區，以便在後續傳輸中重複使用這些連線。不過，組態檢查中忽略了兩個 SSH 設定，這使得它們可以輕鬆比對，進而可能導致重複使用不當連線。(CVE-2023-27538)

請注意，Nessus 依賴供應商報告的套件存在。

遠端主機上安裝的 Splunk 版本低於測試版本。因此，它會受到 SVD-2023-0613 公告中提及的一個弱點影響。

  - 在 Node.js 的 xmldom (發佈為 @xmldom/xmldom) 套件 0.8.3 之前版本中，透過 p 變數可在 dom.js 的 copy 函式中產生原型污染弱點。注意：廠商表示我們正在將此報告標記為無效，但是某些第三方認為原型插入/原型污染不僅在全域物件受到遞回合併或深度複製污染時發生，也在目標物件受到污染時發生。(CVE-2022-37616)

  - curl 7.84.0 之前版本將 cookie、alt-svc 和 hsts 資料儲存到本機檔案時，會透過將暫存名稱重新命名為最終目標檔案名稱來完成作業，從而使此作業成爲原子型作業。在此重新命名作業中，它可能會意外*放寬*針對目標檔案的權限，讓更多使用者可存取更新後的檔案。(CVE-2022-32207)

  - 在 2.10.3 之前的 libxml2 中發現一個問題。在啟用 XML_PARSE_HUGE 剖析器選項的情況下剖析數個 GB 的 XML 文件時，數個整數計數器可能溢位。這會導致程式嘗試以負的 2GB 位移存取陣列，這通常會導致區段錯誤。(CVE-2022-40303)

  - 在 2.10.3 之前的 libxml2 中發現一個問題。某些無效的 XML 實體定義可損毀雜湊表金鑰，這可能導致後續發生邏輯錯誤。在一種情況下，可能會引發雙重釋放。(CVE-2022-40304)

  - X.509 GeneralName 中有一個與 X.400 位址處理相關的類型混淆弱點。
    X.400 位址被剖析為 ASN1_STRING，但 GENERAL_NAME 的公開結構定義錯誤地將 x400Address 欄位的類型指定為 ASN1_TYPE。此欄位隨後會被 OpenSSL 函式 GENERAL_NAME_cmp 解譯為 ASN1_TYPE，而非 ASN1_STRING。啟用 CRL 檢查時 (即應用程式設定 X509_V_FLAG_CRL_CHECK 旗標)，此弱點可能允許攻擊者向 memcmp 呼叫傳遞任意指標，使其能夠讀取記憶體內容或發動拒絕服務攻擊。在大多數情況下，攻擊者需要同時提供憑證鍊和 CRL，兩者都不需要有效的簽章。如果攻擊者只控制其中一個輸入，則另一個輸入必須已包含 X.400 位址作為 CRL 發佈點，此情況並不常見。因此，此弱點最有可能只影響已實作透過網路擷取 CRL 這一功能的應用程式。(CVE-2023-0286)

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

遠端主機上安裝的 IBM EngineeringRequirements Management DOORS (之前稱為 IBM Rational DOORS) 版本為 9.7.2.8 之前的 9.7.2.x 版。因此，它會受到 7124058 公告中所提及的多個弱點影響。

  - 1.9.1 之前的 Apache Shiro 版本可能將 RegexRequestMatcher 錯誤地設定為可在某些 servlet 容器上繞過。在規則運算式中使用含有 `.` 的 RegExPatternMatcher 的應用程式可能容易受到授權繞過影響。(CVE-2022-32532)

  - Java OpenWire 通訊協定封送處理器容易受到遠端程式碼執行影響。出現此弱點時，若遠端攻擊者可透過網路存取使用 Java 的 OpenWire 訊息代理程式或用戶端，便可能透過操控 OpenWire 通訊協定中的序列化類別類型來執行任意 shell 命令，造成用戶端或訊息代理程式 (分別) 具現化類別路徑的任何類別。建議使用者將訊息代理程式和用戶端升級至 5.15.16、5.16.7、5.17.6 或 5.18.3 版，即可修正此問題。
    (CVE-2023-46604)

  - 2.13.9 之前的 Scala 2.13.x 的 JAR 檔案中含有 Java 還原序列化鏈結。就其本身而言，它不會遭到惡意利用。只存在與應用程式內的 Java 物件還原序列化相關的風險。在這類情況下，攻擊者可透過小工具鏈結，利用此風險清除任意檔案的內容、建立網路連線，或可能執行任意程式碼 (特別是 Function0 函式)。(CVE-2022-36944)

  - IBM Engineering Requirements Management DOORS 9.7.2.7 容易遭受跨網站要求偽造弱點影響，攻擊者可藉以執行網站信任之使用者傳送的惡意和未經授權動作。IBM X-Force ID：251216。(CVE-2023-28949)

  - 在適用於 4.14 之前的 CKEditor 4.0 版的 HTML 資料處理器中有一個跨網站指令碼 (XSS) 弱點，允許遠端攻擊者透過特製的受保護註解 (使用 cke_protected 語法) 插入任意 Web 指令碼。(CVE-2020-9281)

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

遠端主機受到 GLSA-202310-12 中所述的弱點影響 (curl：多個弱點)

  - curl <7.87.0 HSTS 檢查中存在弱點，攻擊者可繞過檢查以誘騙其繼續使用 HTTP。
    若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。但是，如果給定 URL 中的主機名稱首先使用 IDN 轉換過程中被取代為 ASCII 對應項的 IDN 字元，則可能繞過 HSTS 機制。如同使用 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) 字元，而非一般的 ASCII 句號 (U+002E)「.」。然後在後續要求中，它不會偵測 HSTS 狀態並進行純文字傳輸。因為它會儲存以 IDN 編碼的資訊，但尋找以 IDN 解碼的資訊。(CVE-2022-43551)

  - 低於 7.87.0 版的 curl 中存在一個釋放後使用弱點。可以要求 Curl 透過 HTTP Proxy 為其支援的所有通訊協定*建立通道*。HTTP Proxy 可以 (而且經常) 拒絕此類通道作業。
    當特定通訊協定 SMB 或 TELNET 被拒絕時，curl 會在其傳輸關閉程式碼路徑中使用堆積配置結構。(CVE-2022-43552)

  - 早於 v7.88.0 的 curl 中存在敏感資訊純文字傳輸漏洞，當連續請求多個 URL 時，該漏洞可能導致 HSTS 功能失敗。若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。然而，在相同命令行上完成後，後續傳輸會意外忽略此 HSTS 機制，因為狀態將無法正確執行。 (CVE-2023-23914)

  - 早於 v7.88.0 的 curl 中存在敏感資訊純文字傳輸漏洞，當並行請求多個 URL 時，該漏洞可能導致 HSTS 功能行為不正確。若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。然而，當並行完成多個傳輸時，此 HSTS 機制會意外失敗，因為 HSTS 快取檔案會被最近完成的傳輸覆寫。之後對舊版主機名稱的純 HTTP 傳輸*不會*正確升級至 HSTS。
    (CVE-2023-23915)

  - v7.88.0 之前版本的 curl 基於鏈結式 HTTP 壓縮演算法，存在資源配置無限制或無節流弱點，這表示伺服器回應可被壓縮多次，並且可能使用不同的演算法。此解壓縮鏈中可接受的連結數設有上限，但該上限是依標頭實作的，惡意伺服器可利用許多標頭來插入幾乎不受限制的壓縮步驟數。使用此類解壓縮鏈可導致 malloc 炸彈，進而使 curl 最終花費大量已配置的堆積記憶體，或嘗試並傳回記憶體不足錯誤。(CVE-2023-23916)

  - 在使用 TELNET 通訊協定進行通訊期間，curl 8.0 之前版本存在輸入驗證弱點，攻擊者可在伺服器交涉期間傳遞惡意特製的使用者名稱和 telnet 選項。
    由於缺少適當的輸入清除，攻擊者可在沒有應用程式意圖的情況下傳送內容或執行選項交涉。如果應用程式允許使用者輸入，攻擊者就可以利用此弱點，在系統上執行任意程式碼。(CVE-2023-27533)

  - curl 8.0.0 之前版本的 SFTP 實作中存在路徑遊走弱點。波浪號 (~) 除了預定用作指示使用者主目錄之相對路徑的第一個元素外，在第一個路徑元素中作為前置詞使用時，會被錯誤地取代。攻擊者可利用此弱點繞過篩選，或在以特定使用者的身分存取伺服器時，透過僞造類似 /~2/foo 的路徑來執行任意程式碼。(CVE-2023-27534)

  - libcurl 8.0.0 之前版本的 FTP 連線重複使用功能中存在驗證繞過弱點，可導致在後續傳輸期間使用錯誤的憑證。如果先前建立的連線符合目前的設定，則會保留在連線集區中供重複使用。但是，某些 FTP 設定 (如 CURLOPT_FTP_ACCOUNT、CURLOPT_FTP_ALTERNATIVE_TO_USER、CURLOPT_FTP_SSL_CCC 和 CURLOPT_USE_SSL) 並未包含在組態相符檢查中，從而導致它們太容易相符。這可引致 libcurl 在執行傳輸時使用錯誤的憑證，進而可能允許使用者在未經授權的情況下存取敏感資訊。(CVE-2023-27535)

  - libcurl 8.0.0 之前版本的連線重複使用功能中存在驗證繞過弱點，因為無法檢查 CURLOPT_GSSAPI_DELEGATION 選項中的變更，所以可使用錯誤的使用者權限重複使用之前建立的連線。此弱點會影響 krb5/kerberos/negotiate/GSSAPI 傳輸，並可能導致使用者在未經授權的情況下存取敏感資訊。如果 CURLOPT_GSSAPI_DELEGATION 選項已變更，則最安全的選項是不重複使用連線。(CVE-2023-27536)

  - libcurl 8.0.0 之前版本在不同的處理序之間共用 HSTS 資料時，會產生重複釋放弱點。
    引入此共用功能時未考慮跨獨立執行緒的共用，但說明文件中並未指出此事實。由於缺少 mutex 或執行緒鎖定，共用相同 HSTS 資料的兩個執行緒可能會導致重複釋放或釋放後使用。(CVE-2023-27537)

  - 早於 v8.0.0 版的 libcurl 中存在驗證繞過弱點。儘管已修改 SSH 選項，但程式仍會重複使用先前建立的 SSH 連線，此連線本應被阻止重複使用。如果組態相符，libcurl 會維護先前使用的連線集區，以便在後續傳輸中重複使用這些連線。不過，組態檢查中忽略了兩個 SSH 設定，這使得它們可以輕鬆比對，進而可能導致重複使用不當連線。(CVE-2023-27538)

  - 在低於 v8.1.0 的 curl 中存在釋放後使用弱點，體現在 libcurl 使用 SHA 256 雜湊驗證 SSH 伺服器公開金鑰中。此檢查失敗時，libcurl 會在傳回包含 (現已釋放) 雜湊的錯誤訊息之前，釋放記憶體以供指紋識別功能使用。此瑕疵有將敏感堆積型資料插入錯誤訊息中的風險，該訊息可能會顯示給使用者，或可能會遭到洩漏和洩漏。(CVE-2023-28319)

  - 在低於 v8.1.0 的 curl 中存在拒絕服務弱點，體現在 libcurl 提供了多個不同的後端來解析構建時選擇的主機名稱中。如果構建為使用同步解析器，則允許名稱解析為使用「alarm()」和「siglongjmp()」的緩慢作業逾時。執行此操作時，libcurl 會使用未受 mutex 保護的全域緩衝區，因此多執行緒應用程式可能會損毀或發生其他不當行為。(CVE-2023-28320)

  - curl v8.1.0 之前版本中存在憑證驗證不當弱點，它支援比對 TLS 伺服器憑證中做為主體別名列出的萬用字元符號。curl 可以被構建為針對 TLS 使用自己的名稱比對函式，而不是 TLS 庫提供的函式。此私人萬用字元比對函式會錯誤比對 IDN (國際網域名稱) 主機，並因此接受本應不相符的符號。IDN 主機名稱會先轉換為 puny 程式碼，然後再用於憑證檢查。Puny 編碼名稱一律以「xn--」開頭，且不應允許進行符號比對，但 curl 中的萬用字元檢查仍可檢查「x*」，即使 IDN 名稱很可能不包含任何與「x」類似的符號，仍會被視為與「x*」一致。(CVE-2023-28321)

  - curl v8.1.0 之前版本在進行 HTTP(S) 傳輸時，如果之前曾使用相同的控點發出使用讀取回呼 (「CURLOPT_READFUNCTION」) 的「PUT」要求，則 libcurl 可能會錯誤地使用此回呼來要求要傳送的資料，即使已經設定「CURLOPT_POSTFIELDS」選項亦如此。此缺陷可能會使應用程式意外產生錯誤行為，並在第二次傳輸中傳送錯誤資料或使用釋放後的記憶體，或發生類似情況。從 PUT 變更為 POST 時 (預期如此)，重複使用的控點邏輯中存在此問題。(CVE-2023-28322)

  - 當 curl 擷取 HTTP 回應時，會儲存傳入的標頭，以便日後透過 libcurl 標頭 API 進行存取。不過，curl 並未限制其可在回應中接受的標頭數量或大小，進而允許惡意伺服器串流無限系列的標頭，並最終造成 curl 耗盡堆積記憶體。(CVE-2023-38039)

  - CVE-2023-38545 是 libcurl 和 curl 之 SOCKS5 proxy 交握中的一個堆積型緩衝區溢位弱點。當為 curl 指定要傳送至長度超過 255 位元組的 SOCKS5 proxy 的主機名稱時，它會切換至本機名稱解析，以便在將位址傳送至 SOCKS5 proxy 之前先解析該位址。不過，由於 2020 年引入的一個錯誤，此本機名稱解析可能會因為 SOCKS5 交握緩慢而失敗，進而造成 curl 將長度大於 255 位元組的主機名稱傳遞至目標緩衝區，從而導致堆積溢位。 CVE-2023-38545 的公告包含惡意 HTTPS 伺服器重新導向至特製 URL 的惡意利用情形範例。盡快大家認為攻擊者似乎需要影響 SOCKS5 交握的緩慢速度，但該公告指出伺服器延遲可能慢到足以觸發此錯誤。(CVE-2023-38545)

  - 如需詳細資料，請檢閱提及的 CVE 識別碼。請注意，遠端程式碼執行的風險僅限於 SOCKS 使用。(CVE-2023-38546)

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

ID	Name	Product	Family	Published	Updated	Severity
194927	Universal Forwarders < 8.1.14, 8.2.0 < 8.2.11, 9.0.0 < 9.0.5 (SVD-2023-0614)	Nessus	CGI abuses	5/2/2024	5/30/2024	critical
185089	RHEL 9：curl (RHSA-2023: 6679)	Nessus	Red Hat Local Security Checks	11/7/2023	3/13/2025	high
191296	CentOS 9：curl-7.76.1-26.el9	Nessus	CentOS Local Security Checks	2/29/2024	4/26/2024	high
227332	Linux Distros 未修補弱點：CVE-2023-27538	Nessus	Misc.	3/5/2025	3/5/2025	medium
194919	Splunk Enterprise < 8.1.14、8.2.0 < 8.2.11、9.0.0 < 9.0.5 (SVD-2023-0613)	Nessus	CGI abuses	5/2/2024	7/26/2024	critical
191754	IBM Engineering Requirements Management DOORS 9.7.2.x < 9.7.2.8 多個弱點 (7124058)	Nessus	Windows	3/8/2024	3/12/2024	critical
182879	GLSA-202310-12: curl：多個弱點	Nessus	Gentoo Local Security Checks	10/11/2023	12/8/2023	critical
194926	Universal Forwarder 8.2.0 < 8.2.12、9.0.0 < 9.0.6、9.1.0 < 9.1.1 (SVD-2023-0809)	Nessus	CGI abuses	5/2/2024	5/30/2024	critical

Detections

Analytics

Plugins Search

critical

high

high

medium

critical

critical

critical

critical