Skip to content
KitploitKITPLOIT
工具博客
提交
工具博客
提交

黑客、渗透测试和网络安全工具，武装您的安全武器库！

Kitploit 是一个黑客、网络安全和渗透测试工具的目录。发现最新的项目更新，查找漏洞、分析系统、自动化测试并加强你的安全。

··订阅源·联系·隐私·© 2026 Kitploit

工具目录

分类

查看所有分类
Loading categories
netty-http-check — 离线 Java 工具，用于扫描应用程序 jar 包以确定其对 14 个 Netty codec-http CVE 的暴露情况，即使公告边界不一致，也能识别出确切的修复版本（4.1.137.Final/4.2.17.Final）。 | Kitploit
工具/GitHubGitHub/xiaoqimikko/netty-http-check
静态分析漏洞扫描器配置审计Web安全DevSecOps供应链安全
GitHubxiaoqimikko/netty-http-check

netty-http-check

离线 Java 工具，用于扫描应用程序 jar 包以确定其对 14 个 Netty codec-http CVE 的暴露情况，即使公告边界不一致，也能识别出确切的修复版本（4.1.137.Final/4.2.17.Final）。

查看仓库
12小时11分前尚未审核

最受欢迎

查看全部 →

发现我们社区最常用的工具。

探索所有工具

浏览我们的工具集合

查看所有工具 →
分享

netty-http-check

针对 14 个 io.netty:netty-codec-http CVE（2025–2026）的离线检查工具。 告诉你实际暴露于哪些漏洞——以及能一次性清除所有漏洞的单一版本： 4.1.137.Final / 4.2.17.Final，这个版本号在十四份安全公告中任何一份都未提及。

CVE-2025-58056 · CVE-2025-67735 · CVE-2026-33870 · CVE-2026-41417 · CVE-2026-42580 · CVE-2026-42581 · CVE-2026-42585 · CVE-2026-42587 · CVE-2026-50020 · CVE-2026-56746 · CVE-2026-59898 · CVE-2026-59899 · CVE-2026-59903 · CVE-2026-59921

单一 jar 包，零运行时依赖，完全离线，需要 Java 17+。

为什么需要这个工具

1. Netty 只发布一个版本号，但每个模块都有自己的“修复版本”

每个 Netty 模块都以相同的版本号发布，因此升级看起来像是一个单一决策。实际上并非如此。在 4.1 版本线上，这十四个漏洞的修复版本分布在 125 / 129 / 132 / 133 / 135 / 136 / 137 —— 七个不同的值。只跟随任何一份公告升级，你仍然处于其他漏洞的影响范围内。

2. 如果你修复了 HTTP/2 的 CVE，你在这里可能仍然暴露

netty-codec-http2 将 netty-codec-http 声明为 compile 依赖，并使用 <version>${project.version}</version> —— 两个版本被强制绑定在一起。

因此，如果你因为 4.1.136.Final 是清除七个 netty-codec-http2 CVE 的版本而升级到它，那么你现在运行的 netty-codec-http 也是 4.1.136.Final —— 而 CVE-2026-59903 覆盖 <= 4.1.136.Final。你需要 4.1.137.Final。4.2 版本线也是同样的情况：HTTP/2 的答案是 4.2.16.Final，而这一侧需要 4.2.17.Final。

这并不是说 HTTP/2 的建议是错的——它针对的是另一个模块。而是说 “一个版本号”掩盖了你实际上只针对一个模块作答的事实。

3. 边界条件的写法不一致，且一个版本会因此产生分歧

在这十四份公告中，上界写成 <= 的有 16 次，写成 < 的有 12 次。 因此同一个 4.1.136.Final 对于 CVE-2026-56746（< 4.1.136.Final）是安全的，但对于 CVE-2026-59903（<= 4.1.136.Final）则是受影响的。

无论向哪个方向规范化运算符都会产生错误答案——一个方向会过度报告，另一个方向会漏报，而对于这类工具来说，漏报才是代价高昂的错误。 规则表会严格按照公告原文保留每个运算符，并且 tools/gen_rules.py 中的断言会在该边界情况不再如此表现时导致构建失败。

而且它不扫描 pom.xml —— 这是有意为之

如果你使用 Spring WebFlux，netty-codec-http 是通过以下依赖链引入的：

root@kitploit:~
spring-boot-starter-webflux
  -> spring-boot-starter-reactor-netty
    -> reactor-netty-http
      -> netty-codec-http

该 artifactId 永远不会出现在你的 pom.xml 中。 基于 pom 的检查会回答“我没用它”，而这是错误的。本工具读取的是实际发布的 jar 包。

使用方法

root@kitploit:~
java -jar netty-http-check.jar target/                       # 扫描构建输出
java -jar netty-http-check.jar myapp.jar                     # Spring Boot fat-jar / war，包含嵌套 jar
java -jar netty-http-check.jar --version-of 4.1.136.Final    # 直接判断某个版本

退出码：0 = 不受影响 · 1 = 受影响 · 2 = 无法判断。

🔴 2 刻意不是 0。“未找到任何内容”和“干净”在脚本看来绝不能相同。 无法读取的 zip 文件会被报告为读取失败，绝不会被静默视为“这里没有 netty”。

它不会告诉你什么

  • 仅针对这 14 个 CVE，仅针对 netty-codec-http。 其他 Netty 模块有自己的 CVE； 这里的干净结果对它们不构成任何说明。如果你同时运行 netty-codec-http2，本工具会指出这一点并指向上述跨模块问题，但不会对该模块做出判断。
  • 严重性按发布时的原样报告。 十四个漏洞中有两个没有 CVSS 评分，一个是 low；它们会按原样打印，不会被汇总成一个吓人的总数。
  • 这些公告中的每一份都是带有完整包元数据的 reviewed 状态，因此 Dependabot 等工具确实会对其发出警报。本工具不是“扫描器看不到它”——而是“警报按公告告诉你一个版本号，你仍然需要自行判断哪个单一版本能终结这一切。”

规则表是如何构建的

src/main/java/dev/mikko/nettyhttpcheck/RuleTable.java 是生成的，绝不手工编辑：

root@kitploit:~
python tools/gen_rules.py --dry   # 仅运行断言
python tools/gen_rules.py         # 重新生成规则表

必须通过七项断言才会写入任何内容——其中包括：每份公告仍处于 reviewed 状态；每个漏洞的两条版本线都存在；计算出的交集仍然是 4.1.137.Final / 4.2.17.Final；这些版本确实可以从 Maven Central 获取（同时有一个哨兵版本必须返回 404，这样损坏的探测不会静默通过）；§3 中的边界情况仍然会产生分歧；以及 §2 中的 HTTP/2 答案在这一侧仍然留下漏洞。

真实 jar 的端到端检查位于 tools/e2e_real_jars.py —— 它们从 Maven Central 下载真实 jar 而非使用测试夹具，因为“在手写的 zip 上能工作，在真实 jar 上却失败”是一种真实的失败模式。

许可证

MIT

下载工具