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

    當應用程式透過 CURLOPT_STREAM_DEPENDS 或 CURLOPT_STREAM_DEPENDS_E 設定 HTTP/2 資料流相依性樹狀結構，隨後叫用 curl_easy_reset（），最後以 curl_easy_cleanup（） 終止控制碼時，libcurl 中就存在釋放後使用弱點。在此最後清除階段，libcurl 會嘗試存取及修改在重設作業期間已釋放的內部結構。（CVE-2026-10536）

    根據預設，curl 會自動回應 WebSocket PING 框架。由於 curl 對於未確認的幀缺乏記憶體配置上限約束，惡意伺服器透過向 curl 快速連續傳送大量 PING 訊息，來耗盡所有可用的記憶體。(CVE-2026-11586)

    成功使用 libcurl 透過摘要驗證傳輸至特定 HTTP 來源 （hostA），然後將來源變更為不同的來源 （hostB） 進行第二次傳輸，重複使用相同的控制碼，會使 libcurl 錯誤地將適用於 hostA 的 Authorization： 標頭欄位傳遞給 hostB。（CVE-2026-11856）

    當使用者使用結合 sftp （或 scp） 的無配置 URL --proto-default 叫用 curl 時，工具層和 libcurl 之間會發生中斷連線。工具層錯誤地推斷了 URL 配置，這錯誤地繞過了關鍵 SSH 安全選項的初始化，例如 CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256 和 CURLOPT_SSH_KNOWNHOSTS。相反地，libcurl 執行階段會成功接受CURLOPT_DEFAULT_PROTOCOL，並依照指定透過 SFTP/SCP 建立連線。
    由於工具層略過安全性設定，因此會默默省略這些 SSH 主機驗證選項，導致 curl 連線至未經驗證的 SSH 遠端主機，而不會擲回錯誤。
    (CVE-2026-12064)

    存在弱點，其中使用 STARTTLS 升級連線的新傳輸可能會重複使用現有的即時連線，即使 TLS 組態不相符，因此不應重複使用。CVE-2026-8286

    在某些情況下，當要求執行交涉驗證的連線時，libcurl 可能會重複使用錯誤的連線，即使它們設定為使用不同的服務也是如此。

    libcurl 具有最近連線集區，以便後續請求可以重複使用現有連線以避免額外負荷。

    重複使用連線時，必須符合一系列準則。由於程式碼中的邏輯錯誤，應用程式發出的要求可能會錯誤地重複使用與使用不同服務驗證之相同伺服器的現有連線。（CVE-2026-8458）

    curl 的 cookie 剖析邏輯中的一個缺陷允許惡意 HTTP 伺服器設定繞過公用尾碼清單檢查的超級 cookie。這可讓攻擊者控制的來源插入 Cookie，而 Curl 隨後會將這些 Cookie 限定在特定範圍內並傳輸至不相關的第三方網域。(CVE-2026-8924)

    與 SASL 驗證搭配使用的 curl 邏輯最終可能會清理 GSASL 內容兩次，而不清除中間的指標，使其成為 free（） 相同的指標兩次。（CVE-2026-8925）

    當要求 curl 使用 .netrc 檔案來尋找憑證，同時指定具有使用者名稱 （不含密碼） 的 URL 時， https://user@example.com/如果存在該主機的 .netrc 檔案中設定的另一個使用者，則 curl 可能會錯誤地取得並使用該主機的 .netrc 檔案中設定的另一個使用者的密碼，且指定的使用者沒有相符項。（CVE-2026-8926）

    將 libcurl 控點重複用於由環境變數 Proxy 組態驅動的循序傳輸時，libcurl 無法清除要求之間的 Proxy 驗證狀態。具體而言，如果初始傳輸使用摘要驗證對 proxyA 進行驗證，則透過 proxyB 路由的後續傳輸會錯誤地洩漏僅供 proxyA 使用的 Proxy-Authorization： 標頭。（CVE-2026-8927）

    libcurl 會重複使用先前建立的連線，即使某些 mTLS 組態相關選項已變更而本應禁止重複使用。

    libcurl 會將先前使用的連線保留在連線集區中，以便在其中一個連線符合設定時重複使用後續傳輸。但是，某些與用戶端憑證相關的 TLS 設定被遺漏在組態相符檢查中，因此它們太容易相符。特別是與私鑰相關的選項。（CVE-2026-8932）

    libcurl 有一個缺陷，當被指示清除代理身份驗證憑據時，它不會這樣做，留下舊憑據用於不應知道或使用它們的後續傳輸。
    (CVE-2026-9079)

    在事件型 CURLMOPT_SOCKETFUNCTION 回呼中呼叫 curl_easy_pause（） 會觸發釋放後使用弱點，其中 libcurl 會在釋放該指標的記憶體後立即嘗試使用懸空結構指標來儲存旗標。（CVE-2026-9080）

    在此案例中，libcurl 會先使用適當的 HTTP/3 伺服器進行初始傳輸，然後當它第二次傳輸到相同網站時，它已被攻擊者的冒名頂替者機器取代 - 沒有有效的憑證。

    當 libcurl 第二次以快取的 SSL 工作階段 （未停用 CURLOPT_SSL_SESSIONID_CACHE） 且啟用早期資料 （CURLSSLOPT_EARLYDATA位設定在 CURLOPT_SSL_OPTIONS 中） 時，libcurl 可能會在強制執行憑證驗證失敗之前，在該新連線上傳送第二個要求的位元組。可能洩露敏感資訊。（CVE-2026-9545）

    當 libcurl 型應用程式透過 SCP:// 或 SFTP:// 執行傳輸並利用 CURLOPT_SSH_KEYFUNCTION 回呼時，它可能會以無訊息方式接受不受信任的伺服器。當伺服器提供的主機金鑰類型與known_hosts檔案中已針對該主機記錄的特定金鑰類型不符時，就會發生此弱點。回呼機制沒有拒絕不相符，而是無法正確執行限制，導致連線在沒有警告的情況下成功，並面臨潛在的中間人攻擊的風險。（CVE-2026-9547）

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

偵測

Amazon Linux 2023：curl、curl-minimal、libcurl (ALAS2023-2026-2132)

critical Nessus Plugin ID 345801

版本 1.1