HTTP/2 Server Push 允許伺服器在客戶端明確請求前主動提供額外資源。多數代理資料蒐集工作不需要此功能；若應用程式主動啟用推送，就必須把父傳輸、接受的推送控制代碼、共享連線快取與清理順序視為同一個生命週期。
本指南提供受控稽核流程，事實依據包括 curl 專案於 2026 年 9 月 2 日發布的 CVE-2026-18924。此低風險問題在特定 HTTP/2 推送與共享連線組合下，可能在清理階段觸發釋放後使用。curl 8.22.0 已修正。
目標不是向公共網站傳送異常流量，而是在授權測試環境確認應用是否能進入相關路徑，精確升級並保留足夠的回歸證據。
核對全部觸發條件
官方公告要求同時符合：
- libcurl 應用透過
CURLMOPT_PUSHFUNCTION啟用 HTTP/2 推送； - 應用透過
CURL_LOCK_DATA_CONNECT共享連線； - 使用 HTTPS 並協商為 HTTP/2；
- 伺服器傳送 HTTP/2 推送；
- 應用回呼接受該推送。
curl 命令列工具不受影響。未啟用推送回呼、永遠拒絕推送、從不共享連線或只使用 HTTP/1.1 的客戶端，都不符合完整觸發組合。
受影響版本為 curl 7.44.0 至 8.21.0；curl 8.22.0 及以上已修正。應盤點執行時行為，不要只依 HTTP/2 程式庫、代理方案或套件名稱推斷。
代理團隊為何仍需測試
代理增加路由與連線池層，可能掩蓋實際協商協定。請求可能透過 HTTP CONNECT 通道與來源站使用 HTTP/2，也可能在客戶端到代理和代理到來源站之間使用不同協定。Server Push 屬於提供推送的 HTTP/2 對端，不屬於住宅代理出口身分。
稽核必須區分客戶端到代理的協定、通道後的來源站 HTTP 版本、父 easy handle 與接受的推送控制代碼、共享連線快取身分、回呼決策及清理結果。
更換代理出口無法修正客戶端本機的記憶體生命週期問題。應升級客戶端並驗證精確程式碼路徑。
建立隔離測試夾具
使用一次性測試程序、組織擁有的 HTTPS 端點及無害靜態資源。讓伺服器在請求父頁面時只提供一個小型推送資源，並為每次執行分配唯一編號。
準備四種基線模式：
- HTTP/1.1，不啟用推送；
- HTTP/2，不設定推送回呼；
- HTTP/2，回呼拒絕推送；
- HTTP/2，回呼接受推送。
先在不共享連線時執行，再使用具備正確鎖定回呼的 share handle 與 CURL_LOCK_DATA_CONNECT 執行。如此可定位引入相關生命週期的功能轉換。
不得在無關公共伺服器上測試，也不要在正式環境誘發當機。測試內容應無敏感資料、有限速，並與下游匯入系統隔離。
測試前補齊所有權遙測
為 multi handle、每個 easy handle、share handle、父傳輸、每個推送、接受的推送控制代碼、連線快取項目與清理階段分配穩定內部識別碼。
記錄應保存狀態變化而非秘密。可用欄位包括時間戳記、案例編號、父編號、推送編號、回呼決策、HTTP 版本、代理路線類別、新建或重複使用連線、結果碼與清理完成狀態。
禁止記錄代理密碼、授權標頭、Cookie、私密 URL、回應正文或原始記憶體內容。
執行生命週期矩陣
每種模式依序執行：
- 啟動新測試程序，建立 share 與 multi handle；
- 在共享連線資料前安裝所需鎖定回呼；
- 發出父 HTTPS 請求；
- 記錄協商後的 HTTP 版本及連線識別碼；
- 收到推送時記錄回呼決策；
- 讓父傳輸與接受的推送正常完成；
- 依文件化順序移除已完成控制代碼；
- 按應用所有權銷毀 easy、multi 及 share handle；
- 確認程序正常結束，每個解構事件只發生一次；
- 在隔離 CI 中以偵錯或記憶體安全建置重複測試。
公告指出偵錯建置可在相關序列提供明顯提示與斷言。偵錯器與 sanitizer 只能用於受控環境，也不能取代正式升級。
增加並行與失敗案例
單一推送基線通過後，每次只加入一個有界情境：父傳輸先結束、推送先結束、一個推送拒絕另一個接受、回應期間取消、代理通道正常關閉、清理前網路逾時、連線可被其他控制代碼重複使用、multi 迴圈暫停恢復，以及無活動傳輸時關閉應用。
保持低並行與確定性。此處測試的是生命週期，不是壓力測試。過高請求率不利於歸因，也可能違反端點或代理限制。
比較直連與代理路線
使用相同夾具分別覆蓋授權直連控制組、HTTP 代理、HTTPS CONNECT 代理，以及應用明確支援的 HTTP/2 代理模式。
回呼與清理結果應一致。若某條路線沒有出現 Server Push，應記錄為協定行為，不能據此宣稱程式碼安全；仍需透過真正符合所有條件的路線覆蓋觸發路徑。
可搭配HTTP/2 代理連線重複使用稽核核對連線池邊界，並以代理延遲歸因指南拆分握手、通道、來源站和應用耗時。
升級與部署
首選方案是升級到 curl 8.22.0 或以上。暫時無法升級時，官方建議避免 HTTP/2 Server Push，或避免受影響的連線共享組合。沒有業務用途時，直接停用推送通常是較簡單的暫時控制。
升級後應確認執行程序實際載入目標版本，重新啟動長期工作節點，清除舊共享連線池，重跑完整驗收矩陣，再以小流量 canary 推廣。
驗收清單
- [ ] 已記錄執行時 curl/libcurl 版本。
- [ ] 已確認是否使用推送回呼及共享連線資料。
- [ ] 夾具中實際觀察到 HTTPS 與 HTTP/2。
- [ ] 已涵蓋接受與拒絕推送路徑。
- [ ] 父子控制代碼所有權明確。
- [ ] 每個控制代碼與快取物件只清理一次。
- [ ] 偵錯或 sanitizer 測試沒有相關發現。
- [ ] 已比較直連與核准的代理路線。
- [ ] 正式程序載入 curl 8.22.0 或已驗證修補版本。
- [ ] 記錄不含憑證與敏感內容。
FAQ
所有 HTTP/2 客戶端都會受影響嗎？
不會。必須符合 libcurl 推送回呼、接受推送、共享連線、HTTPS 與 HTTP/2 的特定組合。
curl 命令列工具是否受影響？
不受影響。官方公告明確說明問題只影響 libcurl 應用程式。
輪換代理 IP 能否避免問題？
不能。出口輪換改變網路路線，不會修正客戶端程序中的控制代碼所有權與清理邏輯。
蒐集器應啟用 Server Push 嗎？
只有具備明確業務需求、所有權模型、測試及遙測時才應啟用。若應用不用推送資源，拒絕或停用可降低複雜度。
來源與合規說明
內部研究依據：curl 專案「HTTP/2 server push UAF」安全公告，CVE-2026-18924，發布於 2026 年 9 月 2 日；curl 8.22.0 發布資料。外部資料 URL 僅保存在內部營運記錄中，公開文章不含外部連結。
只在擁有或獲授權的應用、端點、代理帳號及網路上測試，並遵守目標站條款、供應商限制、隱私要求與組織變更流程。
