Dependabot 面板全绿,不代表你的 Tomcat 没洞

我升级了 Spring Boot,Dependabot 面板全绿,以为没事了。

然后我扫了一下自己的 fat jar:

ruby 复制代码
构件:tomcat-embed-core  版本:9.0.118

── 🔴 你的 Dependabot 大概率不会告警的条目:4 条 ──
  CVE-2026-55276  ASF 官方 Low │ GitHub critical (CVSS 9.1)
     触发条件:默认配置即受影响
  CVE-2026-59083  ASF 官方 Low │ GitHub critical (CVSS 9.1)
  CVE-2026-53404  ASF 官方 Low │ GitHub high (7.3)
  CVE-2026-55956  ASF 官方 Moderate │ GitHub medium (6.5)

  命中 4 条,其中 4 条你的 Dependabot 大概率不会告警

9.0.118 是 2026 年 5 月那批 CVE 的官方修复版 ------ 也就是「已经升到位」的状态。

一、先说清楚:这不是谁的锅

有两种机制会让一条 CVE 进不了你的告警面板,两种都不是失职

机制 A:advisory 还是 unreviewed

GitHub 的 advisory 有两种状态。reviewed 是人工确认过受影响包范围的,unreviewed 是从 NVD 自动导入、还没人工确认的。Dependabot 只用 reviewed 的做告警。

bash 复制代码
$ gh api /advisories?cve_id=CVE-2026-59083
type: unreviewed   severity: critical   vulnerabilities: []

严重性给到 critical,受影响包列表是空的。没有包就没有匹配对象,自然不会告警 ------ 对所有人都不会,不只是你。

这是正常流程,不是隐瞒。人工审核需要时间,这批六月底公布的条目还排在队列里。

机制 B:坐标对不上

Spring Boot 的依赖树里只有这三个坐标:

makefile 复制代码
org.apache.tomcat.embed:tomcat-embed-core
org.apache.tomcat.embed:tomcat-embed-el
org.apache.tomcat.embed:tomcat-embed-websocket

而有些 advisory 挂的是 org.apache.tomcat:tomcat-coyoteorg.apache.tomcat:tomcat ------ 独立安装用的坐标。Dependabot 按坐标匹配,匹配不上就不报。

二、那这些代码到底在不在我的 jar 里

这一步不能靠推测,得下真 jar 数。

arduino 复制代码
tomcat-embed-core-9.0.118.jar   1745 个条目
  org/apache/catalina/valves/rewrite/RewriteValve.class      有   ← CVE-2026-59083 / 53404
  org/apache/catalina/startup/ContextConfig.class            有   ← CVE-2026-55276
  org/apache/catalina/realm/JNDIRealm.class                  有   ← CVE-2026-55957
  org/apache/catalina/servlets/DefaultServlet.class          有   ← CVE-2026-55956

在。

但反过来也必须验,不然就成了吓唬人。同一批里,这些是真的不在内嵌版里的:

CVE 代码实际在哪
59084 / 55955 / 29146 / 34486(EncryptInterceptor) tomcat-tribes.jar,内嵌版不含
34487(CloudMembershipService) tomcat-tribes.jar
53434 / 34500(FFM 连接器) tomcat-coyote-ffm,三条线的 embed-core 里都没有
50229 / 66299 示例应用 webapps/examples

2026 年 Tomcat 一共 29 条 CVE。「进不了告警」的有 16 条,扣掉本来就不在内嵌版里的 9 条,对 Spring Boot 用户真正成立的是 7 条。

三、最该看的是这一条

csharp 复制代码
CVE-2026-55957   ASF 官方 Important   GitHub high 7.3   unreviewed
                 Authentication bypass with JNDIRealm and GSSAPI authentication

官方自己评的是 Important。

这条不需要任何「两套评级谁更准」的辩论 ------ 官方和 GitHub 都认为它不轻,而它进不了告警面板。

触发条件:仅当你用 JNDIRealm + GSSAPI 认证。用不到就真的不受影响。

四、顺带说说那个让人半夜爬起来的评级差

29 条里有 17 条,官方评级和 GitHub 评级差 2 级以上。最极端的一条:

复制代码
CVE-2026-41293   ASF 官方 Low   →   GitHub critical CVSS 9.8

不是谁报错了,是两套体系测的不是同一个东西:

ASF / Tomcat 官方 GitHub / NVD
分级 Low / Moderate / Important / Critical CVSS 数值
依据 默认配置下的实际可利用性 向量机械计算,不看你开没开那个功能
在哪看 tomcat.apache.org/security-9.html Dependabot 直接推给你

而真正决定「要不要现在升」的,是两套评级里都没有的第三样东西 ------ 触发条件。

比如官方对 CVE-2026-66299 的原话:

Users who followed the security guidance to remove the examples web application are not affected.

这句话不在任何评级里,但它才是那句该看的。

五、做成了个工具

零依赖单 jar,离线跑,需要 Java 17+:

bash 复制代码
java -jar tomcat-check.jar target/my-app.jar    # Spring Boot fat jar
java -jar tomcat-check.jar /opt/tomcat          # 独立安装
java -jar tomcat-check.jar --all --utf8 target/lib

对每条命中给出:两套评级 + 触发条件 + 官方描述原文 + 这条会不会进你的 Dependabot 告警,最后给一个能覆盖全部命中条目的升级目标。

判定表从官方 security 页面和 GitHub Advisory API 两个一手源生成,一行不手抄,带 7 条断言,任一不满足就中止不生成文件。其中一条断言是用第二个独立口径把条目再数一遍 ------ 开发时真的靠它抓到过一次条目错配。

仓库:github.com/xiaoqiMikko...

最后,请这样读它的输出

  • 「命中」= 你的版本落在官方 Affects 区间内,不等于「已被利用」,更不等于「必然可利用」。29 条里只有少数是默认配置即暴露,其余需要你显式开启某个功能(RewriteValve、DIGEST 认证、AJP、WebDAV、集群通信)。
  • 「不会告警」不是说 GitHub 失职 ,unreviewed 是正常流程状态。
  • 判定表只覆盖 2026 年公布的 CVE,没命中不等于你的版本没问题。

工具不替你决定要不要升级。它只给你做这个决定需要的三样东西:你装的是哪个版本、官方怎么评、触发条件是什么。

相关推荐
前端开发张小七1 小时前
Java 学习笔记 · 第三课:多线程与并发编程(线程、同步、死锁、Lock、乐观锁与悲观锁)
java·后端·程序员
摇滚侠1 小时前
SpringBoot 官网 阅读笔记 启用生产就绪功能 端点
spring boot·笔记·后端
花生了什么事o1 小时前
JVM 垃圾回收:对象如何被判定和回收
java·jvm
evans在进步2 小时前
HashMap 为什么线程不安全?ConcurrentHashMap 如何解决?
java·spring boot·spring
我命由我123452 小时前
匈牙利命名法
java·服务器·后端·学习·java-ee·kotlin·学习方法
闲猫2 小时前
LangChain / Integrations / Integrations by component / Tool
java·数据库·langchain
小田的博客2 小时前
SAP MM 供应商银行主数据更新报错!message R1228!
android·java·服务器
范什么特西3 小时前
知识总结03
java