curl 的连接复用漏洞群：SMB 可能传错 share，静态包的版本号还会骗过扫描器
curl 8.17.0 于 2025-11-05 发布，其安全公告页列出的已公布问题累计有 43 条（总览见 curl security）。翻下来有一条贯穿的主题：连接复用（connection reuse）判断不严。libcurl 会维持一个近期连接池来省掉握手开销，复用一个连接需要同时满足一串条件；这些条件一旦有逻辑漏洞，就可能复用到错误的连接上。
连接复用类
最直接的一条是 CVE-2026-5773（wrong reuse of SMB connections）：libcurl 在某些情况下会为 SMB(S) 传输复用错误的连接。服务器相同、凭据相同，但 share 不同——结果就是可能下载到错误的文件，或者把文件上传到错误的位置。受影响范围从 7.40.0 到 8.19.0，后续版本修复，Netdata 的 tracking 里记录的修复版本为 8.20.0。NVD 于 2026-05-13 收录。
同一类别下还有：
- CVE-2026-8286：STARTTLS 连接错误复用
- CVE-2026-8458：不同服务之间错误复用
- CVE-2026-4873：连接复用忽略 TLS 要求
- CVE-2026-5545：HTTP Negotiate 连接错误复用
- CVE-2025-14017：多线程 LDAPS 场景下，改一个线程的 TLS 选项会影响全局，可能给其它线程关掉证书校验，受影响 7.17.0–8.17.0
凭据与令牌泄露
- CVE-2025-14524：OAuth2 bearer token 在 HTTP(S) 跨协议重定向到 IMAP/LDAP/POP3/SMTP 时，被错误转发到新主机
- 跨代理 Digest 认证状态泄露：CVE-2026-7168、CVE-2026-8927
- CVE-2026-6253：代理凭据经重定向泄露
- CVE-2026-6429：netrc 凭据因复用代理连接泄露
证书与固定
- CVE-2026-80230：OpenSSL pinning bypass
- CVE-2026-80231：native CA store 连接复用
- CVE-2026-11564：native CA trust persist
- CVE-2026-7009：OCSP stapling 绕过（Apple SecTrust）
另外，CVE-2026-11586 是 WebSocket Auto-PONG 导致的内存耗尽。
版本号判断不出编译选项
实际运维里更常见的问题不是漏洞本身，而是扫描器和实际构建对不上。
Netdata issue #22471：v2.10.3 的静态构建捆绑了 curl 8.17.0，低于修复版本 8.20.0，漏洞扫描器按版本号告警。但这个构建是用 --disable-smb 编译的，CVE-2026-5773 实际可能并不适用；作者仍然提出升级请求，以满足合规要求。
OPNsense 论坛这个帖子：26.1.5 里的 curl 8.17 被扫出多个 CVE，官方答复是随 26.1.6 升级（此前跳过了 8.18）。
curl 被大量内嵌——静态构建、发行版包、设备固件里都有。安全扫描通常只看版本号，与实际是否启用了相关功能并不一致。排查时不能只跑 curl --version，还要看编译选项。
修复思路
- 把内嵌或系统 curl 升级到包含修复的版本。
- 暂时无法升级的，先评估是否用到了受影响协议（SMB、LDAPS、跨协议重定向等），据此判断实际风险，而不是只看版本号。
- 对外发请求统一走受控的 HTTP 客户端，避免把 bearer token 交给会做跨协议重定向的调用链。