Traefik ForwardAuth 把 NTLM 身份串给了别人：认证子请求共用连接池，v2.11.60 / v3.7.16 才隔离
- Advisory：GHSA-hrpp-p4fc-wwf8
- 修复版本：v3.7.16
- 等级 High，CVSS 7.0，无 CVE，2026-10-21 发布
影响范围
| 分支 | 受影响版本 | 修复版本 |
|---|---|---|
v2（github.com/traefik/traefik/v2） | <= v2.11.59 | v2.11.60 |
v3（github.com/traefik/traefik/v3） | >= v3.0.0, <= v3.7.15 | v3.7.16 |
v3.0 到 v3.6 已 EOL，不会在自己的分支上修复，只能升级到 v2.11.60 或 v3.7.16。
触发条件
只有当认证服务器使用连接绑定（connection-bound）的认证方案时才会触发：NTLM，或 SPNEGO/Kerberos 的 Negotiate，典型场景是 IIS 的 Windows 认证。认证端如果只做 Basic、Bearer token 一类与连接状态无关的校验，不涉及这条路径。
漏洞机制
ForwardAuth 发出的认证子请求，走的是该中间件所有客户端共享的同一个连接池。NTLM/Negotiate 的认证状态是绑在 TCP 连接上的：用户 A 完成握手后，那条通往 auth server 的连接就带着 A 的身份。此时 B 从另一条前端连接进来，Traefik 发子请求时复用了这条已认证连接，auth server 直接回 200；Traefik 认为 B 已通过认证，把 authResponseHeaders 中的用户标识转发给后端，后端看到的就是 A。B 全程不需要任何凭据。
v3.7 中 Kubernetes Ingress NGINX provider 的 auth-url 注解所发出的外部认证请求，同样受此影响。
与之前几个 GHSA 的区别
GHSA-53qr-784g-cj35、GHSA-qqjf-53cj-pwvv、GHSA-cw35-4q88-3rmp、GHSA-qm9f-w54v-q2qh 只隔离了 backend 代理路径上的连接绑定认证。这次的缺陷在 auth server 一侧——前面几个补丁打完，只要认证端是 NTLM，身份仍然会串。修复把同样的按前端连接隔离的做法应用到了认证服务器连接上。
CVSS v4 向量：AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N。
排查
- 列出所有 ForwardAuth 中间件和 ingress-nginx
auth-url指向的认证端点。 - 直接打认证端点，看它宣告的认证方案：
curl -sv -o /dev/null https://auth.example.com/ 2>&1 | grep -i '^< www-authenticate'
出现 Negotiate 或 NTLM 即满足触发前提；响应中出现 NTLMSSP 标记同样是连接绑定认证的信号。
3. 核对 Traefik 版本是否落在受影响区间，尤其是还在跑 v3.0–v3.6 的集群。
缓解
- 升级到 v2.11.60 / v3.7.16。这是唯一能保住现有 Windows 域透明登录的方案。
- 短期无法升级时，把认证端换成不依赖连接状态的方案，例如 Basic（务必走 HTTPS）或 token 校验。代价是丢掉域内免密登录，用户需要重新输入凭据。
- 在认证端或网络层让 ForwardAuth 的子请求不复用连接：每请求独立连接、关闭 keepalive。代价是每次请求都要重做一遍 NTLM 握手，到 auth server 的延迟和连接开销明显上升，属于降风险而非修复。
v3.7.16 的发布说明里另有一条：Support NTLM and Kerberos in ForwardAuth and ingress-nginx auth-url（#14091、#14084）。