觀點 · 資訊分享

curl 8.21.0 一次公開 18 個漏洞:4 個中等、14 個低風險,重複使用連線可能外洩驗證資訊

curl 在 6 月 24 日釋出 8.21.0,同時公告 18 個 CVE,其中 4 個是中等嚴重度。重點是 libcurl 重複使用同一個連線物件、中途換網站或代理時,可能把舊的驗證資訊帶給新對象。

發布
2026-06-24
篇幅
約 5 分鐘 · 2,241 字
結構
8 節 + 4 題常見問題
標籤
#curl#libcurl#CVE#資安漏洞
curl 8.21.0 一次公開 18 個漏洞:4 個中等、14 個低風險,重複使用連線可能外洩驗證資訊

一句話看懂:curl 在 6 月 24 日釋出 8.21.0,同時公開 18 個漏洞,其中 4 個是中等嚴重度;最值得注意的是,重複使用同一個 libcurl 連線物件、中途換網站或代理時,舊的驗證資訊可能被帶給新對象。

curl 8.21.0 一次公開 18 個 CVE資訊圖卡:4 個中等、14 個低風險;重點是換對象時帶走舊驗證

先用白話講:這些漏洞怎麼發生?

想像你是一位快遞員,用同一個手提袋裝文件。去 A 公司送件時,你拿了一張「A 公司簽收單」放進袋子。送完 A 後,你直接去 B 公司,卻忘了把簽收單拿出來,B 公司就看到了 A 的簽收單。對方不能用它做太多事,但能拿去重送「那一次」的請求。

curl 是傳輸資料的命令列工具,libcurl 是它的函式庫,被許多軟體內嵌,但常常沒有標示。這次最典型的問題就是「提袋沒清乾淨」。

發生什麼事

curl 專案的維護者在 6 月 24 日釋出 8.21.0,同時用一封信列出 18 個新漏洞,並附上每個漏洞的說明頁。18 個裡有 4 個中等、14 個低風險,沒有高風險。

4 個中等嚴重度

CVE 白話說明 影響版本
CVE-2026-11856 先用 Digest 驗證連到網站 A,再用同一個控制代碼連到網站 B,A 的驗證標頭被帶給 B 7.10.6 到 8.20.0
CVE-2026-8927 同樣的情況,但發生在透過環境變數設定的代理之間,A 代理的驗證標頭被帶給 B 代理 7.12.0 到 8.20.0
CVE-2026-9079 要求清除代理驗證資訊,卻沒有真的清掉,舊的帳密被後續請求繼續使用 8.8.0 到 8.20.0
CVE-2026-8925 SASL 驗證的程式碼可能把同一塊記憶體釋放兩次;用 IMAP、POP3、SMTP 並且編譯時使用 libgsasl 才會碰到 8.15.0 到 8.20.0

前三個官方說明不影響 curl 命令列工具,只影響程式呼叫 libcurl 並重複使用控制代碼的情境;第四個命令列工具也受影響。官方對第四個的評估是:要精準控制被釋放的記憶體很難,但無法完全排除被惡意利用的可能。

另外 14 個低風險

我只讀了上面 4 個的完整說明,其餘 14 個只看到官方公告信列出的標題:連線重用判斷錯誤(STARTTLS、不同服務、mTLS 設定)、結尾有點的網域造成超級 Cookie、使用 netrc 與網址內帳號時的密碼外洩、暫停後使用已釋放記憶體、HTTP/3 早期資料暴露、送出舊的 Referer、SSH 主機驗證不當(兩個)、HTTP/2 串流依賴樹的記憶體問題、QUIC 長度為零的封包造成忙迴圈、原生 CA 信任殘留、WebSocket 自動 PONG 的記憶體耗盡。細節請看各自的說明頁。

給開發者的技術細節

  • 版本:用 curl --version 檢查。官方列出 8.14 系列(8.14.2 起)、8.16 系列(8.16.1 起)、8.20 系列(8.20.1 起)也有各自的修正版,因版本而異,詳見各 CVE 頁面
  • 建議做法(官方排序):升級到 8.21.0;或套用修補後自行編譯;暫時無法升級的話,在換網站或換代理時,避免重複使用同一個控制代碼
  • 8.21.0 的其他改動:新增 HTTP/3 的代理 CONNECT 與 MASQUE CONNECT-UDP 支援(ngtcp2 QUIC)、移除 HTTP/2 串流依賴追蹤、不再支援 CURLAUTH_DIGEST_IE、libssh 後端支援 SHA256 主機公鑰等
  • 要升級的不只是 curl:內嵌 libcurl 的軟體、容器映像與發行版套件,也要等它們自己更新

我的看法

看到「18 個」很嚇人,但仔細看,其實只有 4 個中等、沒有高風險,而且多數有前提條件。我會把它分成三種人:

  • 只用命令列 curl 抓東西的人,更新到新版就好,不必緊張
  • 自己寫程式呼叫 libcurl,或用 PHP、Python 等語言綁定、又會在同一個連線物件上換對象的人,要優先檢查程式裡有沒有這種用法
  • 維護容器映像或自架服務的人,要確認基底映像有沒有更新 curl 與 libcurl

另外也提醒:每個漏洞的細節,都值得看一眼,因為裡面常常寫著「怎麼避免」的做法,例如這次的「換對象時不要重用控制代碼」,這是不升級也能先做的緩解。

名詞小辭典

  • libcurl:curl 背後的函式庫,許多軟體內嵌它來做網路請求。
  • 控制代碼(Handle):libcurl 裡代表一組傳輸設定的物件,可被重複使用以加快連線。
  • Digest 驗證:一種 HTTP 驗證方式,不直接送密碼,而是送由密碼算出的雜湊值。
  • CVE:公開漏洞的統一編號,方便大家用同一個代號討論同一個問題。

資料來源

常見問題

curl 和 libcurl 是什麼?
curl 是傳輸資料的命令列工具,libcurl 是它背後的函式庫,許多軟體會把 libcurl 內嵌進去做網路請求,但不一定會標示出來,所以影響範圍比你想的廣。
我用 curl 命令列需要擔心嗎?
官方說明,其中三個與重複使用 libcurl 控制代碼有關的中等漏洞(CVE-2026-8927、CVE-2026-9079、CVE-2026-11856)不影響 curl 命令列工具。SASL 二次釋放(CVE-2026-8925)則命令列工具也受影響,但要用 IMAP、POP3 或 SMTP,並且編譯時用了 libgsasl。
「重複使用控制代碼」是什麼意思?
程式用同一個 libcurl 連線物件,先連到 A 網站、再連到 B 網站(或換成別的代理)。舊版在換對象時沒有清乾淨 A 的驗證狀態,可能把原本只給 A 的驗證標頭送給 B。
被偷走的驗證標頭有多危險?
官方的說明是,這類標頭含有已驗證的狀態,惡意的 B 可以拿來重送「那一個特定請求」,但看不到原始帳號密碼,也沒有資訊透露 A 是誰,所以評為中等。
作者

韓滷 · 全端系統工程師

接案做系統開發、網站與主機託管。觀點裡的文章都是我自己寫的,寫的是做專案時第一手遇到的事。

LINE