一、先给结论:七条的修复版,和那个没人写的交集io.netty:netty-codec-http2在 2025-08 至 2026-07 之间累计 7 条 CVE。每一条的 GitHub advisory 都规规矩矩给了first_patched_version—— 问题是七个都不一样:CVE评级4.1 线修复版4.2 线修复版CVE-2025-55163(MadeYouReset)high7.54.1.124.Final4.2.4.FinalCVE-2026-33871(CONTINUATION 洪水)high4.1.132.Final4.2.11.FinalCVE-2026-47244(MAX_CONCURRENT_STREAMS 不生效)medium 5.34.1.135.Final4.2.15.FinalCVE-2026-48043(Decompressor 引用计数泄漏)medium 5.34.1.135.Final4.2.15.FinalCVE-2026-50560(Reset 攻击换了个签名)medium 5.34.1.135.Final4.2.15.FinalCVE-2026-56819(解压泄漏 → OOM)high7.54.1.136.Final4.2.16.FinalCVE-2026-59900(Host 头去重缺失 → 路由绕过)medium4.1.136.Final4.2.16.Final取最大值:4.1 线 → 4.1.136.Final 4.2 线 → 4.2.16.Final这两个数字不写在任何一条 advisory 上。它们是七条各自修复版的交集,得自己算。照着其中任何一条升,都还落在其余几条的受影响区间里 —— 比如升到4.1.124修好了 MadeYouReset,剩下六条一条没动。说清楚一件事,免得误会:这七条 Dependabot 都会正常告警。它们全是reviewed、包信息齐全、修复版有值。告警会来,而且会给你一个版本号 —— 但那是这一条的版本号,不是这七条的。二、为什么你的pom.xml里搜不到netty-codec-http2这是最容易得出错误结论的地方。如果你用 Spring WebFlux,依赖链是这样的:spring-boot-starter-webflux └─ spring-boot-starter-reactor-netty └─ reactor-netty-http └─ io.netty:netty-codec-http2 ← 在这儿三个 POM 都在repo1.maven.org上,可以逐个点开核。结论是:netty-codec-http2这个 artifactId 从头到尾不会出现在你自己的pom.xml里。所以:在源码目录里grep netty-codec-http2→ 没有 →不代表你没用它;想知道实际装的是哪个版本,得看构建产物:target/*.jar、容器镜像里的/app、或者mvn dependency:tree | grep netty-codec-http2。三、4.1 和 4.2 是两条要分开算的线七条每一条都同时影响两条线,而两条线的修复版编号完全不同(见第一节的表)。这里有个容易踩的心理陷阱:4.2 是新线,用它的人容易觉得自己在新版本上。实际上停在4.2.15.Final的人:已经修好五条;还中着CVE-2026-56819和CVE-2026-59900两条,其中前者是 high 7.5。四、有一个版本掉在官方口径的缝里:4.2.10CVE-2026-33871在 4.2 线上的两个字段是这么写的:vulnerable_version_range : 4.2.0.Alpha1, 4.2.10.Final first_patched_version : 4.2.11.Final4.2.10.Final掉在中间—— 按区间它不受影响(区间是小于 4.2.10),按修复版它又没到(修复版是 4.2.11)。这不是我的推断,是这条 advisory 上两个字段的原文。我不知道哪个字段是笔误,所以工具的处理是:把它显式报出来,而不是让它落进默认分支——因为默认分支是安全,而一个判不了的情况被判成安全,是最糟的那种错。如果你正好在4.2.10.Final上:直接升过4.2.11就行,别在这条上纠结。五、MadeYouReset 在 Netty 上有自己的编号2025 年 8 月那批 HTTP/2 重置流放大攻击,公开讨论用的编号是协议级的CVE-2025-8671。Netty 自己的那条是CVE-2025-55163。拿 8671 去查你的 Netty 版本,查不出结论。这两个编号不是一回事:前者说的是协议层面的问题面,后者才是你的 netty-codec-http2 中不中。顺带一提:CVE-2025-55163的 advisory 还单列了io.grpc:grpc-netty-shaded( 1.75.0)。用 gRPC 的人换个坐标也在里面 —— 但只有这一条 advisory 列了这个坐标,另外六条没列。「advisory 没列」不等于「不受影响」,只等于官方没给这个坐标下过结论。六、怎么自查手动:# 1) 看构建产物里实际装的版本(不是 pom)mvn dependency:tree|grepnetty-codec-http2# 2) 或者直接翻 jarunzip-ptarget/myapp.jarBOOT-INF/lib/netty-codec-http2-*.jar/dev/null21lstarget/*/BOOT-INF/lib/|grepnetty-codec-http2拿到版本号后,对照第一节的表逐条比。或者用工具(开源,单 jar,零运行时依赖,完全离线):java-jarnetty-http2-check.jar target/# 扫构建产物,支持 fat-jar / war 嵌套java-jarnetty-http2-check.jar--version4.1.100.Final# 直接判一个版本java-jarnetty-http2-check.jar--table# 打印完整规则表输出长这样:netty-codec-http2 4.1.135.Final 证据: META-INF/io.netty.versions.properties 中了 2 条: CVE-2026-56819 high CVSS 7.5 解压泄漏 - OOM CVE-2026-59900 medium 官方未给分 Host 头与 :authority 去重缺失 - 路由绕过 - 一次修完这几条,升到:4.1.136.Final仓库:https://github.com/xiaoqiMikko/netty-http2-check几个刻意的设计:不扫pom.xml—— 理由就是第二节;判不了就说判不了—— 认不出的版本号、没覆盖的版本线(4.0 / 5.0)、读不动的压缩包,一律报判不了,绝不报安全;规则表是生成的,不是手抄的——tools/gen_rules.py直接读 GitHub advisory,五条断言不过就拒绝出表(包括算出来的交集必须真的是 4.1.136 / 4.2.16)。七、附:我是怎么确认补丁真的在 4.1.136 里的只比版本号是不够的 —— advisory 说修了,得自己看一眼。于是下了4.1.135和4.1.136两个 jar 做字节码对比。这里有个坑,值得单独说。第一次我比的是每个条目的 SHA-256:40 个条目全变了(其中 35 个是.class,另外 5 个是 META-INF 里的元数据),连DefaultHttp2PingFrame、AbstractHttp2StreamFrame这种和本次修复八竿子打不着的类都在里面。原因很简单:整包重编译。常量池顺序、时间戳都会变,hash 自然全不一样。hash 变了 这个类改过是个会骗人的判据。换成比 class 的字节大小,噪音从 35 个降到15 个;再用javap -c做反编译差分,才拿到能说话的证据:CVE类4.1.136 里新增的东西CVE-2026-56819DelegatingDecompressorFrameListener$Http2Decompressor多了EmbeddedChannel.isOpen()判断和new ClosedChannelException—— 向已关闭的 decompressor 写数据时抛异常,而不是继续吃内存CVE-2026-59900HttpConversionUtil$Http2ToHttpHeaderTranslator多了字段hostHeaderFound和错误消息Conflicting :authority and host headers found—— 开始比对 Host 与:authority是否一致第二个坑更隐蔽。我一开始的判据是136 的那个类里出现了HOST这个符号,结果135 里也有(HttpHeaderNames.HOST本来就在常量池里)。换成那句只在 136 出现的错误消息,判据才立得住。教训是通用的:验新版本有某个东西,必须同时验旧版本没有。只验一半,和没验长得一模一样。