我升级了 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-coyote、org.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 条断言,任一不满足就中止不生成文件。其中一条断言是用第二个独立口径把条目再数一遍 ------ 开发时真的靠它抓到过一次条目错配。
最后,请这样读它的输出
- 「命中」= 你的版本落在官方 Affects 区间内,不等于「已被利用」,更不等于「必然可利用」。29 条里只有少数是默认配置即暴露,其余需要你显式开启某个功能(RewriteValve、DIGEST 认证、AJP、WebDAV、集群通信)。
- 「不会告警」不是说 GitHub 失职 ,
unreviewed是正常流程状态。 - 判定表只覆盖 2026 年公布的 CVE,没命中不等于你的版本没问题。
工具不替你决定要不要升级。它只给你做这个决定需要的三样东西:你装的是哪个版本、官方怎么评、触发条件是什么。