验证失败时，它放行了
10 月 20 日，Apache Tomcat 公开一批漏洞修复。主角是 CVE-2026-101296，评级 Important：当 JNDI Realm 配置了非 GSSAPI 的 SASL 认证机制时，认证流程里缺失一个关键步骤，攻击者不提供正确密码也能通过认证。官方公告的标题里有个词比 CVE 号本身更值得看…
验证失败时，它放行了
10 月 20 日，Apache Tomcat 公开一批漏洞修复。主角是 CVE-2026-101296，评级 Important：当 JNDI Realm 配置了非 GSSAPI 的 SASL 认证机制时，认证流程里缺失一个关键步骤，攻击者不提供正确密码也能通过认证。官方公告的标题里有个词比 CVE 号本身更值得看——「bind credential validation fails open」：验证失败时，门是往开的方向倒的。
先把词掰开。Tomcat 里管「你是谁、密码对不对」的组件叫 Realm。JNDIRealm 是其中一种，把用户名单存在 LDAP 目录服务器里。认证的时候，Tomcat 拿用户名和密码去目录服务器做一次绑定（bind）——绑定成功，就等于目录服务器替你验过密码。SASL 是 LDAP 的一套认证协商框架，里面有好几种机制，GSSAPI（也就是 Kerberos）是其中之一，还有 DIGEST-MD5 等非 GSSAPI 机制。洞就出在这条非 GSSAPI 的路径上：验证绑定凭据的那一步没跑，或者跑了没看结果——而代码的默认动作不是停下来拒绝，是继续往下走，认证通过。
安全代码的第一课是 fail closed：出了任何不确定的状况，一律拒绝。这个洞是它的镜像——fail open。
故事还有个前情。今年 6 月，Tomcat 修过同一个组件里的兄弟洞（CVE-2026-55957），那次是 GSSAPI 路径上「缺失认证关键步骤」。当时堵了一条路；9 月 14 日，有人报告非 GSSAPI 的 SASL 路径存在一模一样的问题——缺的还是那一步。10 月 20 日两个一起收官。同一类「没验就放行」，半年里在同一个组件的两种认证机制上各现一次。
影响范围值得注意：三个版本线的第一个发布版起全部中招——11.0.0-M1 到 11.0.26、10.1.0-M1 到 10.1.60、9.0.0.M1 到 9.0.122。也就是说这个洞跟 JNDIRealm 的 SASL 支持同岁，十几年来第一次被人踩到、第一次被报告。波及面有个天然缓冲：默认配置用的是内存 Realm，JNDI+LDAP 的部署大多走简单绑定而不是 SASL——所以中招环境比标题看起来少；但对用 JNDIRealm 配 SASL 的环境来说，这是未认证远程攻击者直通受保护资源和管理界面的门，升级优先级没有余地。修复版：11.0.27、10.1.61、9.0.123。
同批公开的还有三个「串门」的洞，可以放在一起看：AJP 响应混淆（CVE-2026-103119，一次大块非阻塞写可能把响应体劈到当前和下一个请求之间，前一个响应的数据可能漏给后一个）、HTTP/2 异步处理出错后的请求响应混淆（CVE-2026-101356，对象回收复用触发用户之间的串话）、HTTP/2 trailer 头跨请求污染（CVE-2026-88041，上一个请求的 trailer 信息漏进下一个请求）。
眼熟吗？今天凌晨 Node.js 的安全更新里也有一条一模一样的：keep-alive 连接把上个请求还没发出的响应递给了下个请求。同一个星期，Java 和 JavaScript 两个最大的运行时，各自在自己最拿手的连接复用机制上翻车。复用是性能的命根子——省下的每一次握手，都是一次「上下文清干净了没有」的赌注。赢了十几年，输一次就是别人的数据。