curl HTTP/2 上傳 UAF 被證明可轉成 RCE
daniel.haxx.se · 2026-10-14
curl 8.12.0 至 8.22.0 在上傳途中收到伺服器的 HTTP/2 RST_STREAM 時，會釋放仍在使用的 struct Curl_easy，形成 use-after-free，而且在嚴苛條件下已被證實能轉成遠端程式碼執行。
漏洞編號為 CVE-2026-92392，curl 官方公告於 2026-10-14 與 curl 8.23.0 同日發布，嚴重度評為 High，弱點類別 CWE-416。
漏洞機制
公告指出，觸發點是上傳期間伺服器送來原因為 HTTP_1_1_REQUIRED 或 REFUSED_STREAM 的 RST_STREAM。curl 拆掉這條傳輸，卻留下一個指向 easy handle 的懸空指標，連線本身仍保持開啟。
Daniel Stenberg 在部落格描述的攻擊流程是：惡意伺服器先把 HTTP/2 視窗大小歸零以暫停上傳，回一個不完整的回應，再重置 stream。應用程式接著釋放 easy handle 並清理 multi handle，之後 libcurl 為下載資料配置的記憶體剛好重用那塊已釋放的空間，懸空指標便讓下載內容寫進去。
從 UAF 到 RCE 靠兩步：這次請求會洩漏本機位址資訊，幫助繞過 ASLR；之後 libcurl 使用過期的 handle 並呼叫一個已被下載資料覆寫的函式指標。
原本的問題
根源是 curl 內部用原始指標指向 handle，而 handle 的釋放權在應用程式手上。stream 被伺服器重置後，指標沒有一併失效，這個缺陷從 8.12.0 一路留到 8.22.0。
為什麼實際風險有限
文章列出的前提很多：受害者必須對一台持有有效憑證的惡意伺服器發起上傳，上傳量約 135KB，攻擊者要知道 curl 的建置與記憶體配置細節。配置順序會隨發行版、libc、憑證套件與應用程式而變，nghttp2 與 OpenSSL 的 TLS 1.3 session ticket 行為也會影響結果。公告另提到需要兩條時機精準的平行傳輸。
可放進 payload 的空間只有約 23 位元組。Daniel 的評估是最可能的結果只是當機，成功攻擊的機率「slim」。
受影響版本
- 受影響：curl
8.12.0至8.22.0，含 curl 命令列工具，不只 libcurl。 - 不受影響：
8.12.0之前的版本、8.23.0以後，以及維護分支8.20.2+、8.16.2+、8.14.3+。 - 引入的 commit 為
cd9107e0128191b7b5396b，修補的 commit 為8b0744af5b1b631da5b938ca31c，修補者為 Stefan Eissing。
修補與緩解
公告給的緩解有三項：升級到 8.23.0、把修補套用到自己維護的版本，或在升級前避免使用 HTTP/2。內嵌 libcurl 的產品與靜態連結 curl 的容器映像不會因系統套件更新而自動修好，要自行確認內含版本是否落在 8.12.0 至 8.22.0。
除了這個點修補，curl 也在減少內部指向 handle 的指標，改存傳輸識別碼並在需要時查表。Daniel 說這會稍慢，但對邏輯錯誤更穩，同時會增加測試與分析器；他也強調這不保證未來不再有 UAF。
curl --version # 看 libcurl 版本
# 升級前的暫時繞路依公告：避免使用 HTTP/2發現過程
回報者是 Anthropic 的 Luna，公告署名「Luna with Claude」，Daniel 說她使用的是 Anthropic 的新 OSS Scanner。回報於 2026-09-15 送到 curl，HackerOne 報告見連結，安全團隊數小時內確認。8.23.0 發布文列出本版修了 24 個漏洞，Daniel 為此把發布週期從八週縮短為六週。
Daniel 同時重申 curl 不會改寫成 Rust 或其他語言，理由是 libcurl 支援的平台與架構遠多於 Rust 所能涵蓋的範圍。公告本身則把這個漏洞稱為「C mistake」，認為在記憶體安全語言中大概不會發生。