netty-codec-http2 该升到哪个版本?7 条 CVE 的修复版各不相同,一次修完是 4.1.136 / 4.2.16-平芜编程栈

一、先给结论:七条的修复版,和那个没人写的交集

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.5	4.1.124.Final	4.2.4.Final
CVE-2026-33871(CONTINUATION 洪水)	high	4.1.132.Final	4.2.11.Final
CVE-2026-47244(MAX_CONCURRENT_STREAMS 不生效)	medium 5.3	4.1.135.Final	4.2.15.Final
CVE-2026-48043(Decompressor 引用计数泄漏)	medium 5.3	4.1.135.Final	4.2.15.Final
CVE-2026-50560(Reset 攻击换了个签名)	medium 5.3	4.1.135.Final	4.2.15.Final
CVE-2026-56819(解压泄漏 → OOM)	high7.5	4.1.136.Final	4.2.16.Final
CVE-2026-59900(Host 头去重缺失 → 路由绕过)	medium	4.1.136.Final	4.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.10

CVE-2026-33871在 4.2 线上的两个字段是这么写的:

vulnerable_version_range : >= 4.2.0.Alpha1, < 4.2.10.Final first_patched_version : 4.2.11.Final

4.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.jar'BOOT-INF/lib/netty-codec-http2-*.jar'>/dev/null2>&1lstarget/*/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-56819	`DelegatingDecompressorFrameListener$Http2Decompressor`	多了`EmbeddedChannel.isOpen()`判断和`new ClosedChannelException`—— 向已关闭的 decompressor 写数据时抛异常,而不是继续吃内存
CVE-2026-59900	`HttpConversionUtil$Http2ToHttpHeaderTranslator`	多了字段`hostHeaderFound`和错误消息`Conflicting ':authority' and 'host' headers found`—— 开始比对 Host 与`:authority`是否一致