async-http-client-check

针对 org.asynchttpclient:async-http-client（AsyncHttpClient，"AHC"）的 21 条仓库级安全公告的离线检查工具。 它会告诉你你的 jar 实际暴露于哪些公告，标记出 Dependabot 和 OSV 看不到的那些，并每行给出一个答案：3.0.13（3.x）/ 2.16.1（2.x）。

单个 jar，零运行时依赖，完全离线，Java 17+。

为什么需要它

1. 2026-08-09 发布了 17 条公告——而全局数据库只有其中 4 条

2026-08-09，AsyncHttpClient 维护者在项目自己的仓库（AsyncHttpClient/async-http-client → Security → Advisories）上发布了 17 条安全公告。

Dependabot 和 OSV 不读取那个页面。它们读取的是 GitHub 全局公告数据库。截至 2026-09-19，该数据库只包含这 17 条中的 4 条（CVE-2026-85716、CVE-2026-85717、CVE-2026-85720、CVE-2026-85721，均于 2026-09-17 添加）。其余 13 条从 GET /advisories/<GHSA> 返回 404；这 13 条中甚至有两条拥有 CVE ID（CVE-2026-85718、CVE-2026-85719）。

加上四条更早的公告（CVE-2024-53990、CVE-2026-40490、CVE-2026-45300、CVE-2026-55688），仓库共列出 21 条；全局数据库有 8 条。

2. Dependabot 让你安装的版本本身就受其中 5 条影响

从全局数据库计算"能清除一切问题的版本"，3.x 的答案是 3.0.12。OSV 也同意：对 3.0.12 执行 POST /v1/query 返回 零 个漏洞。

仓库公告称 3.0.12 仍处于五条公告的范围内：

对两个 high 要精确理解： 它们会泄露凭据，但仅当你配置了凭据（一个 Realm、Digest/NTLM 或代理）时——而且 GHSA-jmqq 还需要重放到不同主机。一个只做普通未认证 GET 的客户端不会暴露于它们。本工具不知道你如何使用该客户端；它只报告版本范围所说明的内容，判断留给你。

维护者在 CVE-2026-85721 的文本中自己说了：

注意 3.0.12 本身受另一个问题影响，GHSA-rqf5-2wxv-rjf4……升级到 3.0.13 以同时获得两个修复。

所以在 3.x 上：Dependabot 说 3.0.12，你升级后它显示绿色。真正的答案是 3.0.13。 在 2.x 上答案无论如何都是 2.16.1——但其背后的 13 条公告对你的扫描器仍然不可见。

3. 解压缩炸弹无需任何配置

CVE-2026-85721（high）是适用于默认设置的那一条：自动响应解压缩默认开启，且 HTTP/1.1 路径在解压正文时对总大小没有限制。恶意或被攻陷的服务器——或任何能在传输中修改响应的人——可以发送一个小的 gzip/deflate 正文来耗尽堆内存。受影响：<= 3.0.11 和 <= 2.16.0。这一条确实在全局数据库中，所以 Dependabot 会对其告警。

边界写法并不一致

这些范围混用了 >=、<=、<、一个显式的 = 3.0.12，以及一个裸的 3.0.0。同一个 3.0.11 对 CVE-2026-55688（< 3.0.11）是安全的，对 GHSA-v9f2-7rw2-gr2x（<= 3.0.11）则是受影响的。规则表完全按原样保留每个运算符；如果边界不再如此表现，tools/gen_rules.py 中的断言和单元测试会失败。解析器无法识别的任何范围片段都是错误——绝不是"不受影响"。

当仓库和全局数据库都包含某条公告但彼此不一致时，规则表取并集。目前只有一个案例：CVE-2024-53990——仓库只列出 3.x 版本 3.0.0，全局数据库还列出 2.x >= 2.1.0, < 2.12.4。只信任一方会导致漏报。

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

AHC 通常是传递依赖，由某个 SDK 或客户端库引入。该 artifactId 可能永远不会出现在你的 pom.xml 中。本工具读取实际发布的 jar 内部的 META-INF/maven/org.asynchttpclient/async-http-client/pom.properties——包括嵌套在 Spring Boot fat-jar（BOOT-INF/lib）或 WAR（WEB-INF/lib）中的 jar。旧版 1.x 坐标 com.ning:async-http-client 具有相同的 artifactId；它会被列出但不作判定。

用法

java -jar async-http-client-check.jar target/                 # scan build output
java -jar async-http-client-check.jar myapp.jar               # fat-jar / war, nested jars included
java -jar async-http-client-check.jar --version-of 3.0.12     # judge a version directly

每个命中都会打印 ID（有 CVE 则用 CVE，否则用 GHSA）、严重性、标题、修复版本，以及适用时的 Dependabot/全局库:未收录（"不在全局数据库中"）。输出为中文。

退出码

"我无法读取它"和"你是安全的"必须是两个不同的句子。一个合法的空 jar（一个裸的 22 字节 EOCD 记录）不是读取失败。如果一个文件受影响且另一个不可读，退出码保持 1。

它不会告诉你什么

• 仅这 21 条公告，仅 async-http-client。 AHC 所依赖的 Netty jar 中的 Netty CVE 不在覆盖范围内。
• 不检查可达性。 2026-08-09 的公告大多需要认证、代理、WebSocket、cookie 或可恢复下载才会产生影响。严重性按发布原样打印。
• 信息缺口是暂时的。 GitHub 可能随时将缺失的 13 条加入全局数据库。tools/recheck_before_publish.py 会检查它是否仍然存在。

规则表如何构建

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

python tools/gen_rules.py --dry   # run the assertions only
python tools/gen_rules.py         # regenerate the table

它读取仓库级公告（vulnerable_version_range、patched_versions），在全局数据库中查找每一条，并将"对 Dependabot 可见：是/否"记录为每条规则的一个字段。七项断言必须全部通过，否则不会写入任何内容：公告数量以及全局数据库中缺失的那 13 条的精确集合仍与基线匹配；交集仍是 3.0.13 / 2.16.1（以及仅从全局数据库计算时的 3.0.12）；这些版本从 Maven Central 返回 200，而一个哨兵版本返回 404；3.0.12 仍至少命中一条 high 公告，且这些都不在全局数据库中；所有运算符风格都存在且边界案例仍然翻转；仓库/全局的不一致仍然恰好是已知的那一个。

真实 jar 的端到端检查位于 tools/e2e_real_jars.py（来自 Maven Central 的实际 jar，包括一个 fat-jar 和一个 WAR）。tools/recheck_before_publish.py 重新验证该缺口——全局数据库、OSV 和 Maven Central，每个都带一个阳性对照和一个哨兵——如果任何东西发生变化则以非零退出。

许可证

Apache License 2.0——见 LICENSE。