安全决策¶

我们会反复收到某些类型的报告。本页记录已经明确的立场， 方便你在提交前对照检查，也让我们可以引用已有结论， 而不必每次重新分析。

本页按报告涉及的安全领域组织。每项先说明团队立场，再说明边界在哪里： 哪些相邻变体确实被视为漏洞，并附上相关公告作为证据。 这条边界才是有用的部分。几乎每个领域都既有被关闭的报告，也有产生 CVE 的报告。

本页应用威胁模型，由该模型定义边界本身。 如果只想先了解简要说明，请从那里开始。

路径处理、规范化与编码¶

常见报告。 特制路径（%2e%2e、%2f、双重编码、字面的 ;、 反斜杠或 URL 片段）穿越或逃离某个前缀，到达原本应由中间件保护的路由或后端。

我们的立场。 这是发现有效问题最多的领域，我们认真对待。 在入口点使用原始默认配置时，规范化或编码差异仍能到达后端，就属于漏洞， 即使它仅表现为路径解码形式与原始形式之间不同步。

边界在哪里。 如果逃逸依赖运维人员放宽处理规则， 或依赖某个后端对标准允许字符的再次解释，我们不将这类变体视为漏洞：

• 只有编码字符处理保持宽松时，逃逸才成立。 这一默认值是有意且有文档说明的兼容性决定，只在主要版本中重新评估。
• 攻击字符是 RFC 3986 允许出现在路径片段中的字符， 例如字面的 ; 或反斜杠，而且只有特定后端重新解释它时才会产生逃逸。 这种重新解释因后端而异，应由后端定义：Java Servlet 家族通过 ; 引入路径参数是标准行为， 不是某个实现的怪异特例。我们不会将某个已公开编码分隔符漏洞的所有字面字节变体 都纳入 CVE 处理。

提交前，请使用入口点原始配置，针对会进行规范化的后端确认绕过成立。

此类已判定案例。 GHSA-xf64-8mw2-4gr2（CVE-2026-48020，StripPrefix 路由级身份验证绕过）， GHSA-6jwx-7vp4-9847（CVE-2026-40912，StripPrefixRegex 的 Path/RawPath 不同步），GHSA-46wh-3698-f2cx（CVE-2026-33186，去前缀中间件的点片段绕过）， GHSA-gm3x-23wp-hc2c（CVE-2025-66490，路由器与中间件规则组合）， GHSA-vrch-868g-9jx5（CVE-2025-47952，通过 URL 编码实施遍历）， GHSA-6p68-w45g-48j7（CVE-2025-32431，路径匹配器）， GHSA-fvhj-4qfh-q2hm（CVE-2023-47106，URL 片段），以及 GHSA-cxjq-mrr5-89rv （ReplacePathRegex）。

转发请求头与客户端身份¶

常见报告。 中间件透传或未移除某个 X-Forwarded-* 或 Forwarded 请求头，使客户端可以影响后端对其身份、协议、端口或地址的判断。 由于相邻代码路径没有重复其他地方新增的移除操作，这类报告经常被描述为已公布问题的修复不完整。

我们的立场。 转发请求头的信任边界位于入口点层级。 forwardedHeaders.trustedIPs 和 forwardedHeaders.insecure 在入口点、任何中间件运行前， 一次性决定是否信任客户端的转发请求头。我们有意不在每个中间件中重复判断： 每个中间件重新作出决定，正是我们要避免的设计错误，而不是遗漏。 中间件透传入口点已经接受的请求头，属于设计行为；相邻路径没有重复移除操作， 不自动意味着修复不完整。

边界在哪里。 以下情况属于漏洞范围：

• 某条路径在入口点清理后重新引入或重建可信值， 使入口点之前的决定失效。
• 中间件根据运维人员已声明不可信的请求头，作出身份验证前的决定。

“不自动意味着修复不完整”并不是“绝不会”：如果相邻路径确实重新引入了相同的攻击原语， 我们已经将其作为修复不完整问题发布过公告。

此类已判定案例。 GHSA-6384-m2mw-rf54（CVE-2026-35051，trustForwardHeader=false 时仍采用伪造前缀）， GHSA-3q9r-p662-5j8m（CVE-2026-54764，ForwardAuth 信任伪造端口）， GHSA-92mv-8f8w-wq52（CVE-2026-29054，区分大小写的 Connection 请求头）， GHSA-62c8-mh53-4cqv（CVE-2024-45410，滥用 Connection 请求头移除 X-Forwarded-*），GHSA-h924-8g65-j9wg（CVE-2024-52003，通过前缀实施开放重定向），以及 GHSA-6qq8-5wq3-86rp（CVE-2020-15129，前缀请求头未经验证）。

Traefik 为后端设置的请求头¶

常见报告。 客户端预先设置某个请求头，或设置其另一种拼写，而 Traefik 原本会为后端写入这个请求头： 例如身份验证中间件在配置的 headerField 中写入已认证用户， PassTLSClientCert 写入客户端证书信息，前缀中间件写入 X-Forwarded-Prefix， 以及 X-Replaced-Path 或自定义请求头。后端因为这些值由 Traefik 设置而信任它们， 因此伪造这些值就构成攻击。

我们的立场。 原因与转发请求头相同，架构也相同：请求头清理由入口点负责， 不是每个中间件分别负责。 中间件会移除即将设置请求头的规范拼写。 后端会折叠为同一名称的其他拼写，则在路由之前， 由入口点的 aliasHeadersStrategy 统一处理一次。

这里需要说明底层差异，因为它让这一类问题不那么直观：Go 仅根据 - 规范化请求头名称， 而根据请求头名称生成变量名的后端（CGI、WSGI、PHP、nginx、Tomcat）会将其他字符折叠为 _。 因此，在 Traefik 看来不同的两个请求头名称，到达后端后可能变成同一个。 这是整个请求的属性，而不是某个中间件的属性， 也正因此要在入口点解决。

边界在哪里。 仅证明单独看某个中间件时，它没有清理自己设置的请求头的报告， 不会被接受为漏洞。清理由入口点负责；在每个中间件内重新决定，是我们避免的设计，而不是遗漏。 以下情况属于漏洞范围：

• 某种拼写通过入口点清理后，仍以可信名称到达后端；
• 中间件在入口点清理之后重建或重新引入该值。

此类已判定案例。 GHSA-qr99-7898-vr7c （CVE-2026-33433，通过非规范 headerField 伪造身份）， GHSA-x677-9fxg-v5c5 （CVE-2026-54763，被确认的修复不完整：别名拼写绕过了针对上一案例新增的移除操作），以及 GHSA-5m6w-wvh7-57vm （CVE-2026-39858，身份验证前决策中的别名伪造）。

TLS 与 mTLS 强制约束¶

常见报告。 由于 Traefik 为连接选择了错误的 TLS 配置， 客户端到达了某条路由，或避免了提交证书。

我们的立场。 强制约束失效属于漏洞范围。这个领域反复出现的具体形式，是我们现在会直接检查的： 连接所选用的 TLS 配置必须与运维人员为该主机预期的配置匹配， 包括通配符映射、大小写混合的主机名以及所有协议版本。 即使每个组件都按代码执行，只要配置不匹配导致客户端证书验证被跳过，就构成绕过。

边界在哪里。 配置宽松的 TLSOption，或省略客户端身份验证， 是运维人员的选择，不是缺陷。漏洞范围是 Traefik 没有应用运维人员实际设置的更严格配置， 或者只在某个协议上应用，而没有在另一个协议上应用。

此类已判定案例。 GHSA-9cr8-q42q-g8m7（CVE-2026-53622，HTTP/3 对通配符和大小写混合主机执行精确 SNI 查找）， GHSA-5r4w-85f3-pw66（CVE-2026-48491，SNICheck 忽略通配符映射，造成域名前置绕过）， GHSA-wvvq-wgcr-9q48（CVE-2026-32305，分片 ClientHello 在 SNI 之前回退到默认配置）， GHSA-gv8r-9rw9-9697（CVE-2025-68121，HTTP/3 上的 ClientAuth）， GHSA-gxrv-wf35-62w9（CVE-2024-39321，通过 QUIC 0-RTT 早期数据绕过 IP 允许列表）， GHSA-468w-8x39-gj5v（CVE-2022-46153，空 TLSOption 导致路由暴露），以及 GHSA-hrhx-6h34-j5hc（CVE-2022-23632，选择了错误的 TLS 配置）。

Kubernetes 跨命名空间与跨提供者引用¶

常见报告。 某个命名空间或某个提供者下的资源，通过 backendRef、ExtensionRef、 ServersTransport 或跨提供者引用，访问了本不应到达的服务、中间件或传输配置。

我们的立场。 引用逃离运维人员建立的边界，到达配置未授权的命名空间或提供者， 就属于漏洞。这个领域产生了相当一部分 CVE。

边界在哪里。 检查允许列表的信任锚点，是否对当前路由真的能够被绕过。 如果跨越操作受运维人员主动启用的选项控制，例如 crossProviderNamespaces 或 allowCrossNamespace， 这就是该选项在文档中说明的契约。如果未启用这些选项仍然可行，或能突破它们，则属于漏洞范围。 同样，如果报告要求能够创建或编辑相关 Kubernetes 对象，也不构成跨越边界： 该参与者本来就控制着命名空间内的路由。

此类已判定案例。 GHSA-62fc-8686-hfmq（CVE-2026-71325，通过 @kubernetescrd 绕过 allowCrossNamespace=false）， GHSA-3g6v-2r68-prfc（CVE-2026-54761，突破 crossProviderNamespaces 允许列表）， GHSA-42cj-m3vj-89wv（CVE-2026-65602，IngressRouteTCP ServersTransport）， GHSA-qq9q-x9w4-chhj（CVE-2026-65601，ExtensionRef 命名空间混淆）， GHSA-xhjw-95fp-8vgq（CVE-2026-41174，跨命名空间中间件绑定）， GHSA-96qj-4jj5-wcjc（CVE-2026-44774，可将 rest@internal 用作后端）， GHSA-67jx-r9pv-98rj（CVE-2026-32695，主机限制被绕过），以及 GHSA-8q2w-wr49-whqj（CVE-2026-29777，Ingress 和 HTTPRoute 中未转义值导致规则注入）。

生成键与共享状态¶

常见报告。 两个不同对象的内部键发生冲突，或共享缓存、 连接池、进行中的请求，从而让一个对象进入另一个对象的上下文。

我们的立场。 判定此类报告的关键区别是：谁生成了冲突键。

• 如果冲突必须由报告者自行构造，例如创建或编辑名称会碰撞的对象， 就不构成跨越边界。用于命名路由器、服务和中间件的内部键空间， 不是共享实例上的租户隔离边界。
• 如果是 Traefik 生成的键，却对运维人员已分离的输入发生碰撞，就属于漏洞。 缓存、连接池或去重机制的键约束过宽而导致共享状态，也属于漏洞。

边界在哪里。 严重程度取决于碰撞实际跨越的边界，而不是碰撞机制： 共享控制平面上跨命名空间或租户的生成键冲突属于高严重度； 如果只限制在单个凭据缓存内部，不会跨租户，则属于低严重度。两者仍然都是漏洞。

此类已判定案例。 GHSA-fgjj-px3w-67xx（CVE-2026-71327，Gateway API 路由身份冲突， 跨命名空间后端劫持，高严重度）， GHSA-6765-c87h-8mrf（CVE-2026-71326，BasicAuth singleflight 键冲突， 低严重度），GHSA-6p8f-p8j2-rqmv（CVE-2026-54765，共享同一 Service:port 的路由间泄漏 backendRef 过滤器），以及 GHSA-3ccp-42pg-hgv6（CVE-2026-71324，共享后端 keep-alive 连接池造成跨用户响应污染）。

Ingress-NGINX 提供者兼容性¶

常见报告。 Kubernetes Ingress-NGINX 提供者的某个默认行为或注解行为不安全， 并有可运行的复现。

我们的立场。 该提供者的契约是兼容 ingress-nginx 注解。 只要它忠实重现了上游文档说明的语义，即使上游结果不安全，我们也会保留兼容行为， 转而改进文档；否则会静默破坏这个提供者旨在支持的迁移。 先检查上游行为。如果 Traefik 与之相同，预期处理结果是文档修改，而不是安全公告。 我们已基于此理由关闭的报告包括宽松的 CORS 默认值、每个 Ingress 的 auth-url 优先级， 以及 auth-url 变量插值差异。

边界在哪里。 兼容性涵盖的是运维人员主动选择的语义。 它不涵盖身份验证或 mTLS 强制约束静默失效。 如果提供者在失败时放行，而不是忠实重现不安全的上游默认行为，就属于漏洞。

此类已判定案例。 GHSA-4mr2-fg2p-w63c（CVE-2026-54762，解析 auth-secret 失败时放行）， GHSA-7vww-mvcr-x6vj（CVE-2025-66491，TLS 验证逻辑反转，导致未验证客户端证书），以及 GHSA-8rxv-jg7p-wvg3 （rewrite-target 路径遍历破坏路由级身份验证）。

身份验证中间件的正确性¶

常见报告。 身份验证中间件泄漏信息、接受不应接受的身份， 或将凭据转发到非预期位置。

我们的立场。 以下属于漏洞范围：凭据或身份处理跨请求、跨用户泄漏， 可观察的时间差异泄漏某个主体是否存在，以及凭据被转发到运维人员未授权的目标。

边界在哪里。 选择较弱的身份验证机制，或采用宽松配置， 是运维人员的决定。中间件未实现其文档承诺的行为，则由我们负责。

此类已判定案例。 GHSA-6x2q-h3cr-8j2h（CVE-2026-41263，BasicAuth 时间侧信道），以及 GHSA-g3hg-j4jv-cwfr（CVE-2026-32595，BasicAuth 时间侧信道与用户名枚举）， GHSA-p6hg-qh38-555r（CVE-2026-41181，Errors 中间件将 Authorization 和 Cookie 转发给独立服务），以及 GHSA-h2ph-vhm7-g4hp（CVE-2022-23469，调试日志包含 Authorization）。

可用性与资源消耗¶

常见报告。 某种请求模式耗尽内存、连接、文件描述符或 CPU， 或者使连接无限期停滞。

我们的立场。 未认证请求能够触发的无界资源消耗、panic 和缺失超时，属于漏洞范围。 仍受文档所述可配置上限约束的缓冲与排队，不属于漏洞。

边界在哪里。 我们要求实际复现，而不是仅凭阅读代码，你也应当如此。 这类问题的关键经常是每流限制是否真正限制了每连接的总量， 仅靠读代码可能在两个方向上都判断错误。如果没有在资源受限环境中的复现， 我们无法评估资源消耗主张，会要求补充。

此类已判定案例。 GHSA-4hjq-9h5c-252j（CVE-2026-27141，HTTP/2 帧触发服务器 panic）， GHSA-fw45-f5q2-2p4x（CVE-2026-26998，ForwardAuth 无界响应体）， GHSA-xw98-5q62-jx94（CVE-2026-26999，TCP 路由器连接停滞），以及 GHSA-cwjm-3f7h-9hwq（CVE-2026-22045，握手缺失超时而停滞）， GHSA-89p3-4642-cr2w（CVE-2026-25949，通过 STARTTLS 绕过 readTimeout）， GHSA-4vwx-54mw-vqfw（CVE-2024-28869，Content-Length 处理）， GHSA-7hj9-rv74-5g92（CVE-2023-29013，请求头解析）， GHSA-c6hx-pjc3-7fqr（CVE-2022-39271，HTTP/2 连接管理），以及 GHSA-8g85-whqh-cr2f（CVE-2023-47124，ACME 挑战放大）。

运维人员控制的配置¶

常见报告。 启用某个文档化选项后，或在文档要求运维人员加固的默认部署中， 能够触发某种行为。常见例子包括仪表盘和 API 可达性、snippet 注解、 错误请求头和变量插值。

我们的立场。 配置是可信输入，提供配置的所有提供者也同样可信。 任何能够写入 Traefik 所读取配置的人，本来就控制着路由。 以配置写入权限、运维权限或集群管理员权限为前提的报告，不属于漏洞。 当某个选项明确要求主动启用时，文档描述的效果就是其契约。

边界在哪里。 无特权、不受信任的客户端无需配置访问权限就能产生相同效果， 或某个文档化选项未实现所述行为，属于漏洞范围。

依赖与标准库问题¶

常见报告。 扫描器发现 Traefik 构建使用的 Go 模块或标准库中存在 CVE。

我们的立场。 只有 Traefik 在运行时能够到达易受攻击代码路径时，依赖问题才构成暴露风险。 仅用于构建或无法到达的路径不是 Traefik 漏洞；回复之前， 我们会使用 govulncheck 确认可达性。路径确实可达时，我们会发布公告， 因此安全公告历史中包含多项标准库 CVE。

边界在哪里。 如果能够证明从 Traefik 入口点到达漏洞代码的调用路径， 请明确写出；这正是决定结论的关键部分。

非 GA 代码¶

按照 CVE 政策， 仅影响候选发布版、测试版或开发分支的漏洞，会直接修复，不创建 CVE。

对这类问题创建普通议题，而不是安全公告。 确认所有 GA 版本都不存在该缺陷后， 就没有需要保护的已发布版本，也没有需要保密的内容； 普通议题比安全公告队列更快到达维护者。 在候选发布阶段报告问题，也是联系团队最有价值的时机： 此时修复只需要一个提交，而不是安全公告、向所有维护分支回移修复， 以及让已经升级的用户承受暴露风险。

如果相同缺陷在 GA 版本中也能触达，就不属于非 GA 问题， 应提交安全公告。 判断问题只影响候选版本之前，请检查已发布分支，并告诉我们具体检查了哪些分支。