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 日。研究 URL 仅保存在内部运营记录中，本公开文章不包含外部链接。
仅对获准目标运行代理和数据采集系统。遵守站点条款、隐私要求、robots 指令、数据保护法规与合理请求频率。不得利用代理基础设施绕过访问控制、身份验证或地域限制。
