curl 8.22 修正 Negotiate 連線重用問題：代理自動化稽核指南
curl 專案於 2026 年 9 月 2 日隨 curl 8.22.0 揭露 CVE-2026-19931。問題涉及使用 Negotiate 驗證建立的 HTTP 連線：空白憑證代表由作業系統提供的「環境使用者」時，若該身分在 libcurl 不知情的情況下改變，後續請求可能重用仍以先前使用者驗證的連線。
curl 公告將其評為中等，受影響版本為 7.64.1 至 8.21.0，curl 8.22.0 已修正。專案首選建議為升級；無法立即升級時，官方緩解方式是禁止使用空白憑證的傳輸重用連線。
對執行代理資料蒐集、市場研究、廣告驗證或內部自動化的團隊，結論應準確：凡是程序、使用者或工作共享連線狀態，都應盤點 libcurl。不要聲稱所有代理密碼或住宅代理工作階段都受影響；觸發條件必須符合 curl 描述的 Negotiate 與環境憑證組合。
明確問題邊界
Negotiate 驗證可從 Windows 的 SSPI 或其他系統的 GSSAPI 取得憑證。在受影響的空白憑證模式中，驗證提供者背後的環境使用者可能改變，而 libcurl 無法得知。
風險來自跨身分重用連線，不是 DNS 或代理出口輪替。持久連線可保留驗證內容，即使應用程式認為下一個請求屬於另一使用者。
這也不同於一般 HTTP 407 疑難排解。驗證成功不代表連線屬於目前預期主體。
判斷觸發條件是否存在
對每個嵌入 libcurl 的應用回答：
- 執行中的 libcurl 是否為 7.64.1 至 8.21.0？
- 是否有請求使用 HTTP Negotiate 驗證？
- 是否使用空白憑證，由驗證提供者取得環境身分？
- 可重用連線仍在池中時，環境身分是否可能改變？
任一答案為否，應記錄為何無法觸發；全部為是或未知，則需納入修復與驗證。
盤點不能只看 curl 命令列。許多桌面代理、SDK、資料工具及內部服務會嵌入 libcurl。應同時記錄應用版本與實際載入的執行階段函式庫版本。
優先升級
乾淨的修復方式是透過應用支援的更新管道部署 curl 或 libcurl 8.22.0 以上版本，並確認容器或套件在執行時確實載入已修正函式庫。
安全上線順序：
- 建立受影響與未知元件清單；
- 優先處理共享程序、服務帳號與多使用者主機；
- 更新金絲雀環境；
- 重新啟動或排空可能保留舊連線的程序；
- 執行身分隔離測試；
- 依工作負載與區域擴展；
- 設定回復標準，但不得回復至有問題的函式庫。
無法立即升級時，針對確切受影響流程採用 curl 專案提供的緩解：禁止空白憑證連線重用。同時評估效能影響，避免暫時方案造成無上限建連風暴。
建立身分隔離測試
只使用已授權測試服務與合成主體，不得使用真實客戶工作階段。
每次請求記錄：
client_build
loaded_libcurl_version
auth_scheme
credential_mode
synthetic_principal_alias
connection_reused
connection_alias
server_observed_principal_alias
request_result別名不能包含使用者名稱、票證、Cookie 或驗證材料。
測試順序：
- 在受影響設定下，以合成主體 A 發出請求；
- 保持用戶端程序與連線池存活；
- 透過受支援測試機制切換環境身分至主體 B；
- 向同一授權主機傳送第二個請求；
- 比較預期主體與服務端觀察主體；
- 升級後以及停用重用時分別重複。
修正後的結果必須讓每次請求對應預期主體，或建立適當隔離的連線。最終 HTTP 成功碼本身不足。
讓代理連線池明確分區
即使不涉及此 CVE，連線池也應有明確隔離鍵。依用戶端與協定，可能包含：
- 代理閘道主機與連接埠；
- 驗證方案；
- 憑證或服務帳號身分；
- 租戶或工作負載邊界；
- TLS 政策與用戶端憑證；
- 目的 authority；
- 必要區域或路由政策。
不了解用戶端重用規則時，不要自行在函式庫外包裝連線池。優先使用受維護版本與官方隔離控制。
監控維運回歸
禁止重用或排空連線池會增加建連、TLS 握手與驗證次數。修復期間監控：
- 每秒新連線數；
- 代理驗證延遲與失敗；
- 首試成功率；
- 檔案描述符與暫時連接埠壓力；
- p95 建連與請求延遲；
- 有上限的重試量；
- 每個有效結果的成本。
安全正確性是驗收門檻，效能調整不能重新引入跨身分重用。
稽核清單
- [ ] 已知實際執行的 libcurl 版本。
- [ ] 已定位 7.64.1 至 8.21.0。
- [ ] 已識別 Negotiate 驗證流程。
- [ ] 空白與明確憑證模式已分開。
- [ ] 優先處理多使用者與共享程序用戶端。
- [ ] 已部署 8.22.0 或更高版本。
- [ ] 升級後舊連線池已排空。
- [ ] 合成 A 至 B 身分測試通過。
- [ ] 重用遙測不含秘密。
- [ ] 暫時停用重用有容量限制。
- [ ] 代理 407 與 TLS 仍正常。
- [ ] 測試不使用真實使用者身分資料。
相關內容可參考 98IP 的代理憑證輪替、curl 代理驗證 407 疑難排解與住宅代理工作階段黏著測試。
常見問題
所有 curl 代理請求都受影響嗎？
不是。公告描述的是使用空白憑證代表環境使用者的 Negotiate 驗證，並在環境身分改變後重用連線。應核對實際條件，不要把所有 curl 使用都判定為受影響。
只升級 curl 命令列就足夠嗎？
若應用嵌入或動態載入另一版 libcurl，就不足。必須確認執行中程序使用的函式庫。
清空連線池能取代升級嗎？
不能。清空連線只能降低短期暴露，無法修正受影響版本的重用判斷。應升級至修正版，或在升級前採用專案公布的緩解方法。
輪替代理出口可以緩解嗎？
不可以。問題涉及驗證連線身分。輪替出口 IP 不會修正錯誤驗證連線，反而可能讓證據更難解讀。
合規說明
只在已授權系統與身分上驗證。不得對第三方服務或真實使用者工作階段重現問題。保護驗證材料、最小化日誌、遵守事件應變要求，並只將代理用於合法工作。
來源說明：curl 專案，《Negotiate ambient user conn reuse》，CVE-2026-19931，發布於 2026 年 9 月 2 日。
