curl 專案於 2026 年 9 月 2 日發布 CVE-2026-82209。啟用公共後綴清單支援的受影響版本中，若一個本身就是公共後綴的主機設定 Cookie，用戶端可能把它儲存為萬用字元網域作用域，而不是限制於該精確主機。之後存取或重新導向至同層子網域時，Cookie 可能被一併傳送。
curl 將此問題評為低風險，因為觸發條件要求公共後綴頂層主機先設定 Cookie，且用戶端之後還要存取其同層子網域。不過，對於持久保存 Cookie jar、自動跟隨重新導向、重用工作程序，並在大量目標間輪換代理出口的資料收集系統，這項修正仍有明確營運價值。
官方說明的影響範圍
啟用 libpsl 支援時，受影響版本為 curl 7.46.0 至 8.21.0；curl 8.22.0 以上已修正。libcurl 應用程式與 curl 命令列工具都可能觸發該行為。
邊界條件是 Set-Cookie 回應中的 Domain 屬性明確等於一個本身位於公共後綴清單的來源主機。正確行為應將 Cookie 限制為僅該主機可用；舊行為可能將其儲存為帶前導點的網域 Cookie，讓公共後綴下的同層子網域也有機會收到它。
這不表示一般可註冊網域的 Cookie 都不安全，也不表示代理伺服器能自行製造問題。風險取決於 Cookie 回應、啟用 PSL 的解析、後續目的地與 Cookie jar 的生命週期。
為何代理自動化團隊需要關注
代理出口屬於傳輸層屬性，Cookie 屬於應用狀態。輪換出口 IP 不會重設 Cookie 作用域、撤銷重新導向或隔離租戶。若共用工作程序把作用域過寬的 Cookie 帶入下一個任務，網路路線即使變化，應用身分仍可能被污染。
應優先檢查以下系統：
- 以持久 Cookie jar 收集大量不相關主機；
- 自動跨主機跟隨重新導向；
- 多個工作程序共用 libcurl handle 或 Cookie 檔案；
- 切換國家或住宅代理工作階段時不重設應用狀態；
- 把出口 IP 變化視為全新瀏覽器工作階段；
- 編譯時啟用 libpsl，卻沒有盤點實際執行版本。
第一步：確認真實執行階段，而非僅看套件標籤
記錄每個環境實際載入的 curl 與 libcurl 版本，包括容器、無伺服器函式、桌面工具、排程工作、CI 執行器和供應商應用。同時確認組建是否報告公共後綴清單支援。
不要假設升級 curl 命令就會更新所有應用。服務可能動態連結另一份 libcurl，靜態二進位檔也可能在系統套件升級後繼續攜帶舊程式碼。
盤點表應將每個執行階段關聯至 Cookie 模式、重新導向策略、代理設定、部署負責人和重啟流程，才能把安全公告轉換為邊界明確的升級任務。
第二步：升級並處理舊工作階段狀態
將受影響用戶端升級至 curl 8.22.0 或更高版本。若無法立即重新建置，可採用官方修補程式，或在完成修正前暫停該工作流程的 Cookie 使用。
升級後還要決定如何處理舊用戶端建立的 Cookie jar。匿名收集通常直接替換較簡單；驗證流程則應依風險制定失效方案，尊重工作階段所有權並避免意外觸發帳號鎖定。
重新啟動或排空長期運作的工作程序，確保修正後的函式庫確實載入。重啟前取得的套件版本，不能單獨證明執行階段已修正。
第三步：讓 Cookie 分區獨立於代理工作階段
Cookie 分區鍵應反映應用信任邊界，可包含租戶、帳號、目標可註冊網域、環境和驗證用途。不要將它與代理工作階段鍵綁成同一概念。
例如，兩個任務可以刻意共用一個黏性住宅代理出口，但必須使用不同 Cookie jar；反過來，同一個受控驗證工作階段可能在批准的出口間切換，卻仍需要一個嚴格管理的 Cookie jar。將兩者耦合會造成意外狀態共享。
可配合站內的住宅代理工作階段黏性測試檢查傳輸與工作階段的差異，並使用代理繞過稽核指南驗證意外直連路徑。
第四步：建立受控網域邊界回歸測試
只使用你擁有或獲准測試的網域與子網域。建立可安全模擬 PSL 行為的測試夾具，讓回應覆蓋精確的 Domain 邊界條件。Cookie 名稱和值必須是沒有正式用途的合成資料。
建議測試順序：
- 啟動新程序並使用空的一次性 Cookie jar；
- 經由預定代理路徑請求受控 HTTPS 來源；
- 收集 Cookie 中繼資料，但不記錄 Cookie 值；
- 檢查 Cookie 是僅限主機或網域作用域；
- 請求獲准的同層主機，並斷言請求中沒有該 Cookie；
- 在重新導向、程序重啟和重新載入 jar 後重複；
- 分別覆蓋直連、固定代理和輪換代理；
- 測試後銷毀暫存夾具。
測試必須預設失敗。PSL 資料庫無法使用、組建未知、重新導向異常或斷言缺失時，應產生明確失敗，而不是靜默通過。
第五步：將重新導向與重試視為獨立邊界
Cookie 暴露可能發生在最初回應之後，因此需要驗證完整請求圖。每一跳都記錄初始主機、重新導向目標、最終位址、協定、Cookie 網域判斷、代理路線與重試原因。
拒絕會靜默從代理切換成直連，或擴大允許目的地集合的重試。限制重試次數，並禁止把 Cookie jar 帶入不同信任鍵的任務。故障持續時，應整理有限且去識別化的代理支援升級資料包，而不是繼續增加重試。
第六步：監控中繼資料，但不洩露憑證
有價值的遙測包括用戶端版本、PSL 支援狀態、Cookie 的 host-only 標記、正規化網域、重新導向邊界、工作程序識別碼與策略決定。不要記錄 Cookie 值、驗證標頭、密碼、代理憑證或原始工作階段權杖。
可為以下情況設定警示：在公共後綴邊界接受 Cookie、跨分區重用 Cookie jar、重新導向至未批准的同層主機，或部署截止後工作程序仍回報舊版 libcurl。
部署檢查清單
- [ ] 所有工作負載的 curl 與 libcurl 執行版本已盤點；
- [ ] 每個組建的公共後綴清單支援狀態已確認；
- [ ] 受影響用戶端已升級至 8.22.0 或更高版本；
- [ ] 長期工作程序已重啟或排空；
- [ ] 舊 Cookie jar 已依書面規則失效或複核；
- [ ] Cookie 分區鍵與代理工作階段鍵相互獨立；
- [ ] 重新導向與重試執行目的地和路線允許清單；
- [ ] 直連與代理路徑的受控同層網域測試均通過；
- [ ] 日誌只含 Cookie 中繼資料，不含 Cookie 值；
- [ ] 失敗會停止流程，而不是擴大作用域或繞過代理。
常見問題
更換代理 IP 能避免這個問題嗎？
不能。代理輪換改變傳輸路線，而 Cookie jar 仍是用戶端應用狀態。修正需要更新用戶端並正確隔離狀態。
每個 curl 組建都會受影響嗎？
官方公告描述的是啟用 libpsl 支援的 7.46.0 至 8.21.0 版本。必須確認實際執行組建的功能與版本。
是否應關閉公共後綴清單支援？
首選方案是升級。PSL 檢查本身是重要的 Cookie 邊界控制，廣泛關閉可能帶來不同風險。若必須暫時緩解，應限制範圍並記錄權衡。
可以對任意公共網域執行測試嗎？
不可以。只使用受控網域與合成工作階段，不要向沒有所有權或測試許可的系統傳送特製 Cookie 或自動請求。
來源與合規說明
內部研究依據：curl 專案安全公告「domain-scoped PSL domain cookie」，CVE-2026-82209，發布於 2026 年 9 月 2 日。研究網址僅保存在內部營運紀錄，本公開文章不包含外部連結。
僅對獲准目標運行代理與資料收集系統。遵守網站條款、隱私要求、robots 指令、資料保護法規與合理請求頻率。不得利用代理基礎設施繞過存取控制、身分驗證或地域限制。
