curl 8.22 修正 Secure Cookie 屬性解析繞過問題
curl 專案在 2026 年 9 月 2 日揭露並修正一項低風險 Cookie 解析問題。受影響版本在解析 Set-Cookie 回應標頭時，若 Secure 屬性前緊鄰的是水平定位字元（ASCII 9）而非空格，可能會把 Cookie 存入 Cookie jar，卻沒有保留 Secure 標記。之後，同一主機的明文 HTTP 請求可能攜帶該 Cookie。
這不是代理伺服器本身的漏洞，但會影響任何透過 curl 或 libcurl 重複使用 Cookie 的代理工作流程，尤其是同時存在 HTTPS、HTTP 降級、出口輪換與長期工作階段狀態的任務。
官方影響範圍
官方說明將問題列為低風險，影響 curl 命令列工具與 libcurl。受影響版本為 8.13.0 至 8.21.0，8.22.0 以上版本已修正。
觸發條件需同時成立：伺服器回傳包含目標 Cookie 的 Set-Cookie 標頭；Secure 屬性前使用水平定位字元；用戶端啟用 Cookie 儲存；之後又向同一主機發出明文 HTTP 請求。代理出口是否改變，並不會自動清除已經進入 Cookie jar 的狀態。
為何代理與資料收集團隊需要關注
代理輪換改變的是網路出口，不等於更換瀏覽器身分或應用程式工作階段。Cookie、驗證標頭、快取與重新導向狀態通常保存在用戶端。如果同一個 Cookie jar 被多個任務、協定或出口共用，錯誤解析的 Cookie 可能跨越原本預期的安全邊界。
常見風險場景包括：
- HTTPS 請求失敗後自動降級到 HTTP；
- 多個代理出口共用同一個 Cookie 檔案；
- 收集器把登入、匿名存取與健康檢查放在同一工作階段；
- 重試邏輯跨協定、跨主機或跨區域繼續沿用狀態；
- 只檢查代理 IP 是否變化，卻沒有檢查 Cookie jar。
因此，修正動作不應只停在「更換代理」。正確重點是升級 curl、隔離工作階段狀態，並驗證任何明文路徑都不會收到 Secure Cookie。
第一步：盤點 curl 與 Cookie 使用面
先建立可稽核清單，至少包含：
- curl 命令列版本與 libcurl 執行階段版本；
- 使用 Cookie 檔案、記憶體 Cookie jar 或共用工作階段的任務；
- 允許 HTTP、跟隨重新導向或進行協定降級的程式路徑；
- Cookie jar 是否在租戶、帳號、代理出口或任務之間共用；
- 生產映像、無伺服器函式、桌面工具與 CI 環境中的版本差異。
不要只檢查開發電腦。容器基礎映像與系統套件可能仍攜帶舊版 libcurl，即使上層應用程式看來已經更新。
第二步：優先升級並限制明文路徑
優先升級至 curl 8.22.0 或更高版本。若短期內無法升級，應套用官方修補方式，並避免在攜帶 Cookie 的工作階段中存取明文 HTTP。
同時收緊用戶端策略：
- 預設僅允許 HTTPS；
- 禁止自動從 HTTPS 降級到 HTTP；
- 對重新導向後的協定與主機重新執行允許清單檢查；
- 將登入 Cookie jar 與匿名收集、探測和健康檢查分離；
- 不讓不同客戶或工作負載共用 Cookie 檔案。
關於出口繞過與路由驗證，可參考站內的代理繞過稽核指南。
第三步：執行受控回歸測試
在隔離測試環境中建立受控回應端點，回傳 Secure 屬性前帶水平定位字元的 Set-Cookie。測試目的不是利用第三方網站，而是確認自己的用戶端是否正確保存安全屬性。
建議流程：
- 使用目標 curl 或 libcurl 組建發出 HTTPS 請求；
- 將 Cookie 寫入一次性 Cookie jar；
- 檢查 Cookie 是否記錄為僅限安全傳輸；
- 對同一測試主機發出受控 HTTP 請求；
- 確認請求沒有送出該 Cookie；
- 分別在直連、固定代理與輪換代理路徑重複測試；
- 刪除測試 Cookie jar，不與正式環境憑證混用。
測試時不要記錄真實 Cookie 值。證據只需保留版本、測試編號、協定、出口類型、是否傳送 Cookie 與結果時間。
第四步：驗證完整工作階段生命週期
單次 HTTPS 請求通過不代表整條鏈路安全，還應覆蓋重新導向、重試、代理切換、連線重用與任務復原。
建議建立下列矩陣：
- HTTPS 到 HTTPS，主機不變；
- HTTPS 重新導向到不同主機；
- HTTPS 意外指向 HTTP；
- 代理逾時後的同協定重試；
- 固定工作階段切換為輪換出口；
- 任務重新啟動後載入舊 Cookie jar。
每個場景都要驗證協定、目標主機、Cookie 標記與出口策略。重試次數與邊界可搭配代理重試預算指南設定。
第五步：準備可重現的支援證據
若升級後仍有異常，不要提交包含敏感 Cookie 的原始日誌。先製作最小化證據包：
- curl 與 libcurl 的完整版本；
- 作業系統或容器映像識別碼；
- 已去識別化的請求與回應標頭結構；
- Cookie jar 標記，而非 Cookie 值；
- 使用的協定和代理類型；
- 可重現步驟、預期結果與實際結果；
- 直連路徑是否同樣發生。
可使用代理支援升級資料包整理證據，避免把無關日誌或憑證傳給支援人員。
發布前檢查清單
- [ ] curl 或 libcurl 已升級到 8.22.0 或更高版本；
- [ ] 所有執行環境都完成版本盤點；
- [ ] Cookie 工作階段預設禁止明文 HTTP；
- [ ] 重新導向與重試不會繞過協定限制；
- [ ] Cookie jar 依租戶、帳號與任務隔離；
- [ ] 直連、固定代理、輪換代理均完成回歸測試；
- [ ] 日誌與工單不包含 Cookie 值、密碼或權杖；
- [ ] 失敗時預設停止，而非靜默降級。
常見問題
更換代理 IP 能消除這個問題嗎？
不能。代理 IP 變化只改變網路出口，Cookie jar 仍由用戶端保存。必須修正用戶端版本與工作階段隔離策略。
只存取 HTTPS 是否仍有風險？
僅允許 HTTPS 會大幅降低這個問題導致 Cookie 經明文傳送的機會，但仍應升級，因為重新導向、設定漂移或隱藏的健康檢查可能引入 HTTP 路徑。
受影響的是 curl 命令還是 libcurl？
兩者都在官方影響範圍內。使用 libcurl 的應用程式需要確認實際載入的執行階段函式庫版本，而不是只檢查系統中的 curl 命令。
是否應把 Cookie 內容寫入除錯日誌？
不應該。記錄標記、網域、路徑與測試結果即可，Cookie 值應始終去識別化或省略。
來源與合規說明
內部研究依據：curl 專案，CVE-2026-80255「secure cookie attribute bypass with tab」，發布日期為 2026 年 9 月 2 日。公開頁面不含外部連結；研究網址僅保存在內部營運紀錄。
僅能在你擁有或獲准測試的系統上執行回歸測試。遵守目標網站條款、robots 指令、隱私要求、資料保護法規與合理請求頻率。不得使用代理繞過存取控制、身分驗證或地域限制。
