这两天各家运维和安全群里的告警弹窗几乎没断过。先是 PHP 爆出能直接拿权限的 php2shell，接着大家内部常用的 GitLab 紧急发了高危更新，紧接着 Node.js 和 Chrome 也在同一周把严重补丁推了出来。
几个底层组件像商量好了一样扎堆报警，好多工程师连着通宵排查。更要命的是，这次的风波没停在脚本语言或者前端工具上，向来被当成企业级压舱石的 Java 生态，紧跟着也挨了两记重锤。
AI 把攻防节奏推到了极致
很多人纳闷，以前一年难得碰上一两回的顶级漏洞，这周怎么全撞车了？中间最大的变量就是 AI。
现在无论是白帽研究员还是攻击方，都在拿大模型和自动化智能审计工具对着底层开源库硬跑。以前要资深安全专家翻上几个月代码才可能揪出来的状态机边界缺陷，现在被脚本成批量地扫出来。
更头疼的是武器化的时间差。早些年漏洞公布后，大家通常还有两三天的时间窗口排查打补丁。现在借助 AI 辅助生成攻击脚本，公开后不到一小时，全网的扫描和利用尝试就成倍往上窜。防守方过去习惯的人工巡检和按周发版，在这套自动化节奏面前几乎成了慢动作。
Oracle 撤销 CA 信任（CVE-2026-91403）
Java 挨的第一记重锤来自 Oracle 紧急发布的特别安全通告。漏洞编号是 CVE-2026-91403，在 CVSS 3.1 评分体系里直接打了 9.1 分，影响的核心组件是 JSSE。
这次出事的地方不在常见的内存越界或者代码注入，而是底层的数字证书信任体系。Oracle 在这版紧急更新里，强制撤销了对 eMudhra 关联的一批受影响中级 CA 证书的信任。在平时走 TLS 和 HTTPS 的微服务系统里，JSSE 管着握手和证书验真。一旦底层的数字证书信任链出了窟窿，攻击者就能拿着伪造证书在网络传输途中搞中间人劫持，直接把服务之间的身份校验架空。
受波及的范围相当广。从老的 Oracle Java SE 8u511、11.0.33，到主流的 17.0.21、21.0.13、25.0.5 以及最新的 27.0.1，再加上云原生常用的 GraalVM，全在受影响名单里。解决这个漏洞没有捷径，只能老老实实把底层 JDK 整体升级到官方修复版本。
Tomcat 异步串流错乱（CVE-2026-101356）
如果说 Oracle 的漏洞动摇了加密通信的底座，Apache Tomcat 的问题则是把运行时的会话边界给搞乱了。Apache 官方这次一次性披露了多个 Tomcat 缺陷，里面最扎眼的正是打了 9.1 分的 CVE-2026-101356。
这个漏洞藏在 HTTP/2 协议搭配异步 Servlet 的处理逻辑里。当客户端请求在异步处理过程中抛了异常或者遇到网络错误，Tomcat 内部的对象回收机制出了差错，前一个请求占用的底层对象还没彻底清空，就被直接塞给后面其他用户的请求复用。
这会导致严重的请求与响应混淆。比如用户 A 在页面上查自己的订单或者提交认证信息，后端返回的数据包却可能被顺手推到了用户 B 的屏幕上。在现在大量使用前后端分离、长连接多路复用的架构里，敏感 Token 和隐私数据一旦在信道里串门，后果谁也兜不住。
Tomcat 与 Spring Boot 修复实操
两颗雷排查清楚了，接下来就是工程层面的实际处置。
如果是独立部署或者打在容器镜像里的原生 Tomcat，官方已经给出了对应版本的修复基线。Tomcat 11 需要升到 11.0.27 及以上，Tomcat 10 对应的是 10.1.61 及以上，老一些的 Tomcat 9 则要升到 9.0.123 及以上。还在跑 9.0 体系的团队要留意，这个大版本官方支持快到期了，后续建议提早规划换代。
Spring Boot 官方今天也紧急发布了维护版本，包含 Spring Boot 4.1.2 等。如果项目本身在推进最新版本，直接在工程里升级到 Spring Boot 4.1.2 最稳妥，框架会把配套版本直接配齐。
要是手头的业务系统正赶上发版封板期，没法冒风险做 Spring Boot 大版本升级与全量回归，还有一种轻量级的应急办法。在 Maven 项目的 pom.xml 属性区里，单把 Tomcat 版本号提上去就行。
1 | <properties> |
如果是 Gradle 工程，可以在 build.gradle 里加一行属性覆盖。
1 | ext['tomcat.version'] = '10.1.61' |
配置改完之后，记得用构建工具打个包，看一眼依赖树，确认 tomcat-embed-core 等核心 jar 包确实切到了新版本。改完业务代码的同时，别忘了检查宿主机和基础镜像里的 JDK，两头都补齐，才算把这轮连环漏洞真正关在门外。