Tomcat 那条漏掉 HTTP 方法的斜杠（CVE-2026-55956）

1 同一路径的两种方法，被选成了同一组策略

最小用例在 / 上放置两个集合：第一个只包含 GET，没有授权元素，表达公开读取；第二个省略 GET 并要求 ROLE1，表达其余方法都受保护。三种主体——匿名、ROLE1 和 ROLE2——分别请求 GET 与 POST，就形成了六个不会触碰真实业务的判断格子。只要 POST 的三种结果被压成同一种允许，问题就不再是笼统的“权限异常”，而是方法这一维在策略选择阶段消失了。

1.1 代码与处置图：默认斜杠分支漏掉了方法成员判断

1.2 先冻结一次完整决策，再判断是否发生绕过

从连接器把请求交给 Catalina 的位置开始，保存可信代理处理之后的真实输入。浏览器地址可能已经经过路径规范化、Context 路由、转发主机重建、入口改写和预认证；调查需要的是 Tomcat 实际看到的方法与路径。应同时捕获虚拟主机、Context 名称与版本、连接器、规范化的 Context 内路径、派发类型、选中 Wrapper、主体、角色、状态码，以及能够连接代理、容器和应用日志的请求标识。

查看观察结果之前，先把预期写成操作矩阵。最小矩阵包含三种主体状态：匿名、拥有 ROLE1 的用户、拥有其他角色的用户；再与 GET、POST 两种方法交叉。上游回归用例要求三种主体都能读取 GET，匿名与 ROLE2 不能完成 POST，只有 ROLE1 可以。六个格子先写清楚，公开读取成功就不会被误当作受保护写入也正常的证据。

把传输要求、认证过程和最终授权结果分开记录。未认证请求碰到角色保护时，可能先收到认证挑战，带错角色的已认证主体通常会走到禁止结果，公开操作则可以没有挑战直接成功；FORM、BASIC、CLIENT-CERT、JASPIC 与自定义错误页还会改变外观。状态码可能因机制不同而变化，真正稳定的判断是：每种主体是否进入了目标操作，以及被拒格子是否产生了任何业务副作用。

请求旁边还要冻结有效描述符。保存部署中的 WEB-INF/web.xml、继承自 conf/web.xml 的默认项、Web fragment、贡献 Servlet 安全策略的注解、程序化注册、角色映射与应用制品哈希。源码仓库里的文件不一定等于运行时策略，构建 profile、overlay、厂商封装或替代描述符都可能改变结果。关键配置是模式恰好等于 /，且集合成员依赖 http-method 或 http-method-omission。

同时准备无害的对照组。若应用已有安全测试资源，可以在精确模式、路径前缀模式或扩展名模式上执行同样的主体矩阵。受影响代码在这些分支本来就会调用 findMethod()，因此它们结果正确并不能替默认斜杠作证；但它们能够说明 Realm、主体映射和角色数据确实有能力执行同一份策略，问题集中在约束集合如何进入结果数组。

受影响版本只是必要条件。应用必须为默认 Servlet 模式 / 贡献安全约束，其中至少一个相关 web-resource-collection 通过包含或省略方式枚举方法。若斜杠约束适用于所有方法，缺少的谓词不会改变集合成员；若方法约束落在精确、前缀或扩展名模式上，请求会进入已经检查方法的分支。资产盘点必须保留这些差异，不能把每个 Tomcat 进程都标成同一种应用暴露状态。

对应操作还要能被会受到方法分区影响的主体触达。面向互联网会抬高优先级，内部管理站、制品浏览器、文档服务和嵌入式设备同样可能把操作交给不可信或低权限用户。相反，一台受影响容器若承载的应用都没有方法特定的斜杠约束，就缺少这条利用路径的配置前提。这个结论依赖部署描述符和运行时覆盖完整，证据缺口必须继续保留。

本漏洞也不能与“DefaultServlet 开启写入”类问题混为一谈。默认 Servlet 通常负责静态资源并全局映射到 /，其 readonly 配置会影响 PUT、DELETE 等操作。CVE-2026-55956 位于 Realm 的安全约束选择器，凡是落到默认映射策略的请求都可能受影响。写方法开启会改变后果，却不是源码缺陷的根本前提，仍需回到有效描述符逐项核对。

Apache 将问题定为中危，CNA 归类为 CWE-285 不当授权。Apache CNA 本身没有给出数值 CVSS 向量，因此不应再附加未经来源支持的分数。处置优先级应叠加本地事实：操作是否改变状态或读取受保护内容、哪些身份可以触达、公开集合是否会与受保护方法重叠、应用副本有多少、日志能否复原旧决策，以及临时上游控制是否覆盖规范化后的真实路径。

旧分支还需要单独的迁移风险栏。CNA 已确认的 7.0、8.5，仓库观察到的 10.0，以及其他退役线常被封装进设备、商业中间件或多年未重建的应用，Java 要求与 Java EE 到 Jakarta 的命名空间迁移可能让直接跨代升级失败。清单要同时记录厂商支持渠道、JDK 约束、Servlet API 代际、依赖框架、测试数据和可回滚窗口。临时方法限制只能为迁移争取时间，不能抹掉缺少维护线的事实；每次续期都应重新证明规则仍覆盖真实后端。

公开时间线为账本提供外部锚点：问题于 2026 年 6 月 15 日私下报告；CVE 编号在 17 日保留，三条修复提交也在当天落库；Apache 安全页把 10.1.56、11.0.23 的固定版本记在 22 日，把 9.0.119 记在 23 日；问题于 29 日公开。Apache 维护者公告把 finder 归功于 j0hndo。提交落库是源码事件，22 至 23 日条目是固定版本发布记录，二者都不能证明本地二进制何时改变；本地首次可达、发现、限制、替换和验证时间必须另存。

2 斜杠指向默认 Servlet，不等于整片站点

案子中央只有一个简单的斜杠，它在不同层次却承担着不同含义：浏览器路径、Context 路径、Servlet 映射、安全约束模式和资源查找中都可能出现斜杠。把它们视作同义词，会同时制造误报与漏报。CVE-2026-55956 命中的是 findSecurityConstraints() 最后的默认模式分支；运行到这里之前，Tomcat 已经选好虚拟主机和 Web 应用，接下来比较的是该 Context 内部的请求操作。

2.1 Context 选择完成后，才轮到默认映射

Catalina 先在选定虚拟主机内，以最长 Context 路径前缀挑选 Context。部署在 /docs 的应用接管其下请求，ROOT 应用接收没有更长 Context 命中的请求。这一步决定由哪个 Web 应用处理。与漏洞相关的 / 随后在选中应用内、针对 Context 内路径进行匹配。ROOT Context 与默认 Servlet 可能在部署上相遇，匹配语义却不是同一层。

Tomcat 在 $CATALINA_BASE/conf/web.xml 中全局声明 DefaultServlet 并映射到 /。它常用于静态资源，也可按配置提供目录列表，应用还能覆盖部分声明。按照 Servlet 映射规则，默认映射是在精确、最长路径前缀和扩展名映射都没有接管时使用的兜底项。它不是正则表达式，也不等同于 /*；后者属于路径映射，在优先级和请求路径行为上都有自己的规则。

以 /docs/manual/start.html 为例，连接器先接收请求目标，主机与 Context 选择把请求交给 /docs 应用，Context 内路径变成 /manual/start.html。若没有精确、前缀或扩展名 Servlet 映射接手，映射到 / 的默认 Servlet 才会服务资源。容器在允许派发继续之前，就要为这个 Context 内操作选出安全约束。

这也解释了反向代理为何无法单独证明 Tomcat 的决定。代理可以认证用户、改写路径或限制方法，这些控制很重要；它并不会自动重建完整的 Servlet 部署约束、最佳模式选择和 Realm 角色组合。若代理承担临时限制，规则必须作为独立控制记录，明确主机、Context、规范化路径和方法，并通过矩阵验证，不能把代理返回正常等价成容器已经修复。

发现工作因此可以收窄：在部署后的描述符与运行时对象中寻找解码值恰好为 / 的 url-pattern，再检查同一个集合是否含方法元素。不要因为应用路由以斜杠开头就全部告警，也不要因为公网 URL 带有 Context 前缀就排除。真正相关的斜杠存在于描述符处理后的 Web 资源集合中，请求比较发生在已经选中的 Context 之内。

2.2 Web 资源的身份由路径与方法共同决定

Jakarta Servlet 将安全约束定义为附着在 Web 资源集合上的授权与传输要求。集合用 URL 模式识别资源，再用 http-method 或 http-method-omission 识别 HTTP 操作。没有列出方法时，集合适用于全部方法；显式列出时只包含这些方法；使用 omission 时则包含被省略值之外的所有方法。方法并非后加的可选过滤器，它是资源操作身份的一部分。

Tomcat 把这层含义保存在 SecurityCollection。findMethod(String method) 的职责非常直接：判断集合是否适用于当前请求方法，并同时处理显式包含、显式省略与全方法三种情况。描述符解析没有丢掉数据，修复也不需要发明新解释。发生问题的函数手里已经有当前方法，并且在另外三种模式分支里一直调用这个 helper。

同一个模式和方法可能被多个安全约束描述，因此选择之后还要组合。带角色的授权约束会合并允许角色，全部已认证用户与特殊角色名遵循各自语义；包含授权元素却没有任何角色的约束会拒绝所有访问并压过其他组合。与本次回归最相关的一条规则是：命中的安全约束若没有授权元素，与角色约束组合时会允许未认证访问。

公开读取与受保护写入正依赖这些规则。GET 集合没有授权元素，它不该出现在 POST 决策里；另一个集合省略 GET 并要求 ROLE1，所以应成为 POST 唯一相关的授权要求。默认分支把公开集合也加入后，宽松组合并非 hasResourcePermission() 自己犯错，而是它对错误输入集合执行了规范规定的结果。

注解与程序化注册可以生成等价的方法特定约束。Servlet 6.1 会把方法无关的 @HttpConstraint 和多个 @HttpMethodConstraint 映射成包含 method 或 omission 的安全约束；可移植描述符对同一 Servlet 注册的精确模式还可能覆盖注解策略。因此，暴露复核必须在部署处理之后重建有效集合，不能停在应用仓库里搜索一段字面 XML。

在前端控制器应用中，这个区别尤其容易被误读。外部路由可能全部看起来像 /api/order，Servlet 实际只注册一个更宽模式，静态内容又由默认 Servlet 接管；安全约束的最佳模式还可能与最终处理业务的 Java 方法不同。复核时分别记录“选中哪个 Context”“约束使用哪个模式家族”“派发给哪个 Wrapper”“应用内部又走到哪个 handler”，四栏缺一就可能把框架路由表当成容器策略表。

HEAD、OPTIONS 与扩展方法也不能靠对 GET 的直觉推导。Servlet 和应用可能让 HEAD 复用读取逻辑，也可能单独覆盖；CORS 预检会经过认证器专门分支；WebDAV 还会出现 PROPFIND、LOCK 等方法。操作表应从有效集合与实际 handler 能力逐项得出预期，同时用 deny-uncovered-http-methods 的配置解释未覆盖方法。未知方法留在“待验证”，不要默认为等同 GET 或天然拒绝。

重建注解策略时还要尊重描述符的 metadata-complete、fragment 排序与精确模式覆盖规则。一个库升级可能带入新的 web-fragment.xml，一次构建优化也可能改变注解扫描结果；同名 Servlet 的程序化注册若遇到描述符已精确约束的模式，生效范围会受规范限制。记录每条有效约束的贡献者和被覆盖者，能够解释“源码里明明有注解、运行时为何没有这一行”，也能防止把未生效配置当成临时补偿。

可以把整个过程想成一张以“最佳 URL 模式 + 请求方法”为键的操作表：路径匹配挑出模式家族，方法成员判断挑出本次真正发生的行，组合规则计算传输与授权要求，认证和角色检查最后执行。CVE-2026-55956 只在默认模式家族漏掉第二步。下一章打开这个选择器，看方法令牌怎样在第四个抽屉里消失。

3 前三个抽屉都带着方法，第四个却把它落下了

现在可以把调用路径收进一个方法：RealmBase.findSecurityConstraints(Request, Context)。它接收当前请求和已经选定的应用 Context，读取 Context 内请求路径与 HTTP 方法，再按 Servlet 映射顺序遍历所有 SecurityConstraint 及其 SecurityCollection。这个函数只负责挑选策略对象，不负责最终授权；它返回的数组会被后续环节组合并执行。

3.1 映射优先级在源码中展开成四轮选择

第一轮寻找精确匹配。函数逐个查看集合里的模式，与请求路径比较；即使路径完全相等，也只有在 securityCollection.findMethod(method) 返回 true 时才把父约束加入结果。只要存在精确模式，Tomcat 就返回这一轮的结果，不再让更弱的模式家族贡献约束。路径与方法在策略对象进入数组的同一处被联合检查。

第二轮处理以 /* 结尾的路径前缀。代码追踪最长命中长度，更长前缀出现时会清除较短候选留下的结果，同时保留相同最佳长度上的组合；方法成员判断仍在准入条件里。这个细节会直接影响现场：更具体的保护前缀一旦命中，默认斜杠不会参加；映射配置稍作改变，同一个外部 URL 却可能换到另一轮选择。

第三轮处理 *.jsp 一类扩展名模式。代码在最后一个路径片段内找到句点并比较后缀，确认命中后依旧先调用 findMethod(method) 才加入父约束。2026 年另有一条 Tomcat 公告修正多个扩展名约束组合错误，那是独立问题。一个资产可能同时需要两项修复，验证其中一项不能替另一项结案。

第四轮是模式恰好等于 / 的兜底。受影响代码看到斜杠就把 matched 设为 true，循环结束后直接追加父 SecurityConstraint。当前方法变量仍在作用域内，集合也完整保存了包含与省略列表，二者却没有进入判断。周围抽象并没有要求跳过方法，只是前三轮都有的一个合取条件在这里缺席。

四轮都面对“父约束包含多个集合”的结构。一个 SecurityConstraint 可以放若干 SecurityCollection，只要其中某个集合命中获胜模式，父对象就可能进入结果。也正因此，修复不能等父对象全部积累完再粗略过滤；到那时已经丢失“究竟是哪个子集合让它进来”的信息。上游把方法判断放在斜杠模式旁，正好位于集合成员仍然清晰的位置。

3.2 少掉的合取条件改变了集合，没有改写角色算法

漏洞条件等价于 pattern.equals("/")；修复后变成 pattern.equals("/") && securityCollection.findMethod(method)。请求字节没有重新解析，角色没有凭空增加，认证器也没有换掉。新增谓词只做一件事：若某个集合不包含当前方法，就不能由它提名父约束进入返回数组。默认模式由此恢复与另外三种模式一致的“路径 + 方法”不变量。

代入上游 POST 用例，公开 GET 集合对 findMethod("POST") 返回 false，它的父允许约束不再进入结果；省略 GET 的集合对 POST 返回 true，要求 ROLE1 的父约束继续保留。换成 GET 时两者结果反转。主体尚未参与，选择器已经为两种操作准备好各自应有的策略集合。

漏掉方法也可能错误附加更严格的约束。只针对某种方法的空授权元素若被带到其他操作，可能把本应允许的请求全部拒绝；只为某操作配置的传输保证也可能被错误交给另一个方法。公开漏洞以不当授权为核心，因为宽松组合能形成角色绕过；本地影响复核仍应比较斜杠上所有方法特定的授权与传输属性，避免只盯一个 200 响应。

源码形状也提供了有范围的反证。有效最佳模式若是精确、最长前缀或扩展名，这个缺失谓词不会被执行；斜杠集合若没有包含或省略方法，findMethod() 本就会对所有方法返回 true，修复不改变其成员；上游控制若在 Tomcat 之前拦住操作，利用可能暂时不可达，容器代码仍旧受影响。这些结论帮助排序，却不能替代升级。

审查厂商回补时，不要只搜索 CVE 编号或版本字符串。定位交付源码或反编译代码中的 findSecurityConstraints()，找到最后的默认模式循环，确认集合的方法谓词支配父约束追加；再检查厂商是否增加了其他选择路径。helper 改名并不重要，等价语义才重要。等到角色检查阶段再补一个条件，已经无法恢复集合成员关系。

若需要在隔离环境观察选择结果，可以开启 Realm 的细粒度 trace，并用单一无害请求配合固定描述符，记录每轮模式命中、当前方法和最终数组；日志等级变更前评估性能与敏感信息，实验后立即恢复。更稳妥的方式是把上游测试改造成一次性 harness，直接断言返回数组包含哪些父约束。两种方法都应以对象哈希和测试代码版本为前提，避免某人在新构建上观察、却声称解释了旧二进制。

等价回补审查还要检查控制流。精确命中是否会提前返回，最长前缀是否清除短候选，扩展名命中是否保留同模式上的多个约束，默认轮次是否只在前三轮无结果时运行，resultsToArray() 如何处理空列表。单行 diff 可以相同，周围厂商改造却可能让它永远不执行或在错误位置追加对象。审查记录既保存谓词，也保存能到达谓词的最小调用路径与对应回归结果。

方法比较应使用 Tomcat 实际传入的字符串，不在测试工具中自作主张地转大写。HTTP 方法在协议与 Servlet API 中有既定处理，代理、框架或自定义连接器若做过转换，需要以连接器后的值为准。测试 harness 同时记录原始请求行与 request.getMethod()，发现差异就单列为路由或规范化问题。这样能避免测试端“帮忙修正”输入，导致 findMethod() 在真实流量中的行为没有被覆盖。

源码证据与运行时证据在这里相接。源码锁定错误的准入规则，映射数据证明请求是否来到第四轮，有效描述符证明是否存在不属于当前方法的集合，返回策略数组或确定性回归用例证明结果。任何单件证物都不能独自承担完整结论，四者合起来才能复原那次异常成功究竟怎样产生。

4 权限引擎拿到错误策略，也会认真算出错误答案

选择器的返回值会成为后续安全流程共享的输入。AuthenticatorBase.invoke() 很适合当作叙事主线，因为它清楚展示顺序：找出适用约束，检查传输要求，判断是否需要认证，在必要时建立身份，最后询问 Realm 该主体是否具有资源权限。一张无关的公开约束卡只要混进数组，后面多个完全正确的决定就可能合成错误结果。

4.1 同一个约束数组依次走过传输、身份和角色

认证器在安全处理开始不久便调用 Realm 的 findSecurityConstraints(request, context)。返回 null 代表没有适用约束，流程可以不做容器托管授权继续；非空数组则被保留给后续检查。它不是给调试页面看的元数据，而是本次请求计算传输与身份要求的策略输入。集合选错之后，下游没有另一份原始描述符可供重来。

hasUserDataPermission() 首先检查集合中的 user-data-constraint。根据合并后的传输保证和当前连接器，Tomcat 可能继续、跳转到受保护连接或拒绝。一个没有传输要求的额外集合也可能影响本应要求机密连接的方法。CNA 把漏洞描述为不当授权，但共享选择机制意味着本地复核仍需检查方法特定的传输策略。

随后，认证器根据选中约束判断是否需要身份。缓存主体、JASPIC、预认证、CORS 预检设置和具体认证机制会影响身份怎样建立、挑战怎样呈现，它们不会重新推导丢失的方法成员关系。若策略集合已经表示该操作可未认证访问，再可靠的凭据验证器也可能根本没有机会运行。身份提供方没有失败日志，不能反推出请求经过了正确授权。

最后，hasResourcePermission() 组合授权元素并检查主体角色。它的职责正是根据传入约束执行访问控制。回归用例中，数组错误包含了一个没有授权元素的公开父约束；Servlet 组合规则将其存在解释为允许未认证访问，所以函数返回 true 在自身输入下完全一致，只是应用设计者为 POST 写下的 ROLE1 要求已被错误集合冲淡。

这条顺序改变了日志解读。身份系统没有失败事件，不代表错误密码被接受，认证可能被跳过；角色服务显示组成员正确，也不能替请求洗清，因为宽松组合可能让角色失去作用；代理日志里的 200 只证明结果，无法说明哪些约束促成结果。调查必须把容器映射、有效策略、主体状态和应用结果连接到同一个请求标识。

4.2 六个无害格子足以显出被污染的组合

上游测试创建两个父约束。第一个含模式 /、方法 GET 的集合，没有授权角色；第二个使用同一模式，省略 GET 并声明 ROLE1。测试再创建匿名请求、拥有 ROLE1 的主体和拥有 ROLE2 的主体。它不需要危险业务操作或攻击载荷，只在受控对象上调用选择与权限方法。

对 GET 而言，三种主体都应获准：公开集合属于这个操作，互补角色集合省略了 GET，不该进来。对 POST 而言，匿名与 ROLE2 应被拒，ROLE1 应获准。六个断言同时覆盖显式方法、omission 和角色结果。若只测匿名 POST，一个过度收紧、连正确角色也拒绝的修复也可能被误判为成功。

受影响代码在斜杠轮次对两种方法都加入两个父约束。处理 POST 时，公开父约束触发宽松组合，三种主体的预期差异被压平成允许；处理 GET 时，额外角色父约束在同一组合规则下不会消除公开许可，所以健康检查仍然显得正常。这种不对称正是“公开读取一切正常、受保护操作悄悄失守”能够长期存在的原因。

真实描述符会产生更大的矩阵：传输保证、空角色拒绝、全部角色、全部已认证用户、每个父约束的多个集合，以及注解和 overlay 带来的重叠约束都可能参与。每种方法的结果都要从部署后的有效集合推导，不能靠某一个 XML 片段猜测。上游六格是缺陷的最小证明，并不等于完整的应用授权测试。

最终后果取决于应用副作用。一个成功 POST 可能只是忽略请求体的无害路由，也可能触发资源变换、管理动作或前端控制器中的业务逻辑。CVE 证明容器策略可能弱于声明，却不会替现场证明哪项动作已经发生。历史复核必须把异常获准的方法连接到应用审计、下载记录、状态变化和下游调用后再判断影响。

组合表应把授权与传输拆成两个独立输出。对每个方法，先列出选择器应返回的父约束，再计算授权元素组合，最后计算 user-data-constraint 的连接要求；把匿名、正确角色、其他角色分别代入。这样可以看见三种不同异常：公开约束使角色要求消失、deny-all 被错带导致可用性下降、无传输要求的集合让保护连接变弱。只用一列“allow/deny”会隐藏后两类结果，也很难解释跳转或挑战。

身份数据同样要按请求时刻固定。Tomcat 的缓存主体、Session、JASPIC 和上游预认证可能让“当前目录角色”与“容器本次请求使用的主体”不同。测试记录需包含 getUserPrincipal()、认证类型、应用角色映射和会话是否复用；历史调查则保留身份提供方事件与当时组成员。若代理注入身份 header，还要证明只有可信代理能到达连接器，并说明 Tomcat 是否实际消费该身份。否则，一条角色正确的目录截图无法解释容器为何跳过认证。

缓存也是容易制造错觉的一层。认证器会为受约束资源设置抑制共享缓存的 header，但公开集合被错误带入后，响应缓存策略也可能与设计者预期不同；代理或 CDN 若缓存了成功读取，再次请求可能根本没有抵达 Tomcat。验证时为合成请求使用唯一安全对象或明确绕开缓存，并同时检查 Age、Via、缓存命中标识和后端请求日志。历史分析则把缓存返回与容器授权事件分开，避免把一份旧响应算成多次绕过。

一条有力度的本地结论应具备如下证据结构：受影响版本处理了可达请求，选中 Context 的有效默认模式约束按方法划分操作，斜杠轮次加入了不包含当前方法的集合；Servlet 组合语义因此削弱授权，主体得到与预期矩阵不一致的结果。每个分句都需要本地证据；缺少任一项就调整信心与范围，全部证明后才能从描述符一路解释到响应。

5 资产清单开始记录可验证对象

单条请求的机制清楚之后，问题才适合扩展到整片资产。进程名、软件版本、应用负责人和公网标签仍不够：暴露属于一个正在运行的组合——Tomcat 实现落在已确认受影响或尚未排除的退役线，有效应用策略在默认模式上按方法分流，同时存在一个授权结果会因错选集合而改变的可达操作。清单必须分别保存这三项事实及其证据来源。

5.1 运行身份比版本标签更可靠

三条维护线要记录完整版本身份。Banner、编排标签和包数据库只能提供线索，它们都可能与 Java 进程实际加载的类发生漂移。保存启动命令、服务单元或容器 digest、classpath、catalina.home、catalina.base、包来源、镜像 digest，以及真正提供 RealmBase 的 Catalina JAR 哈希。若厂商 shaded 或重打包 Tomcat，先把该类映射回上游代码，再套用版本结论。

Tomcat 的 parallel deployment 还允许多个应用版本共享一个 Context 路径。Context 文档说明，携带既有会话的请求可能继续附着在旧版本，而无会话请求选中最新版本。同一个 URL 因而可能同时通往已更正应用和仍活跃的旧副本。盘点每个 Context 名称、Context version、会话、部署时间与底层运行时；负载均衡器显示新池健康，不能证明粘性会话不再抵达旧副本。

嵌入式 Tomcat 同样需要这套严谨度。Spring 类服务、设备、启动器和定制 Java 产品可能完全没有熟悉的安装目录。依赖锁文件或 SBOM 只能指出候选版本，真正交付的制品才证明包含什么。检查嵌套 JAR、基础镜像层与厂商 overlay，再把每个哈希关联到运行工作负载。一个仓库可产出多个区域镜像，一个可变 tag 也能指向不同内容，结案单位必须是不可变制品。

版本可信以后再加入可达性，且不要把它压成“公网/内网”两格。记录连接器与监听地址、虚拟主机、代理路由、进入 Tomcat 前完成的认证、允许方法、客户端群体，以及低权限身份能否触达应用。只在员工网开放的管理服务仍可能把受保护操作暴露给大量普通账号；代理只允许 GET 的公网端点可能有强临时控制，容器与策略仍需替换并准备回滚。

最终状态要写得足够直白：“受影响构建，策略未知”代表证据缺口；“受影响构建，存在默认模式，但没有方法分流”是配置观察；“受影响构建，斜杠策略按方法分流，保护操作可达”才是确认暴露；“固定构建，矩阵未跑”说明验证尚缺；“固定构建，有效策略已保存，六格通过”才是可辩护的技术关闭。这些标签会阻止缺失描述符被偷偷翻译成安全。

5.2 有效描述符会说明斜杠究竟从哪儿来

应用仓库只是策略重建起点。Tomcat 会组合应用 WEB-INF/web.xml、容器默认项、按顺序处理的 web-fragment.xml、发现的注解、程序化 Servlet 注册与部署覆盖；Context 还能通过 altDDName 指向替代描述符，安全角色和 role reference 也可能在部署时映射。源码搜索没有发现字面斜杠，不能在这些贡献者尚未解析时关闭暴露。

logEffectiveWebXml 可在应用启动时输出组合后的描述符，但 2026 年 6 月同一批安全版本还修复了 CVE-2026-55276：旧输出可能漏掉特殊角色和空授权约束。这些细节恰好会改变组合结果。把固定版本日志当作一项证据，同时保存原始贡献文件，并用运行时对象或受控部署核对关键集合；不要因为文件名叫 effective 就默认旧日志完整。

把结果规范化成操作表。每行包括虚拟主机、Context 名称与版本、解码 URL 模式、模式家族、包含方法、省略方法、授权元素是否存在、角色、全部角色标记、全部已认证用户语义、空角色拒绝、传输保证、来源与优先级。尤其要保留“没有授权元素”和“有授权元素但没有角色”的区别：前者在组合中会放宽，后者会拒绝所有访问；若统一扁平化成 roles: empty，案件原因就被数据管道抹掉了。

模式家族也必须单列。/、/*、空 Context-root 模式、/admin/* 和 *.jsp 不是写法变体，它们会进入不同轮次并遵循不同优先级。保存作者写下的值和 Tomcat 使用的解码值，再给每种模式关联一个安全代表路径。这样搜索引擎、YAML 序列化或表格清洗就不会把受影响默认映射悄悄改造成普通路径映射。

随后用稳定标识把策略制品与版本、可达性连接。记录 Catalina JAR 哈希、WAR 哈希、规范化策略哈希、Context version、节点或镜像 digest 和捕获时间。任意一项变化，旧暴露结论自动过期并触发重评。滚动部署尤其需要这样做：同一个服务名后的两个 Pod 可以运行不同 JAR 或 WAR，访问日志外观却几乎相同。

采集方式要适配资产形态。传统主机从服务管理器、进程命令和文件清单三处交叉；容器从运行 digest、镜像层与挂载配置交叉；Kubernetes 还要保存 Deployment、ReplicaSet、Pod UID 与实际 image ID；设备则依靠厂商清单、管理接口和升级包。任何自动脚本输出都附带权限范围与失败列表，扫描不到的目录、离线节点或只读设备明确留在“未覆盖”，不能因为命令返回零错误就假定资产完整。

策略证据还要有保鲜期。应用热部署、Context reload、注解扫描结果、全局 conf/web.xml 更新和角色映射变化，都可能让昨天的规范化表过期。为每次捕获保存启动序列号或部署事件标识，并在运行时哈希、WAR 哈希、全局配置哈希任一变化时重新生成。若节点之间结果不同，先保留差异并追查部署漂移，不要为了得到一条整齐 CMDB 记录而选一个“代表节点”覆盖其他实例。

盘点结束时，每行都应有负责人和下一步。维护线的确认暴露节点进入固定版本与矩阵测试；退役线进入受支持平台迁移，必要时增加方法限制；策略未知行触发描述符重建；不可达行保存上游控制证据与漂移监控；固定版本行直到部署哈希和授权矩阵同时一致才关闭。资产表从产品名清单变成了一组可以被证伪或证实的声明。

6 一处合取修复，仍需要完整发布证明

源码差异只有一个方法检查，生产保证却远大于这一行。三条维护分支各有等价提交，应用可能依赖同批版本的其他 Servlet 行为，滚动升级又可能让旧进程在新包可见之后继续接流量。修复必须从上游源码一直追到交付二进制、有效策略、授权矩阵和旧实例彻底退出。

6.1 三条分支提交恢复同一条准入规则

Tomcat 9 的修复提交为 a0374c450970760efafbd8806a1db278830ba7bd，10.1 为 9c3b1efb74fd04f77639720af1d48a8f664ad9bb，11 为 3f6bd2ba5e53d1f340bbe5ad2d42a28b29440b7a，三者都在 2026 年 6 月 17 日落库。它们把默认模式条件从只测试 pattern.equals("/")，改为同时测试 securityCollection.findMethod(method)。源码行号略有差异，恢复的不变量完全相同。

条件放置位置与条件本身同样重要。helper 在 Tomcat 正查看某个 SecurityCollection 时求值，并发生在父 SecurityConstraint 进入结果数组之前。这样，排除当前方法的集合无法提名父对象。若等父对象积累后再过滤，就失去了父与命中子集合的关联；后面的角色检查也推不出哪个集合原本不该出现。回补必须保留这个决定点。

每条上游提交还在 TestRealmBase 中加入 testDefaultServletConstraints()。测试创建公开 GET 斜杠集合，以及省略 GET 且要求 ROLE1 的互补集合；再创建匿名、ROLE1 与 ROLE2 三种主体，检查六种组合。新增的 67 行测试比生产代码那一行更完整地表达意图，因为它证明公开、授权成功和拒绝在修复后仍能共存。

分支等价性可以保存为审查表：上游家族、固定版本、完整提交哈希、源码路径、旧谓词、新谓词、测试方法与六个预期结果。发行版若用不同提交号回补，就把 diff 与测试映射进表。仅提供二进制的厂商应给出公告和构建标识；在获授权的隔离环境中，可对交付类做反编译或插桩来验证准入条件。没有来源的版本后缀不是强结案证据。

6.2 哈希与矩阵一致后，部署才真正关闭

从可信发布渠道或获批的可复现流水线生成候选制品。使用上游二进制时校验 Apache 签名与 digest，保存包或镜像 digest 和 Catalina JAR 哈希；打包应用还要用 SBOM 指出嵌入的 Tomcat 组件。测试开始前先把这些值写入变更记录，确保通过矩阵的对象正是随后进入生产的对象。

用有效描述符的代表副本部署候选环境。框架生成注解、排序后的 fragment、全局默认项、角色映射、认证机制、连接器和代理 header 都可能改变响应外观，即使源码缺陷只在一个选择器。使用没有生产权限的合成账号与不会产生永久影响的无害端点。应用若没有安全代表操作，就运行上游对象级回归，再用同一描述符和应用制品搭建一次性环境。

先跑六个核心格子。公开方法下，匿名、指定角色和其他角色都应获得公开结果；受保护方法下，匿名不能完成操作，指定角色应成功，其他角色也不能完成。认证挑战与最终状态分开记录，因为 BASIC、FORM、CLIENT-CERT、JASPIC 和错误页会呈现不同拒绝形态。稳定判据是请求是否抵达目标操作。

再从规范化策略生成扩展矩阵。包含每个显式方法、每组 omission 接纳的至少一种方法、应用扩展方法的安全代表，以及有特殊行为的 OPTIONS、HEAD；同时安排精确、前缀、扩展名和默认模式重叠，验证优先级。若启用 deny-uncovered-http-methods，加入未覆盖方法并确认 403 发生在业务执行之前。

把副作用当作首要断言。每个拒绝格子前后比较测试记录版本、对象存储写入、文件哈希、队列消息、下游请求、缓存变化与应用审计。状态码无法独自证明写入前已停止，异步任务和自定义错误处理都可能造成错觉。指定角色的允许格子只产生一次预期、可控的效果，被拒格子应完全没有效果。

通过不可变替换上线，再证明流量全部收敛。Canary 阶段通过受认证管理通道查询精确构建，按池成员抽样服务器端请求标识，并核对粘性会话、parallel context、蓝绿池、备用节点和灾备镜像。确认回滚安全后删除或隔离旧镜像。一个已经 drain 却能被自动重新拉起的节点，仍属于暴露资产。

回滚方案要同时守住安全与可用性。尽量准备“旧应用制品 + 固定 Tomcat 运行时”，避免整套容器退回受影响构建。若兼容问题迫使暂时回退，使用单独验证过的代理或应用方法规则覆盖准确主机、Context、路径和受保护 verbs，缩小可达性并设置短期到期时间。变更记录必须写清楚哪些证据可以移除临时控制。

兼容性测试要覆盖应用真正依赖的容器行为：Servlet API 版本、JSP 编译、Session 序列化、Realm 与 Valve 配置、反向代理 header、静态资源、错误页和启动扫描。测试失败时先定位是应用、配置还是新版本行为，不直接把整套环境退回旧运行时。若必须分阶段迁移，把高后果操作优先放进固定池，并通过路由证据证明没有请求落到旧池；每个阶段仍跑自己的矩阵和副作用断言。

最终关闭是一串彼此相符的对象：上游提交证明规则已纠正，版本或厂商记录把规则关联到构建，包和 JAR 哈希说明测试了什么，有效策略哈希说明执行了什么，矩阵证明公开与保护操作仍然分明，部署证据说明所有服务实例都使用候选，退役证据阻止旧制品回来。任何一环换了对象，都应重新验证，而不能沿用旧结果。

7 历史要靠方法、主体和状态重新拼接

当盘点找出配置暴露部署，问题便从“能否发生”转成“哪些旧请求得到了不该拥有的权限”。CVE-2026-55956 没有独特载荷、进程名或网络签名；历史复核只能围绕同一次决策，连接方法、有效策略、事发主体、受影响运行时、应用结果和状态。

7.1 寻找那些本应遇到挑战却成功的操作

历史窗口从每次本地部署推导，不只看公告日期。对一个制品而言，起点是受影响 Tomcat 构建与相关策略首次共同运行且路由可达的时刻；终点是最后一个服务副本被替换，或独立验证过的方法控制开始生效。把滚动发布、回滚、自动扩缩、灾备和 parallel deployment 事件都放进窗口。6 月 15 日私报和 29 日公开解释认知时间，却不能代替本地首曝时间。

从规范化操作表生成调查行。每行写明主机与 Context、获胜的默认模式、受保护方法集合、允许角色、传输要求、应用操作和安全预期。先处理会改变状态的方法与会返回敏感内容的保护读取，再覆盖每个显式或 omission 推导的方法，也包括前端控制器或默认 Servlet 行为抵达的路由。宽泛的 CVE 搜索由此变成日志可以回答的一组具体决策。

代理侧恢复时间、请求标识、符合本地隐私规则的客户端身份、改写前后主机与路径、方法、上游认证主体、状态、长度和后端；Tomcat 侧恢复连接器、虚拟主机、Context、Context 内路径、方法、状态、字节、经策略允许的会话哈希、remote user 和请求标识；身份侧恢复认证时间、主体、角色或组快照与成员变更。连接前先校准时钟，并记录误差。

成功响应只是线索。有些 POST handler 只做只读检索，有些通过授权后仍返回校验错误，还有应用会在程序代码中有意允许某些低权限主体；反过来，FORM 工作流可能用 302 或 200 包装认证失败，自定义错误处理也可能在 403 前已经触发副作用。解释必须同时包含状态、路由行为、主体与状态变化，并保留正常流量样本来识别重试、健康检查和自动化。

把候选请求连接到应用审计和业务记录。可用证据包括被读写对象标识、记录前后版本、配置修订、下载审计、文件哈希、对象存储访问、队列消息、管理动作和下游服务调用。请求标识最理想；缺失时可以使用时间、会话、主体、路由、对象标识与后端的有文档组合，但要衡量碰撞风险。多个请求都适配同一窗口时，不应伪装成一对一关联。

角色历史与请求历史同样关键。用户今天拥有 ROLE1，事发时可能没有；目录到应用角色的映射也可能随发布改变。保存事件时刻的应用角色映射、组成员快照、身份提供方事件和服务账号分配。若无法恢复旧角色数据，就把请求标成未决，不能套用当前成员。漏洞决定“是否要求角色”，影响判断仍要知道主体当时是否已经具备角色。

缺少认证事件的含义很有限。源码流程已经表明，多余公开约束可能让 AuthenticatorBase 判定无需认证，因此日志里根本没有失败登录。调查应寻找受保护方法成功且主体为空、主体不在允许角色集合，或只有上游身份而没有容器身份的情况；再与固定版本的隔离行为比较，理解选择纠正后哪些字段会出现。

按层次记录信心。确认策略异常需要受影响构建、完整有效描述符、映射到默认轮次的请求、不属于公开集合的方法，以及异常授权结果；确认影响还要增加受保护读取或可持久状态变化。可疑事件缺少部分连接但违背矩阵；干净区间意味着所有相关操作都有足够遥测且没有矛盾；不可观察区间揭示的是留存缺陷，不能写成“未发现问题”。

7.2 先限制操作、保存证据，再用无害矩阵复验

1. 遏制从后果最高的操作开始。若受保护方法可以改配置、发布内容、调整账号或读取敏感制品，就在可信代理或应用层先限制精确的主机、Context、路径和方法组合，同时准备升级。用同一身份矩阵验证规则不会把流量导向其他 Context 或后端。全面禁止某方法可能打断业务，窄规则则必须覆盖真实改写与规范化过程，并明确由哪一层作决定。
2. 重启或重新部署之前保存证据。捕获进程命令、已打开 JAR 路径、容器与镜像 digest、Catalina 与应用日志、代理路由、当前部署与 parallel version、有效描述符来源、策略制品、身份映射和业务状态快照；为导出文件计算哈希并记录采集时间。日志位于远端时还要保存查询和留存设置。重启会轮换本地日志、结束粘性会话并抹掉旧 Context version 与请求的关联。
3. 受支持线升级到 9.0.119、10.1.56、11.0.23 或后续验证版本；已列出的 Tomcat 7、8.5 区间、Tomcat 10.0 以及所有其他退役线都应迁到维护目的地。设备厂商控制运行时时，用准确产品构建号开单并要求提供上游修复映射。在供应制品完成源码或二进制复核与操作矩阵之前，继续保留临时方法规则。只提 CVE、却没有构建、补丁映射和测试证据的保证声明，仍未回答核心问题。
4. 凭据与会话按观察影响处置。选择器缺陷本身不会泄露密码或伪造身份，因此没有证据时不必把全员改密当成固定动作。若历史显示未授权账号变更、token 创建、secret 读取、会话修改或管理动作，则撤销相关凭据和会话、恢复可信配置并检查依赖系统。确认暴露但遥测无法排除保护读取时，再依据潜在材料的敏感度与寿命决定轮换。
5. 恢复测试先在生产外完成，再变成合成监控。重跑方法乘身份矩阵，确认拒绝格子没有副作用，验证传输保证并逐实例核对；随后增加生产安全探针，使用不变更或一次性对象、指定合成角色与不同角色身份。若拒绝格子变成成功、固定运行时哈希变化、规范化策略哈希漂移，或退役节点重新加入，就立即告警。

业务负责人需要的是具体说明：哪些应用与操作、何时受影响、哪些身份可以触达、牵涉何种数据或状态、现有遥测能证明什么、哪些事件已确认或仍未决、当前控制与剩余不确定性。不要把“中危”机械翻译成统一业务影响。静态文档服务和管理部署台可以共享同一源码缺陷，后果却完全不同，操作表正好提供区分它们的语言。

一套务实节奏能同步源码、资产和事件工作。最初几小时冻结证据、重建策略并限制高后果操作；首日验证固定制品、迁移服务池并启动历史连接；随后几天完成退役线迁移计划、调查状态变化、审查厂商回补，并把矩阵转成持续控制。每次交接都携带制品哈希与策略哈希，避免一个团队验证 A 对象、另一个团队部署 B 对象。

案件还应保存无害的负面发现。精确、前缀和扩展名约束矩阵通过，说明 Realm 与角色库在选择准确时能执行同一策略；没有方法特定默认集合的应用，要记录为何本路径不适用；被上游方法规则拦截的路由，保留规则、测试与监控证据。这些事实可以收窄影响，却不意味着受影响运行时能无限期保留，也不替其他策略缺陷作结论。

实际查询宜分成两轮。第一轮只用低敏字段筛选：受影响后端、Context、规范化路径、保护方法、状态与主体是否为空，形成候选集合；第二轮由有权限的调查者按案件编号连接身份历史和业务对象，减少不必要的数据展开。查询语句、索引版本、时区转换、去重规则和返回行数都归档。若日志采样或字段截断，计算可能漏掉的请求比例，并把它写入信心等级，避免“查询无结果”被误读为“事件不存在”。

不可观察区间同样需要处置计划。可以根据代理总量、Tomcat 留存、应用审计与状态快照交集，画出每种操作真正可证明的时间段；对关键缺口评估数据敏感度、主体可达性与上游限制，再决定通知、密钥轮换或加强监控。后续修复则把请求标识贯穿代理、容器和应用，把 Context version 与制品 digest 写入内部遥测，并验证时钟同步。证据能力的改善与漏洞补丁分开验收，两者都完成才算响应成熟。

检测规则要先经过固定版本基线，减少误报。公开机器人、监控探针、浏览器自动 HEAD、CORS OPTIONS 和失败重试都可能呈现“非 GET + 成功”，却不对应受保护操作；真正高价值信号是方法落入保护集合、事件时主体不满足角色、后端由受影响构建处理，并有应用执行迹象。把每项条件独立存储后，规则可以按证据齐全度排序，分析员也能看见缺少哪一项。

8 授权最终成为一张可版本化的操作表

授权从容器选择策略对象时就已经开始，早于日志里可见的角色比较。若发布工程只给应用代码做版本，却把有效安全策略当成环境背景，一处谓词缺失就可能直到事故后重建方法矩阵才显形。更稳妥的做法，是把规范化操作表及其测试结果作为普通发布制品。

8.1 生成一次策略制品，让每道门禁都消费同一对象

在受控应用部署或构建步骤中，使用目标 Tomcat 家族解析所有描述符来源，生成规范化操作表。保留作者模式与解码模式、模式家族、方法包含与省略、授权元素是否存在、角色语义、传输保证、贡献来源与优先级，再加入应用哈希、Tomcat 组件身份、Java 版本和生成工具版本。哈希前采用规范顺序，使语义相同的输出稳定，真正策略变化留下可审查 diff。

编译器必须保留通用配置工具常抹平的差异。授权元素缺席与授权元素为空分别代表允许与拒绝；特殊角色名有规定语义；方法列表缺席代表所有方法，omission 代表补集；/、/*、空 Context-root、前缀与扩展名走不同路径。若这些状态被压进同一个 null 或空值，schema 校验就应失败。

从操作表直接生成测试。为每个获胜模式挑选安全代表路径，为每种方法分区按需要创建公开、指定角色、其他角色和匿名用例，再加入传输与 deny-all 情形；安排精确、更长前缀、扩展名和默认候选同时存在。预期结果由 Servlet 组合规则与应用角色声明计算，部署后的容器成为被测系统。策略或运行时一变，矩阵自动再生。

把上游六格保留为永久一致性夹具。它足够小，可以针对每个批准的 Tomcat 更新与厂商构建运行，又能准确覆盖默认模式缺陷。再加入精确、前缀和扩展名夹具，防止将来重构修好一轮却从另一轮掉出方法谓词；组合用例则覆盖公开、普通角色、全部已认证、全部角色、deny-all 与传输保证。这套小测试会成为 Servlet 规范的可执行读本。

把策略哈希与矩阵结果附在部署证明上。准入控制可以拒绝 Tomcat 版本不在批准集合、Catalina 哈希未知、策略哈希未评审，或测试证据属于另一个制品的工作负载。运行时盘点再比较实际加载类与应用哈希。生产环境无需暴露公网版本 Banner，构建与运维仍能通过不可变身份接上；一旦不一致，调查直接从具体对象开始。

日志也要使用操作表能消费的语言。在符合隐私规则的前提下记录请求标识、选中主机与 Context version、规范化路径、方法、主体或匿名状态、角色判断、结果与应用审计标识；条件允许时，在内部结构化遥测中加入获胜模式家族和不敏感的策略版本。保护并按策略留存这些记录，目标是解释一次操作为何获准，不是收集凭据、请求正文或敏感响应。

对策略 diff 做语义评审。斜杠上新增公开方法、删除 omission、增加无授权元素的重叠约束、把 /* 改为 /、移除传输保证或改变角色映射，都应由负责人显式批准；单纯 XML 格式变化则在规范化后消失。审查者由此聚焦操作结果，不会被大量无意义差异训练成闭眼通过。

漂移控制闭合循环：定时任务比较部署的 Tomcat、WAR 与策略哈希；合成矩阵抽样最重要的公开和保护操作；资产系统标记退役家族与来源未知回补；日志质量检查确认请求标识、Context version、方法和主体仍能连接。任何一项失败，响应者都从本案使用的同一组对象出发，无需临时发明一套词汇。

生成器和测试 harness 本身也属于安全敏感软件。固定依赖，评审方法集合展开和模式优先级改动，并保留由 Servlet 规范导出的 golden fixture。给编译器输入多个集合共享父约束、相同模式跨多个约束、空授权、method omission、空 Context-root，以及斜杠与更长前缀共存等棘手描述符；再在一次性部署中把规范化输出与 Tomcat 运行时对象比较。转换过程可独立测试，策略制品才值得信任。

8.2 用能跨过下一次部署的证据关闭案件

工程结论把一个缺陷转成代码评审问题：每种模式轮次是否在接纳集合前同时检查路径与方法？优先级清除弱命中时是否保留同级有效集合？一个父约束能否经某子集合进入并影响另一个方法？组合测试是否覆盖公开、角色限制、仅认证和 deny-all？下游是否拿到操作特定集合？分阶段选择授权策略的系统都值得问这些问题。

故事最后仍回到最初两条请求：主机和路径相同，HTTP 方法表达的操作不同，部署描述符也正确写出了差别。受影响选择器在组装策略集合时抹掉了它，固定选择器重新保留它，六格矩阵证明两条操作再次分开。只有把路径、方法、策略、主体和状态放在同一条记录里，那处缺失的合取条件才真正可见。

关闭标准因此很具体：固定版本正在服务，暴露的方法分区通过预期矩阵，退役镜像无法重新加入，历史结论写明证据与信心。其余事项保留负责人和期限；任何新的应用构建、厂商包或角色映射都会使相关结论重新进入验证。