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

  - 當使用 `-t` 命令行選項 (在 libcurl 中稱為`CURLOPT_TELNETOPTIONS`) 傳送 variable=content 配對至 TELNET 伺服器時，curl 7.7 到 7.76.1 會受到資訊洩漏問題的影響。由於傳送 NEW_ENV 變數的選項剖析器中有一個缺陷，libcurl 可能會被用來將未初始化的資料從堆疊型緩衝區傳遞至伺服器，進而可能導致使用純文字網路通訊協定向伺服器洩漏敏感的內部資訊。(CVE-2021-22898)

  - libcurl 會將先前使用的連線保留在連線集區中，以便在後續傳輸時重複使用其中符合設定的某個連線。由於邏輯中的錯誤，組態比對函式未將「issuercert」納入考量，因此會比較所涉及的路徑*案例不敏感地*，這可導致 libcurl 重複使用錯誤的連線。檔案路徑在許多系統上可能是或可能是區分大小寫的，但並非全部都區分大小寫，而且可能會根據所使用的檔案系統而有所不同。比較也未包含「issuer cert」其中，傳輸可設定為符合驗證伺服器憑證的方式。(CVE-2021-22924)

  - 與 IMAP、POP3 或 FTP 伺服器交談時，使用者可告知 curl >= 7.20.0 和 <= 7.78.0 以要求成功升級至 TLS (命令行上的 `--ssl-reqd` 或設為 `CURLUSESSL_CONTROL` 的 `CURLOPT_USE_SSL` 或 `CURLUSESSL_ALL` withlibcurl)。如果伺服器會傳回特製但完全合法的回應，則可繞過此要求。此缺陷會導致 curl 以無訊息模式繼續其作業
    **沒有 TLS** 與指示和預期相反，可能透過網路以純文字洩漏敏感資料。(CVE-2021-22946)

  - 當 curl >= 7.20.0 和 <= 7.78.0 連線至 IMAP 或 POP3 伺服器以擷取使用 STARTTLS 升級至 TLS 安全性的資料時，伺服器可回應並一次傳回 curl 快取的多個回應。
    然後，curl 會升級至 TLS，但不會排清已快取回應的佇列，而是繼續使用並信任其在 TLS 交握*之前*收到的回應，如同這些回應已經通過驗證一般。藉此缺陷，中間攻擊者可先插入假的回應，然後從合法伺服器傳遞 TLS 流量，並誘騙 curl 將資料傳送回給認為攻擊者插入的資料來自受 TLS 保護之伺服器的使用者。(CVE-2021-22947)

  - curl 7.33.0 至 7.82.0 (含) 版本中有不當驗證弱點，可能允許在未正確確定已使用為此傳輸設定的相同憑證來驗證連線的情況下，重複使用 OAUTH2 驗證的代理伺服器連線。此弱點會影響已啟用 SASL 的通訊協定：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S) (僅限 openldap)。(CVE-2022-22576)

  - curl 7.83.0 中修正的憑證保護不足弱點可能會在 HTTP 重新導向至相同主機不同連接埠號碼時洩漏驗證或 Cookie 標頭資料。(CVE-2022-27776)

  - libcurl 提供「CURLOPT_CERTINFO」選項，允許應用程式要求傳回有關伺服器憑證鏈的詳細資料。由於有錯誤的函式，惡意伺服器可造成使用 NSS 構建的 libcurl 在嘗試擷取該資訊時陷入無止境的忙碌迴圈。
    (CVE-2022-27781)

  - 即使已變更 TLS 或 SSH 相關選項，libcurl 仍會重複使用之前建立的連線，而這些連線本應禁止重複使用。若其中一個連線符合設定，libcurl 會將之前使用過的連線保留在連線集區中，以備後續傳送重複使用。但是，組態比對檢查會遺漏數個 TLS 和 SSH 設定，這使匹配變得非常容易。(CVE-2022-27782)

  - curl 7.84.0 之前版本支援鏈結式 HTTP 壓縮演算法，這表示伺服器回應可被壓縮多次，並且可能使用不同的演算法。此解壓縮鏈中可接受的連結數不受限制，因此惡意伺服器可以插入幾乎不限數量的壓縮步驟。使用此類解壓縮鏈可導致 malloc 炸彈，使 curl 最終佔用大量已配置的堆積記憶體，或嘗試並傳回記憶體不足錯誤。(CVE-2022-32206)

  - curl 7.84.0 之前版本在執行受 krb5 保護的 FTP 傳輸時，會錯誤處理訊息驗證失敗。
    攻擊者可利用此缺陷執行攔截式攻擊而不被察覺，甚至可以向用戶端插入資料。(CVE-2022-32208)

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

遠端主機上安裝的 curl 版本為早於 7.61.1-12.101 的版本。因此，會受到 ALAS-2022-1646 公告中所提及的多個弱點影響。

  - curl 7.33.0 至 7.82.0 (含) 版本中有不當驗證弱點，可能允許在未正確確定已使用為此傳輸設定的相同憑證來驗證連線的情況下，重複使用 OAUTH2 驗證的代理伺服器連線。此弱點會影響已啟用 SASL 的通訊協定：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S) (僅限 openldap)。(CVE-2022-22576)

  - curl 4.9 至 7.82.0 版 (含) 存在憑證保護不足弱點，允許攻擊者在遵循身份驗證中結合使用的 HTTP(S) 重新導向時擷取憑證，將憑證洩漏給不同通訊協定或連接埠號碼上的其他服務。
    (CVE-2022-27774)

  - curl 7.83.0 中修正的憑證保護不足弱點可能會在 HTTP 重新導向至相同主機不同連接埠號碼時洩漏驗證或 Cookie 標頭資料。(CVE-2022-27776)

  - libcurl 提供「CURLOPT_CERTINFO」選項，允許應用程式要求傳回有關伺服器憑證鏈的詳細資料。由於有錯誤的函式，惡意伺服器可造成使用 NSS 構建的 libcurl 在嘗試擷取該資訊時陷入無止境的忙碌迴圈。
    (CVE-2022-27781)

  - 即使已變更 TLS 或 SSH 相關選項，libcurl 仍會重複使用之前建立的連線，而這些連線本應禁止重複使用。若其中一個連線符合設定，libcurl 會將之前使用過的連線保留在連線集區中，以備後續傳送重複使用。但是，組態比對檢查會遺漏數個 TLS 和 SSH 設定，這使匹配變得非常容易。(CVE-2022-27782)

  - curl 7.84.0 之前版本支援鏈結式 HTTP 壓縮演算法，這表示伺服器回應可被壓縮多次，並且可能使用不同的演算法。此解壓縮鏈中可接受的連結數不受限制，因此惡意伺服器可以插入幾乎不限數量的壓縮步驟。使用此類解壓縮鏈可導致 malloc 炸彈，使 curl 最終佔用大量已配置的堆積記憶體，或嘗試並傳回記憶體不足錯誤。(CVE-2022-32206)

  - curl 7.84.0 之前版本在執行受 krb5 保護的 FTP 傳輸時，會錯誤處理訊息驗證失敗。
    攻擊者可利用此缺陷執行攔截式攻擊而不被察覺，甚至可以向用戶端插入資料。(CVE-2022-32208)

  - 使用 curl 從 HTTP(S) 伺服器擷取和剖析 cookie 時，它會接受使用控製程式碼的 cookie，稍後將這些 cookie 傳回 HTTP 伺服器時，可能會使伺服器傳回 400 回應。
    有效地允許協助網站拒絕對所有同級網站的服務。(CVE-2022-35252)

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

根據其自我報告的版本號碼，遠端主機上執行的 Nessus Network Monitor 低於 6.2.2 版。因此，會受到 TNS-2023-23 公告中所提及的多個弱點影響。由於發現多個第三方元件中存在弱點，廠商已提供更新版。出於慎重和符合良好實務，Tenable 選擇升級這些元件，以解決這些問題的潛在影響。Nessus Network Monitor 6.2.2 更新了下列元件：

  - 1.10.0 版到 1.19.1 版的 c-ares。
  - 7.79.1 版到 8.1.2 版的 curl。
  - 1.0.6 版到 1.0.8 版的 libbzip2。
  - 8.42 版到 8.44 版的 libpcre。
  - 2.7.7 版到 2.11.1 版的 libxml2。
  - 1.1.26 版到 1.1.37 版的 libxslt。
  - 1.2.18 版到 1.2.37 版的 libxmlsec。
  - 3.27.2 版到 3.40.1 版的 sqlite。
  - 1.3.1 版到 1.4.1 版的 jQuery Cookie。
  - 1.13.0 版到 1.13.2 版的 jQuery UI。
  - 3.0.8 版到 3.0.9 版的 OpenSSL。

遠端 Ubuntu 16.04 ESM 主機上安裝的多個套件受到 USN-5499-1 公告中提及的多個弱點影響。

  - curl 7.84.0 之前版本在執行受 krb5 保護的 FTP 傳輸時，會錯誤處理訊息驗證失敗。
    攻擊者可利用此缺陷執行攔截式攻擊而不被察覺，甚至可以向用戶端插入資料。(CVE-2022-32208)

  - libcurl 提供「CURLOPT_CERTINFO」選項，允許應用程式要求傳回有關伺服器憑證鏈的詳細資料。由於有錯誤的函式，惡意伺服器可造成使用 NSS 構建的 libcurl 在嘗試擷取該資訊時陷入無止境的忙碌迴圈。
    (CVE-2022-27781)

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

遠端主機上安裝的 curl 版本為早於 7.83.1 的版本。因此，會受到 SSA:2022-131-01 公告中提及的一個弱點影響。

  - 即使已變更 TLS 或 SSH 相關選項，libcurl 仍會重複使用之前建立的連線，而這些連線本應禁止重複使用。若其中一個連線符合設定，libcurl 會將之前使用過的連線保留在連線集區中，以備後續傳送重複使用。但是，組態比對檢查會遺漏數個 TLS 和 SSH 設定，這使匹配變得非常容易。(CVE-2022-27782)

  - --no-clobber 與 --remove-on-error 一起使用時，7.83.1 版中已修正的使用錯誤解析的名稱弱點可能會移除錯誤的檔案。(CVE-2022-27778)

  - 如果主機名稱以一個點結尾，libcurl 會錯誤地允許為頂層網域 (TLD) 設定 cookie。可以指示 curl 接收和傳送 cookie。構建 curl 的 cookie 引擎時，可以使用 [公開後置詞清單]，也可以不使用 (https://publicsuffix.org/)awareness。如果未提供 PSL 支援，則需要基本檢查，以至少防止在 TLD 上設定 cookie。如果 URL 中的主機名稱以一個點結尾，此檢查會被中斷。這可造成任意網站皆可設定 cookie，然後傳送至不同且不相關的網站或網域。(CVE-2022-27779)

  - 解碼 URL 的主機名稱部分時，curl URL 剖析器會錯誤地接受以百分號編碼的 URL 分隔符號 (如「/」)，從而使其在以後擷取時成為使用錯誤主機名稱的 *不同* URL。例如，剖析器會允許諸如 `http://example.com%2F127.0.0.1/` 的 URL 並將其轉置為 `http://example.com/127.0.0.1/`。攻擊者可利用此瑕疵規避篩選、檢查等。
    (CVE-2022-27780)

  - libcurl 提供「CURLOPT_CERTINFO」選項，允許應用程式要求傳回有關伺服器憑證鏈的詳細資料。由於有錯誤的函式，惡意伺服器可造成使用 NSS 構建的 libcurl 在嘗試擷取該資訊時陷入無止境的忙碌迴圈。
    (CVE-2022-27781)

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

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

  - 指示 curl 使用 metalink 功能下載內容時，系統會根據 metalink XML 檔案中提供的雜湊驗證內容。metalink XML 檔案會向用戶端指出如何從一組不同的 URL (可能由不同的伺服器主控) 中取得相同的內容，然後用戶端可以從其中一個或多個 URL 下載檔案。以序列或平行方式。如果主控內容的其中一個伺服器遭到入侵，且該伺服器上的特定檔案內容已為修改後的內容取代，則在完成下載後，當檔案的雜湊不符時，curl 應該會偵測到此問題。
    它應該移除內容，並嘗試從另一個 URL 取得內容。應用程式並未這樣做，而是僅在文字中提及此類雜湊不符，並且可能將惡意內容保留在磁碟上的檔案中。(CVE-2021-22922)

  - 當指示 curl 使用 metalink 功能取得內容，並使用使用者名稱和密碼下載 metalink XML 檔案時，這些相同的憑證隨後會傳送至 curl 將從中下載或嘗試下載內容的每一個伺服器。通常與使用者的預期和意圖相反，而且不告訴使用者。(CVE-2021-22923)

  - curl 支援 `-t` 命令列選項，在 libcurl 中稱為 `CURLOPT_TELNETOPTIONS`。此很少使用的選項用於傳送 variable=content 對至 TELNET 伺服器。由於傳送 `NEW_ENV` 變數的選項剖析器存在缺陷，libcurl 可將未初始化的資料從堆疊型緩衝區傳送至伺服器。因此，這可能會將敏感的內部資訊洩漏給使用純文字網路通訊協定的伺服器，這是因為在剖析應用程式提供的字串時，curl 未正確呼叫和使用 sscanf()。(CVE-2021-22925)

  - libcurl-using 應用程式可要求在傳輸中使用特定用戶端憑證。這是透過 `CURLOPT_SSLCERT` 選項 (`--cert` 與命令行工具) 達成。將 libcurl 建構為使用 macOS 原生 TLS 程式庫 Secure Transport 時，應用程式可使用相同選項依名稱或檔案名稱要求用戶端憑證。如果名稱以檔案形式存在，則將使用該檔案而非依名稱。如果應用程式目前執行的運作中目錄可由其他使用者寫入 (像是 `/tmp`)，惡意使用者便可建立與應用程式想要使用的名稱同名的檔案名稱，因此誘騙應用程式使用檔案型憑證，而非名稱參照的憑證，進而使 libcurl 在 TLS 連線交握中傳送錯誤的用戶端憑證。(CVE-2021-22926)

  - 將資料傳送至 MQTT 伺服器時，libcurl <= 7.73.0 和 7.78.0 版在某些情況下可將指標錯誤地保留至已釋放的記憶體區域，並在後續呼叫中再次使用該指標來傳送資料，然後*再次*釋放 。(CVE-2021-22945)

  - 與 IMAP、POP3 或 FTP 伺服器交談時，使用者可告知 curl >= 7.20.0 和 <= 7.78.0 以要求成功升級至 TLS (命令列上的 `--ssl-reqd` 或設為 `CURLUSESSL_CONTROL` 的 `CURLOPT_USE_SSL` 或 `CURLUSESSL_ALL` withlibcurl)。如果伺服器會傳回特製但完全合法的回應，則可繞過此要求。此缺陷會導致 curl 以無訊息模式繼續其作業
    **沒有 TLS** 與指示和預期相反，可能透過網路以純文字洩漏敏感資料。(CVE-2021-22946)

  - 當 curl >= 7.20.0 和 <= 7.78.0 連線至 IMAP 或 POP3 伺服器以擷取使用 STARTTLS 升級至 TLS 安全性的資料時，伺服器可回應並一次傳回 curl 快取的多個回應。
    然後，curl 會升級至 TLS，但不會排清已快取回應的佇列，而是繼續使用並信任其在 TLS 交握*之前*收到的回應，如同這些回應已經通過驗證一般。藉此缺陷，中間攻擊者可先插入假的回應，然後從合法伺服器傳遞 TLS 流量，並誘騙 curl 將資料傳送回給認為攻擊者插入的資料來自受 TLS 保護之伺服器的使用者。(CVE-2021-22947)

  - curl 7.33.0 至 7.82.0 (含) 版本中有不當驗證弱點，可能允許在未正確確定已使用為此傳輸設定的相同憑證來驗證連線的情況下，重複使用 OAUTH2 驗證的代理伺服器連線。此弱點會影響已啟用 SASL 的通訊協定：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S) (僅限 openldap)。(CVE-2022-22576)

  - curl 4.9 至 7.82.0 版 (含) 存在憑證保護不足弱點，允許攻擊者在遵循身份驗證中結合使用的 HTTP(S) 重新導向時擷取憑證，將憑證洩漏給不同通訊協定或連接埠號碼上的其他服務。
    (CVE-2022-27774)

  - curl 7.65.0 至 7.82.0 中存在資訊洩漏弱點，在使用連線集區中具有不同區域 ID 的 IPv6 位址時，它可能會改為重複使用連線。(CVE-2022-27775)

  - curl 7.83.0 中修正的憑證保護不足弱點可能會在 HTTP 重新導向至相同主機不同連接埠號碼時洩漏驗證或 Cookie 標頭資料。(CVE-2022-27776)

  - 如果主機名稱以一個點結尾，libcurl 會錯誤地允許為頂層網域 (TLD) 設定 cookie。可以指示 curl 接收和傳送 cookie。構建 curl 的 cookie 引擎時，可以使用 [公開後置詞清單]，也可以不使用 (https://publicsuffix.org/)awareness。如果未提供 PSL 支援，則需要基本檢查，以至少防止在 TLD 上設定 cookie。如果 URL 中的主機名稱以一個點結尾，此檢查會被中斷。這可造成任意網站皆可設定 cookie，然後傳送至不同且不相關的網站或網域。(CVE-2022-27779)

  - 解碼 URL 的主機名稱部分時，curl URL 剖析器會錯誤地接受以百分號編碼的 URL 分隔符號 (如「/」)，從而使其在以後擷取時成為使用錯誤主機名稱的 *不同* URL。例如，剖析器會允許諸如 `http://example.com%2F127.0.0.1/` 的 URL 並將其轉置為 `http://example.com/127.0.0.1/`。攻擊者可利用此瑕疵規避篩選、檢查等。
    (CVE-2022-27780)

  - libcurl 提供「CURLOPT_CERTINFO」選項，允許應用程式要求傳回有關伺服器憑證鏈的詳細資料。由於有錯誤的函式，惡意伺服器可造成使用 NSS 構建的 libcurl 在嘗試擷取該資訊時陷入無止境的忙碌迴圈。
    (CVE-2022-27781)

  - 即使已變更 TLS 或 SSH 相關選項，libcurl 仍會重複使用之前建立的連線，而這些連線本應禁止重複使用。若其中一個連線符合設定，libcurl 會將之前使用過的連線保留在連線集區中，以備後續傳送重複使用。但是，組態比對檢查會遺漏數個 TLS 和 SSH 設定，這使匹配變得非常容易。(CVE-2022-27782)

  - 若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 直接使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。如果在指定的 URL 中，主機名稱使用了尾隨點，但在構建 HSTS 快取時未使用，則可繞過此機制。或者相反
    - 在 HSTS 快取中使用了尾隨點，但在 URL 中*未*使用尾隨點。
    (CVE-2022-30115)

  - 惡意伺服器可在 HTTP 回應中提供過量的「Set-Cookie:」標頭，低於 7.84.0 版的 curl 會儲存所有這些標頭。數量足夠多 (大) 的 Cookie 會向此伺服器或與這些 Cookie 相符的其他伺服器發出後續 HTTP 要求，從而使建立的要求超過 curl 爲避免傳送過大要求 (1048576 位元組) 而在內部使用的閾值，而沒有傳回錯誤。只要保留和符合這些 Cookie 並且它們未過期，此拒絕狀態就可能持續存在。由於 Cookie 比對規則，「foo.example.com」上的伺服器可設定與「bar.example.com」相符的 Cookie，從而使同級伺服器可以有效造成相同二級網域上使用此方法的同級網站拒絕服務。(CVE-2022-32205)

  - curl 7.84.0 之前版本支援鏈結式 HTTP 壓縮演算法，這表示伺服器回應可被壓縮多次，並且可能使用不同的演算法。此解壓縮鏈中可接受的連結數不受限制，因此惡意伺服器可以插入幾乎不限數量的壓縮步驟。使用此類解壓縮鏈可導致 malloc 炸彈，使 curl 最終佔用大量已配置的堆積記憶體，或嘗試並傳回記憶體不足錯誤。(CVE-2022-32206)

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

  - curl 7.84.0 之前版本在執行受 krb5 保護的 FTP 傳輸時，會錯誤處理訊息驗證失敗。
    攻擊者可利用此缺陷執行攔截式攻擊而不被察覺，甚至可以向用戶端插入資料。(CVE-2022-32208)

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

  - 使用 curl 從 HTTP(S) 伺服器擷取和剖析 cookie 時，它會接受使用控製程式碼的 cookie，稍後將這些 cookie 傳回 HTTP 伺服器時，可能會使伺服器傳回 400 回應。
    有效地允許協助網站拒絕對所有同級網站的服務。(CVE-2022-35252)

  - 可指示 curl 剖析憑證的「.netrc」檔案。如果該檔案以包含 4095 個連續的非空白字母的行結尾且無新行，curl 會先讀取超出堆疊型緩衝區結尾的範圍，如果是 readworks，則寫入超出其邊界的零位元組。在大多數情況下，這會造成區段錯誤或類似問題，但也可能會造成不同的結果。如果惡意使用者可向應用程式提供自訂 netrc 檔案，或以其他方式影響其內容，則可利用此缺陷引致拒絕服務。(CVE-2022-35260)

  - curl 7.86.0 之前版本存在重複釋放問題。如果要求 curl 使用 HTTP Proxy 進行包含非 HTTP(S) URL 的傳輸，它會透過向 Proxy 發出 CONNECT 要求來設定與遠端伺服器的連線，然後讓其餘通訊協定通過。HTTP Proxy 可能會拒絕此要求 (HTTP Proxy 通常只允許至特定連接埠號碼的傳出連線，例如 HTTPS 的 443)，而是將非 200 狀態碼傳回給用戶端。由於錯誤/清理處理中存在錯誤，如果在傳輸的 URL 中使用下列配置之一，這可在 curl 中觸發重複釋放：dict、gopher、gophers、ldap、ldaps、rtmp、rtmps 或 telnet。最早的受影響版本是 7.77.0。(CVE-2022-42915)

  - 在 curl 7.86.0 之前版本中，使用者可以繞過 HSTS 檢查以誘騙其繼續使用 HTTP。若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 直接使用 HTTPS (而不使用不安全的純文字 HTTP 步驟)。如果指定 URL 中的主機名稱使用在 IDN 轉換過程中被 ASCII 對應項取代的 IDN 字元，則可繞過此機制，例如，使用字元 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP)，而非常見的 ASCII U+002E 的句號 (.)。
    最早的受影響版本是 7.77.0 2021-05-26。(CVE-2022-42916)

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

遠端 Ubuntu 18.04 LTS/20.04 LTS/21.10/22.04 LTS 主機上安裝的多個套件受到 USN-5412-1 公告中提及的多個弱點影響。

  - 即使已變更 TLS 或 SSH 相關選項，libcurl 仍會重複使用之前建立的連線，而這些連線本應禁止重複使用。若其中一個連線符合設定，libcurl 會將之前使用過的連線保留在連線集區中，以備後續傳送重複使用。但是，組態比對檢查會遺漏數個 TLS 和 SSH 設定，這使匹配變得非常容易。(CVE-2022-27782)

  - 解碼 URL 的主機名稱部分時，curl URL 剖析器會錯誤地接受以百分號編碼的 URL 分隔符號 (如「/」)，從而使其在以後擷取時成為使用錯誤主機名稱的 *不同* URL。例如，剖析器會允許諸如 `http://example.com%2F127.0.0.1/` 的 URL 並將其轉置為 `http://example.com/127.0.0.1/`。攻擊者可利用此瑕疵規避篩選、檢查等。
    (CVE-2022-27780)

  - libcurl 提供「CURLOPT_CERTINFO」選項，允許應用程式要求傳回有關伺服器憑證鏈的詳細資料。由於有錯誤的函式，惡意伺服器可造成使用 NSS 構建的 libcurl 在嘗試擷取該資訊時陷入無止境的忙碌迴圈。
    (CVE-2022-27781)

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

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

  - 當使用 `-t` 命令行選項 (在 libcurl 中稱為`CURLOPT_TELNETOPTIONS`) 傳送 variable=content 配對至 TELNET 伺服器時，curl 7.7 到 7.76.1 會受到資訊洩漏問題的影響。由於傳送 NEW_ENV 變數的選項剖析器中有一個缺陷，libcurl 可能會被用來將未初始化的資料從堆疊型緩衝區傳遞至伺服器，進而可能導致使用純文字網路通訊協定向伺服器洩漏敏感的內部資訊。(CVE-2021-22898)

  - libcurl 會將先前使用的連線保留在連線集區中，以便在後續傳輸時重複使用其中符合設定的某個連線。由於邏輯中的錯誤，組態比對函式未將「issuercert」納入考量，因此會比較所涉及的路徑*案例不敏感地*，這可導致 libcurl 重複使用錯誤的連線。檔案路徑在許多系統上可能是或可能是區分大小寫的，但並非全部都區分大小寫，而且可能會根據所使用的檔案系統而有所不同。比較也未包含「issuer cert」其中，傳輸可設定為符合驗證伺服器憑證的方式。(CVE-2021-22924)

  - 將資料傳送至 MQTT 伺服器時，libcurl <= 7.73.0 和 7.78.0 版在某些情況下可將指標錯誤地保留至已釋放的記憶體區域，並在後續呼叫中再次使用該指標來傳送資料，然後*再次*釋放 。(CVE-2021-22945)

  - 與 IMAP、POP3 或 FTP 伺服器交談時，使用者可告知 curl >= 7.20.0 和 <= 7.78.0 以要求成功升級至 TLS (命令行上的 `--ssl-reqd` 或設為 `CURLUSESSL_CONTROL` 的 `CURLOPT_USE_SSL` 或 `CURLUSESSL_ALL` withlibcurl)。如果伺服器會傳回特製但完全合法的回應，則可繞過此要求。此缺陷會導致 curl 以無訊息模式繼續其作業
    **沒有 TLS** 與指示和預期相反，可能透過網路以純文字洩漏敏感資料。(CVE-2021-22946)

  - 當 curl >= 7.20.0 和 <= 7.78.0 連線至 IMAP 或 POP3 伺服器以擷取使用 STARTTLS 升級至 TLS 安全性的資料時，伺服器可回應並一次傳回 curl 快取的多個回應。
    然後，curl 會升級至 TLS，但不會排清已快取回應的佇列，而是繼續使用並信任其在 TLS 交握*之前*收到的回應，如同這些回應已經通過驗證一般。藉此缺陷，中間攻擊者可先插入假的回應，然後從合法伺服器傳遞 TLS 流量，並誘騙 curl 將資料傳送回給認為攻擊者插入的資料來自受 TLS 保護之伺服器的使用者。(CVE-2021-22947)

  - curl 7.33.0 至 7.82.0 (含) 版本中有不當驗證弱點，可能允許在未正確確定已使用為此傳輸設定的相同憑證來驗證連線的情況下，重複使用 OAUTH2 驗證的代理伺服器連線。此弱點會影響已啟用 SASL 的通訊協定：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S) (僅限 openldap)。(CVE-2022-22576)

  - curl 4.9 至 7.82.0 版 (含) 存在憑證保護不足弱點，允許攻擊者在遵循身份驗證中結合使用的 HTTP(S) 重新導向時擷取憑證，將憑證洩漏給不同通訊協定或連接埠號碼上的其他服務。
    (CVE-2022-27774)

  - curl 7.65.0 至 7.82.0 中存在資訊洩漏弱點，在使用連線集區中具有不同區域 ID 的 IPv6 位址時，它可能會改為重複使用連線。(CVE-2022-27775)

  - curl 7.83.0 中修正的憑證保護不足弱點可能會在 HTTP 重新導向至相同主機不同連接埠號碼時洩漏驗證或 Cookie 標頭資料。(CVE-2022-27776)

  - libcurl 提供「CURLOPT_CERTINFO」選項，允許應用程式要求傳回有關伺服器憑證鏈的詳細資料。由於有錯誤的函式，惡意伺服器可造成使用 NSS 構建的 libcurl 在嘗試擷取該資訊時陷入無止境的忙碌迴圈。
    (CVE-2022-27781)

  - 即使已變更 TLS 或 SSH 相關選項，libcurl 仍會重複使用之前建立的連線，而這些連線本應禁止重複使用。若其中一個連線符合設定，libcurl 會將之前使用過的連線保留在連線集區中，以備後續傳送重複使用。但是，組態比對檢查會遺漏數個 TLS 和 SSH 設定，這使匹配變得非常容易。(CVE-2022-27782)

  - 惡意伺服器可在 HTTP 回應中提供過量的「Set-Cookie:」標頭，低於 7.84.0 版的 curl 會儲存所有這些標頭。數量足夠多 (大) 的 Cookie 會向此伺服器或與這些 Cookie 相符的其他伺服器發出後續 HTTP 要求，從而使建立的要求超過 curl 爲避免傳送過大要求 (1048576 位元組) 而在內部使用的閾值，而沒有傳回錯誤。只要保留和符合這些 Cookie 並且它們未過期，此拒絕狀態就可能持續存在。由於 Cookie 比對規則，「foo.example.com」上的伺服器可設定與「bar.example.com」相符的 Cookie，從而使同級伺服器可以有效造成相同二級網域上使用此方法的同級網站拒絕服務。(CVE-2022-32205)

  - curl 7.84.0 之前版本支援鏈結式 HTTP 壓縮演算法，這表示伺服器回應可被壓縮多次，並且可能使用不同的演算法。此解壓縮鏈中可接受的連結數不受限制，因此惡意伺服器可以插入幾乎不限數量的壓縮步驟。使用此類解壓縮鏈可導致 malloc 炸彈，使 curl 最終佔用大量已配置的堆積記憶體，或嘗試並傳回記憶體不足錯誤。(CVE-2022-32206)

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

  - curl 7.84.0 之前版本在執行受 krb5 保護的 FTP 傳輸時，會錯誤處理訊息驗證失敗。
    攻擊者可利用此缺陷執行攔截式攻擊而不被察覺，甚至可以向用戶端插入資料。(CVE-2022-32208)

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

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

  - c_rehash 指令碼未正確清理殼層中繼字元以防止命令插入。某些作業系統會以自動執行的方式發佈此指令碼。在這類作業系統上，攻擊者可以透過指令碼的權限執行任意命令。c_rehash 指令碼的使用已過時，應由 OpenSSL rehash 命令列工具取代。
    已在 OpenSSL 3.0.3 中修正 (受影響的是 3.0.0、3.0.1、3.0.2)。已在 OpenSSL 1.1.1o 中修正 (受影響的是 1.1.1-1.1.1n)。
    已在 OpenSSL 1.0.2ze 中修正 (受影響的是 1.0.2-1.0.2zd)。(CVE-2022-1292)

  - 除了 CVE-2022-1292 中發現的 c_rehash shell 命令插入，程式碼審查還發現 c_rehash 指令碼未正確清理 shell 中繼字元以防止命令插入的其他情況。修正 CVE-2022-1292 後，未在指令碼中的其他位置發現雜湊憑證的檔案名稱可能會傳遞至透過 shell 執行的命令。某些作業系統會以自動執行的方式發佈此指令碼。在這類作業系統上，攻擊者可以透過指令碼的權限執行任意命令。c_rehash 指令碼的使用已過時，應由 OpenSSL rehash 命令列工具取代。已在 OpenSSL 3.0.4 中修正 (受影響的是 3.0.0、3.0.1、3.0.2、3.0.3)。已在 OpenSSL 1.1.1p 中修正 (受影響的是 1.1.1-1.1.1o)。已在 OpenSSL 1.0.2zf 中修正 (受影響的是 1.0.2-1.0.2ze)。(CVE-2022-2068)

  - 如果在 32 位元系統上將 LimitXMLRequestBody 設定為允許大於 350MB (預設為 1M) 的要求內文，則會造成整數溢位，進而導致越界寫入。此問題會影響 Apache HTTP Server 2.4.52 以及更早的版本。CVE-2022-22721

  - Apache HTTP Server 的 mod_sed 中的超出邊界寫入弱點允許攻擊者使用可能由攻擊者提供的資料覆寫堆積記憶體。此問題會影響 Apache HTTP Server 2.4 2.4.52 及更舊版本。(CVE-2022-23943)

  - Apache HTTP Server 的 mod_proxy_ajp 中存在對 HTTP 要求解釋不一致 (「HTTP 要求走私」) 弱點，攻擊者可藉此將要求走私到其轉送要求的 AJP 伺服器。此問題會影響 Apache HTTP Server 2.4、2.4.53 以及更舊版本。
    (CVE-2022-26377)

  - libcurl 提供「CURLOPT_CERTINFO」選項，允許應用程式要求傳回有關伺服器憑證鏈的詳細資料。由於有錯誤的函式，惡意伺服器可造成使用 NSS 構建的 libcurl 在嘗試擷取該資訊時陷入無止境的忙碌迴圈。
    (CVE-2022-27781)

  - 在 Apache HTTP Server 2.4.53 及更早版本中，若攻擊者能夠使用 ap_rwrite() 或 ap_rputs() (例如使用 mod_luas r:puts() 函式 ) 讓伺服器反映超大型輸入，則 ap_rwrite() 函式可能會讀取非預期的記憶體。從使用「ap_rputs」函式的 Apache HTTP Server 分別編譯和發佈的模組，必須針對目前的標頭編譯非常大 (INT_MAX 或更大) 的字串，才能解決此問題。(CVE-2022-28614)

  在 Apache HTTP Server 2.4.53 和更舊版本中，當應用程式處理超大型輸入緩衝區時，ap_strcmp_match() 中的超出邊界讀取弱點可能會造成應用程式損毀或資訊洩漏。雖然無法將隨伺服器發布的程式碼強制轉換為此類呼叫，但使用 ap_strcmp_match() 的第三方模組或 lua 指令碼可能會受到影響。(CVE-2022-28615)

  - 如果將 Apache HTTP Server 2.4.53 設定為在 mod_sed 的輸入可能非常大的環境中使用 mod_sed 進行轉換，則 mod_sed 可能會進行超大記憶體配置並觸發中止。
    (CVE-2022-30522)

  - Apache HTTP Server 2.4.53 及更舊版本可能不會根據用戶端的 Connection 標頭逐跳機制將 X-Forwarded-* 標頭傳送至原始伺服器。攻擊者可利用此問題繞過原始伺服器/應用程式上的 IP 型驗證。(CVE-2022-31813)

  - curl 7.84.0 之前版本支援鏈結式 HTTP 壓縮演算法，這表示伺服器回應可被壓縮多次，並且可能使用不同的演算法。此解壓縮鏈中可接受的連結數不受限制，因此惡意伺服器可以插入幾乎不限數量的壓縮步驟。使用此類解壓縮鏈可導致 malloc 炸彈，使 curl 最終佔用大量已配置的堆積記憶體，或嘗試並傳回記憶體不足錯誤。(CVE-2022-32206)

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

  - curl 7.84.0 之前版本在執行受 krb5 保護的 FTP 傳輸時，會錯誤處理訊息驗證失敗。
    攻擊者可利用此缺陷執行攔截式攻擊而不被察覺，甚至可以向用戶端插入資料。(CVE-2022-32208)

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

  - 使用 curl 從 HTTP(S) 伺服器擷取和剖析 cookie 時，它會接受使用控製程式碼的 cookie，稍後將這些 cookie 傳回 HTTP 伺服器時，可能會使伺服器傳回 400 回應。
    有效地允許協助網站拒絕對所有同級網站的服務。(CVE-2022-35252)

  - curl 7.86.0 之前版本存在重複釋放問題。如果要求 curl 使用 HTTP Proxy 進行包含非 HTTP(S) URL 的傳輸，它會透過向 Proxy 發出 CONNECT 要求來設定與遠端伺服器的連線，然後讓其餘通訊協定通過。HTTP Proxy 可能會拒絕此要求 (HTTP Proxy 通常只允許至特定連接埠號碼的傳出連線，例如 HTTPS 的 443)，而是將非 200 狀態碼傳回給用戶端。由於錯誤/清理處理中存在錯誤，如果在傳輸的 URL 中使用下列配置之一，這可在 curl 中觸發重複釋放：dict、gopher、gophers、ldap、ldaps、rtmp、rtmps 或 telnet。最早的受影響版本是 7.77.0。(CVE-2022-42915)

  - 在 curl 7.86.0 之前版本中，使用者可以繞過 HSTS 檢查以誘騙其繼續使用 HTTP。若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 直接使用 HTTPS (而不使用不安全的純文字 HTTP 步驟)。如果指定 URL 中的主機名稱使用在 IDN 轉換過程中被 ASCII 對應項取代的 IDN 字元，則可繞過此機制，例如，使用字元 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP)，而非常見的 ASCII U+002E 的句號 (.)。
    最早的受影響版本是 7.77.0 2021-05-26。(CVE-2022-42916)

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

因此，它受到 ALAS2-2023-1924 公告中所提及的多個弱點影響。

  - libcurl 提供「CURLOPT_CERTINFO」選項，允許應用程式要求傳回有關伺服器憑證鏈的詳細資料。由於有錯誤的函式，惡意伺服器可造成使用 NSS 構建的 libcurl 在嘗試擷取該資訊時陷入無止境的忙碌迴圈。
    (CVE-2022-27781)

  - 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)

  - 在 curl 中發現一個弱點。此問題是由錯誤的函式所導致。嘗試擷取該資訊時，惡意伺服器可使 Network Security Services (NSS) 中的 curl 陷入永無止境的忙碌迴圈。此缺陷允許發生無限迴圈，進而影響系統可用性。
    (CVE-2022-27781) (CVE-2022-43552)

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

因此，它受到 ALAS2023-2023-083 公告中所提及的多個弱點影響。

  - curl 7.33.0 至 7.82.0 (含) 版本中有不當驗證弱點，可能允許在未正確確定已使用為此傳輸設定的相同憑證來驗證連線的情況下，重複使用 OAUTH2 驗證的代理伺服器連線。此弱點會影響已啟用 SASL 的通訊協定：SMPTP(S)、IMAP(S)、POP3(S) 和 LDAP(S) (僅限 openldap)。(CVE-2022-22576)

  - curl 4.9 至 7.82.0 版 (含) 存在憑證保護不足弱點，允許攻擊者在遵循身份驗證中結合使用的 HTTP(S) 重新導向時擷取憑證，將憑證洩漏給不同通訊協定或連接埠號碼上的其他服務。
    (CVE-2022-27774)

  - curl 7.65.0 至 7.82.0 中存在資訊洩漏弱點，在使用連線集區中具有不同區域 ID 的 IPv6 位址時，它可能會改為重複使用連線。(CVE-2022-27775)

  - curl 7.83.0 中修正的憑證保護不足弱點可能會在 HTTP 重新導向至相同主機不同連接埠號碼時洩漏驗證或 Cookie 標頭資料。(CVE-2022-27776)

  - 如果主機名稱以一個點結尾，libcurl 會錯誤地允許為頂層網域 (TLD) 設定 cookie。可以指示 curl 接收和傳送 cookie。構建 curl 的 cookie 引擎時，可以使用 [公開後置詞清單]，也可以不使用 (https://publicsuffix.org/)awareness。如果未提供 PSL 支援，則需要基本檢查，以至少防止在 TLD 上設定 cookie。如果 URL 中的主機名稱以一個點結尾，此檢查會被中斷。這可造成任意網站皆可設定 cookie，然後傳送至不同且不相關的網站或網域。(CVE-2022-27779)

  - 解碼 URL 的主機名稱部分時，curl URL 剖析器會錯誤地接受以百分號編碼的 URL 分隔符號 (如「/」)，從而使其在以後擷取時成為使用錯誤主機名稱的 *不同* URL。例如，剖析器會允許諸如 `http://example.com%2F127.0.0.1/` 的 URL 並將其轉置為 `http://example.com/127.0.0.1/`。攻擊者可利用此瑕疵規避篩選、檢查等。
    (CVE-2022-27780)

  - libcurl 提供「CURLOPT_CERTINFO」選項，允許應用程式要求傳回有關伺服器憑證鏈的詳細資料。由於有錯誤的函式，惡意伺服器可造成使用 NSS 構建的 libcurl 在嘗試擷取該資訊時陷入無止境的忙碌迴圈。
    (CVE-2022-27781)

  - 即使已變更 TLS 或 SSH 相關選項，libcurl 仍會重複使用之前建立的連線，而這些連線本應禁止重複使用。若其中一個連線符合設定，libcurl 會將之前使用過的連線保留在連線集區中，以備後續傳送重複使用。但是，組態比對檢查會遺漏數個 TLS 和 SSH 設定，這使匹配變得非常容易。(CVE-2022-27782)

  - 若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 直接使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。如果在指定的 URL 中，主機名稱使用了尾隨點，但在構建 HSTS 快取時未使用，則可繞過此機制。或者相反
    - 在 HSTS 快取中使用了尾隨點，但在 URL 中*未*使用尾隨點。
    (CVE-2022-30115)

  - 惡意伺服器可在 HTTP 回應中提供過量的「Set-Cookie:」標頭，使得 curl 7.84.0 及更低版本儲存所有標頭。數量足夠多 (大) 的 Cookie 會向此伺服器或與這些 Cookie 相符的其他伺服器發出後續 HTTP 要求，從而使建立的要求超過 curl 爲避免傳送過大要求 (1048576 位元組) 而在內部使用的閾值，而沒有傳回錯誤。只要保留和符合這些 Cookie 並且它們未過期，此拒絕狀態就可能持續存在。由於 Cookie 比對規則，「foo.example.com」上的伺服器可設定與「bar.example.com」相符的 Cookie，從而使同級伺服器可以有效造成相同二級網域上使用此方法的同級網站拒絕服務。(CVE-2022-32205)

  - curl 7.84.0 之前版本支援鏈結式 HTTP 壓縮演算法，這表示伺服器回應可被壓縮多次，並且可能使用不同的演算法。此解壓縮鏈中可接受的連結數不受限制，因此惡意伺服器可以插入幾乎不限數量的壓縮步驟。使用此類解壓縮鏈可導致 malloc 炸彈，使 curl 最終佔用大量已配置的堆積記憶體，或嘗試並傳回記憶體不足錯誤。(CVE-2022-32206)

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

  - curl 7.84.0 之前版本在執行受 krb5 保護的 FTP 傳輸時，會錯誤處理訊息驗證失敗。
    攻擊者可利用此缺陷執行攔截式攻擊而不被察覺，甚至可以向用戶端插入資料。(CVE-2022-32208)

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

  - 使用 curl 從 HTTP(S) 伺服器擷取和剖析 cookie 時，它會接受使用控製程式碼的 cookie，稍後將這些 cookie 傳回 HTTP 伺服器時，可能會使伺服器傳回 400 回應。
    有效地允許協助網站拒絕對所有同級網站的服務。(CVE-2022-35252)

  - 可指示 curl 剖析憑證的「.netrc」檔案。如果該檔案以包含 4095 個連續的非空白字母的行結尾且無新行，curl 會先讀取超出堆疊型緩衝區結尾的範圍，如果是 readworks，則寫入超出其邊界的零位元組。在大多數情況下，這會造成區段錯誤或類似問題，但也可能會造成不同的結果。如果惡意使用者可向應用程式提供自訂 netrc 檔案，或以其他方式影響其內容，則可利用此缺陷引致拒絕服務。(CVE-2022-35260)

  - curl 7.86.0 之前版本存在重複釋放問題。如果要求 curl 使用 HTTP Proxy 進行包含非 HTTP(S) URL 的傳輸，它會透過向 Proxy 發出 CONNECT 要求來設定與遠端伺服器的連線，然後讓其餘通訊協定通過。HTTP Proxy 可能會拒絕此要求 (HTTP Proxy 通常只允許至特定連接埠號碼的傳出連線，例如 HTTPS 的 443)，而是將非 200 狀態碼傳回給用戶端。由於錯誤/清理處理中存在錯誤，如果在傳輸的 URL 中使用下列配置之一，這可在 curl 中觸發重複釋放：dict、gopher、gophers、ldap、ldaps、rtmp、rtmps 或 telnet。最早的受影響版本是 7.77.0。(CVE-2022-42915)

  - 在 curl 7.86.0 之前版本中，使用者可以繞過 HSTS 檢查以誘騙其繼續使用 HTTP。若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 直接使用 HTTPS (而不使用不安全的純文字 HTTP 步驟)。如果指定 URL 中的主機名稱使用在 IDN 轉換過程中被 ASCII 對應項取代的 IDN 字元，則可繞過此機制，例如，使用字元 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP)，而非常見的 ASCII U+002E 的句號 (.)。
    最早的受影響版本是 7.77.0 2021-05-26。(CVE-2022-42916)

  - 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)

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
164482	Debian DLA-3085-1：curl - LTS 安全性更新	Nessus	Debian Local Security Checks	2022/8/29	2023/10/13	high
168600	Amazon Linux AMI：curl (ALAS-2022-1646)	Nessus	Amazon Linux Local Security Checks	2022/12/10	2023/9/15	high
177842	Nessus Network Monitor < 6.2.2 多個弱點 (TNS-2023-23)	Nessus	Misc.	2023/6/30	2023/7/6	critical
162691	Ubuntu 16.04 ESM：curl 弱點 (USN-5499-1)	Nessus	Ubuntu Local Security Checks	2022/7/1	2023/7/10	medium
161057	Slackware Linux 14.0/14.1/14.2/15.0/最新版 curl 多個弱點 (SSA:2022-131-01)	Nessus	Slackware Local Security Checks	2022/5/11	2023/10/27	high
168911	GLSA-202212-01 : curl：多個弱點	Nessus	Gentoo Local Security Checks	2022/12/18	2023/9/12	critical
161058	Ubuntu 18.04 LTS / 20.04 LTS / 22.04 LTS：curl 弱點 (USN-5412-1)	Nessus	Ubuntu Local Security Checks	2022/5/11	2023/10/16	high
163681	Debian DSA-5197-1：curl - 安全性更新	Nessus	Debian Local Security Checks	2022/8/2	2023/10/17	critical
168498	RHEL 7/8：Red Hat JBoss Core Services Apache HTTP Server 2.4.51 SP1 (RHSA-2022: 8840)	Nessus	Red Hat Local Security Checks	2022/12/8	2024/4/28	critical
171046	Amazon Linux 2：(ALAS-2023-1924)	Nessus	Amazon Linux Local Security Checks	2023/2/6	2023/9/5	high
173171	Amazon Linux 2023：curl、curl-minimal、libcurl (ALAS2023-2023-083)	Nessus	Amazon Linux Local Security Checks	2023/3/21	2024/2/20	critical

偵測

搜尋 Plugin

high

high

critical

medium

high

critical

high

critical

critical

high

critical