curl 8.22 強化 HTTP/3 代理的異常回應標頭順序處理
curl 8.22.0 於 2026 年 9 月 2 日發布，其中一項防禦性 HTTP/3 代理修正是：一般回應標頭在 :status 之前抵達時，不再觸發空指標解參照。對評估實驗性 HTTP/3 代理路徑的團隊而言，異常回應應成為可控協定錯誤，而不是終止整個用戶端程序。
curl 專案說明，HTTP/3 代理回呼只有看到 :status 虛擬標頭後才建立隧道回應物件。若其他標頭欄位先到，舊路徑會透過尚不存在的物件保存欄位，造成空指標解參照。修正會在使用物件前先檢查。
為什麼此順序不正常
HTTP/3 回應必須包含 :status，而且虛擬標頭應先於一般標頭。合規對端不應產生暴露此路徑的順序，但用戶端仍須防禦異常輸入、錯誤中介、底層函式庫異常或模糊測試產生的邊界序列。
專案討論認為正常協定下此情況偏理論性，但仍值得防禦。問題由直接驅動 HTTP/3 代理回呼的 libFuzzer 測試發現。罕見路徑若位於程序崩潰邊界，就應納入升級驗證。
準確限定影響範圍
此修正針對 HTTP/3 代理回應處理，不是所有 HTTP/3 故障、一般 HTTP CONNECT、目標網站 HTTP/3 或異常標頭的通用修正。
測試前要確認每一跳：用戶端到代理是否為 HTTP/3、代理層執行哪種 CONNECT、隧道內流量如何傳遞、目標最終協商何種協定。目標使用 HTTP/3 不代表代理跳也是 HTTP/3；QUIC 連線成功也不代表代理回應解析正確。
哪些團隊應優先回歸
優先檢查使用 curl/libcurl 8.21.0 或更早版本並啟用 HTTP/3 代理功能的應用程式，尤其是自訂建置、實驗性代理設定、模糊測試用戶端，以及單一程序承載大量工作的長期資料收集 Worker。
盤點真實執行階段版本、QUIC 後端、建置功能、代理協定與部署產物。主機命令列 curl 不一定等於容器、語言繫結或靜態程式內嵌的 libcurl。僅使用住宅代理並不能證明會進入此回呼；一般 HTTP 或 SOCKS 路由不會自動成為 HTTP/3 代理。
建立安全升級測試
只使用自己擁有或明確獲准測試的代理與目標，絕不能向第三方服務傳送畸形協定輸入。
- 記錄 curl/libcurl 版本、HTTP/3 後端與建置設定。
- 建立
:status先於一般標頭的合法對照回應。 - 在受控測試工具中注入一般標頭先於
:status的序列。 - 測試完全缺少
:status的回應。 - 分別測試重複虛擬標頭等其他無效序列。
- 記錄程序退出、curl 結果、協定錯誤、連線關閉、重試與記憶體診斷。
- 同時涵蓋單一 easy handle 與正式環境所用 multi 介面。
- 確認 Worker 仍存活，其他並行工作不受影響。
畸形序列的預期是有界錯誤，且絕不將回應視為有效結果。不必要求用戶端從無效順序恢復正常內容；應要求不崩潰、不將部分資料算作成功，也不靜默直連。
保守處理重試
解析或標頭順序錯誤不能證明更換住宅出口有效。無限輪替可能重複相同畸形回應、增加費用並掩蓋用戶端或閘道問題。
將此錯誤與逾時、407、目標 429 和一般 5xx 分開分類。只有操作安全且政策明確允許時才進行有界重試，並參考重試放大控制指南共用總嘗試預算。
HTTP/3 代理路徑失敗後，只有備援代理協定已設定、獲准且記錄時才能降級，絕不能繞過代理直接連線。代理繞過稽核可用來驗證 fail-closed。
驗證完整結果
升級後不能只看「程序不再崩潰」，還要確認合法回應繼續成功、異常順序回傳明確錯誤、標頭失敗後本文不會被當成有效結果、回呼不會收到半初始化中繼資料、憑證與工作階段仍限於代理路由、連線重用不會污染後續傳輸、並行工作繼續運作，且監控可區分代理標頭解析與目標失敗。
更完整的協定矩陣可參考HTTP/3 代理評估指南；需要驗證獲准備援路由時，再使用代理容錯移轉演練。
上線檢查清單
- 確認應用程式確實使用 8.22 前執行階段與相關 HTTP/3 代理路徑。
- 升級至 curl/libcurl 8.22.0，或依專案修正流程套用修補。
- 重建所有靜態二進位檔與內嵌 libcurl 的容器。
- 測試合法、一般標頭提前、缺少
:status三類固定場景。 - 要求有界錯誤、無崩潰、無部分成功。
- 涵蓋 multi 介面並行與連線重用。
- 保持重試有界且理解斷路狀態。
- 禁止靜默直接連線。
- 分批上線並監控崩潰、HTTP/3 代理錯誤和有效業務結果。
常見問題
這是 curl 官方安全公告嗎？
curl 8.22 變更紀錄將其列為 bugfix。不要自行加上專案未發布的 CVE 或嚴重性等級。
所有 HTTP/3 使用者都需進行此測試嗎？
不需要。應先確認用戶端到代理的一跳使用 curl 的 HTTP/3 代理實作。只有目標網站使用 HTTP/3 是不同路徑。
應換 IP 重試畸形回應嗎？
不能自動如此處理。應先把協定錯誤當作診斷證據，只在明確且有界的政策內重試，絕不能靠輪替規避目標控制。
什麼結果能證明升級成功？
合法流量繼續運作，異常順序明確失敗，程序與其他工作維持健康，而且沒有部分回應或直接連線繞過被接受。
來源說明與合規
內部研究來源：curl 專案於 2026 年 9 月 2 日發布的 curl 8.22.0 公告與變更紀錄；curl 專案《h3-proxy: fix NULL deref when non-:status header arrives before :status》合併紀錄，2026 年 7 月 30 日提出、7 月 31 日合併。來源 URL 僅保存在內部營運紀錄。
畸形回應測試只能在自有或明確獲准的基礎設施上進行。遵守供應商協議、目標條款、速率限制、隱私義務與當地法律。此修正用於加強防禦性解析，不能用來探測無關服務或規避存取控制。
