2026-10-12 更正本文 2026-09-20 的第一版有三句结论:「17 条公告,GitHub 全局漏洞库只收了 4 条」「Dependabot 会叫你升到 3.0.12」「终点是 3.0.13 / 2.16.1」。这三句在当时是实测成立的,现在都已经不成立,原因是上游之后动了两次:2026-09-24,AsyncHttpClient 官方仓库又发了 5 条安全公告,修复版是 3.0.14,并且写明 2.x 线不再修;2026-10-08,GitHub 全局漏洞库补收了 9 条(8 月那批 5 条 9 月那批 4 条)。所以如果你照第一版升到了 3.0.13 或 2.16.1,它们现在都不是干净版本。配套工具的 v0.1.0 也会把这两个版本判成干净,请换用 v0.2.0。下面是按 2026-10-12 的实测重写的全文;第一版里仍然成立的部分(解压炸弹那条、它常被别的库带进来)保留了。先说结论如果你的项目里有org.asynchttpclient:async-http-client(直接依赖,或者被别的库带进来):你在哪条线现在的结论Maven Central3.x升到3.0.14✅ 3.0.14 存在2.x没有干净的 2.x 版本。终版 2.16.1 仍中 5 条,这 5 条不会再修,只能迁到 3.0.142.x 线最新就是 2.16.1,2.16.2 不存在「升到 2.16.1」在一个月前还是 2.x 线的标准答案,现在不是了。2.x 线:官方原话是「不会再修」2026-09-24 发的 5 条公告,每一条的 Patches 段都以同一句话结尾:The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14.这 5 条在 2.x 上的受影响区间都一直覆盖到 2.16.1,修复版一栏是空的:编号官方评级2.x 受影响区间一句话触发前提CVE-2026-107230high 2.0.0, 2.16.1连接池仍会把一个身份认证过的连接交给另一个身份的请求用 NTLM / Kerberos / SPNEGO,或走需要登录的 SOCKS / CONNECT 代理,并且同一个 client 发不同身份的请求。对源站用 Basic / Digest 不受影响CVE-2026-107227high 2.2.0, 2.16.1WebSocket 压缩消息解压没有大小上限,约 2 MiB 的消息可以膨胀到约 2 GiB调过setEnablewebSocketCompression(true)(默认是关的),且对端不可信或走明文ws://CVE-2026-107228medium 2.1.0, 2.16.1你用setHeader/addHeader设的Cookie头,会被 cookie 存储里的 cookie 整个替换掉cookie 存储(默认开启)里有这个源的任意 cookieCVE-2026-107226medium 2.1.0, 2.16.1明文 HTTP 响应可以种入、覆盖或删除 HTTPS 设下的Securecookie同一个 cookie 存储同时访问同一站点的明文 HTTP 与 HTTPSCVE-2026-107229medium 2.16.0, 2.16.1默认 cookie 存储的来源检查不完整,可以给别的主机种 cookie同一个 client 访问多个源,其中一个受攻击者影响先把话说准:两条 high 都不是「发普通请求就中」。一条要你自己开了 WebSocket 压缩,一条要用到 NTLM / Kerberos / SPNEGO 或带登录的代理。如果你只是拿 AHC 对固定服务发普通 HTTP 请求,这两条大概率不关你的事。落在默认配置上的是三条 medium:它们都出在默认开启的 cookie 存储上。其中CVE-2026-107228官方点了一个具体场景:一个 client 替多个用户发请求、各自的会话 cookie 是用setHeader放在请求上的——这时一个用户的请求可能带着另一个用户的会话 cookie 发出去。它是 2024 年那条CVE-2024-53990的修复被绕过。所以这件事的分量不在某一条漏洞有多严重,而在于:2.x 线从此没有「升上去就干净」的版本了,以后再出公告也一样。老的 2.x 版本:升到 2.16.1 之后是 5 条,不是 4 条这里有个容易算错的地方。拿 2.12.3 举例:它现在中 21 条,其中 4 条是上面那种没有修复版的;升到 2.16.1 能清掉有修复版的那些;但升完之后剩下的是 5 条。CVE-2026-107229的 2.x 区间是从 2.16.0 开始的,2.12.3 本来不在里面,升上去反而进了区间。这不是说别升 2.16.1——它清掉的条目里有默认配置就能触发的解压炸弹(见下文)。只是别把它当终点。3.x 线:终点从 3.0.13 变成 3.0.143.0.13 现在中的就是 9 月那批 5 条,全部在 3.0.14 修复。3.0.14 在 Maven Central 上存在,截至 2026-10-12 是最新版(3.0.15 不存在)。第一版说「Dependabot 给的版本不对」。这一点现在也变了:9 月那 5 条里有 4 条已经进了全局漏洞库,只按全局库算,3.x 的目标同样是 3.0.14。也就是说对 3.x 用户,现在 Dependabot 给的数字是对的。我用 OSV 独立核了一遍:OSV 对 3.0.14 返回零漏洞,对 3.0.13 返回 4 条。全局漏洞库现在还缺 9 条Dependabot 和 OSV 不读项目自己的 Security → Advisories 页面,读的是 GitHub全局漏洞库。AsyncHttpClient 仓库现在一共有 26 条公告,全局库的收录进度是这样的:时间发生了什么2026-08-09官方一次发 17 条2026-09-17全局库收了其中 4 条(晚 39 天)2026-09-24官方又发 5 条2026-10-08全局库再收 9 条(8 月那批 5 条 9 月那批 4 条)2026-10-1226 条里仍有 9 条按编号查是 404还缺的 9 条:8 月那批 8 条 9 月那批 1 条(CVE-2026-107229)。其中官方评 high 的有 2 条,都和代理凭据有关:编号官方评级一句话受影响触发前提CVE-2026-107232high代理拒绝 CONNECT 时,把源站凭据明文发给了代理 3.0.11/ 2.16.0走 HTTP 代理且配了源站凭据CVE-2026-85719highSOCKS 代理凭据通过明文 HTTP 发给了源站 3.0.11/ 2.16.0走 SOCKS 代理这两条 3.0.12 / 2.16.1 就已经修了,所以只要你按上面的结论升级,它们会一起消失;影响的是还停在 3.0.11 及以下、又只看 Dependabot 面板的人——面板上没有这两条。顺带一个评级上的差异:CVE-2026-107282(请求被重放到另一台主机时把原主机的请求发给新主机)官方自评 high,全局库里是 critical。这个数字还会继续变。8 月那批第一次被收录晚了 39 天,9 月那批晚了 14 天。默认配置就中的那一条:CVE-2026-85721 解压炸弹这一节第一版就有,结论没变。AHC 默认开启响应自动解压。85721 说的是:HTTP/1.1 路径上解压没有总输出大小上限,一个很小的压缩响应体可以在内存里无限膨胀,直到 OOM。受影响: 3.0.11与 2.16.0。触发前提:对端是恶意的或被攻陷的服务端,或者有人能在传输中改你的响应。如果你的服务会去请求第三方或用户给的 URL(回调、抓取、Webhook),这个前提并不遥远。gzip / deflate / snappy 始终可用作载体;brotli / zstd 只在对应编解码器在 classpath 上时才算。3.x 线可以关掉自动解压(setEnableAutomaticDecompression(false))自己带上限解;2.x 线没有这个开关,解压 handler 是无条件装上的,只能通过httpAdditionalChannelInitializer把它摘掉。这一条全局库里有,Dependabot 会报。它是 2.x 用户至少要先升到 2.16.1 的理由。你的项目里可能根本看不到它async-http-client经常是被别的库带进来的,不在你自己的pom.xml里。所以「搜一下 pom 没找到」不代表没用它。要看的是最终打进包里的 jar。配套工具 v0.2.0async-http-client-check:给它一个构件(部署目录 / war / Spring Boot fat jar / 单个 jar),它从 jar 内的pom.properties读出真实版本,回答三件事:你中了 AHC 官方仓库 26 条公告里的哪几条;其中哪几条 Dependabot / 全局库看不见;这条线该升到哪——如果这条线已经没有修复版,它会直说,不会硬给一个版本号。java -jar async-http-client-check.jar /path/to/app/lib # 部署目录 java -jar async-http-client-check.jar app.jar # Spring Boot fat jar / war java -jar async-http-client-check.jar --version-of 2.16.1 # 只问一个版本号对 2.16.1,它的输出是(节选,略去了分隔线和「扫到的构件」一段;退出码 1,v0.1.0 对它的退出码是 0):async-http-client-check 0.2.0 —— async-http-client 26 条仓库级 advisory 离线自查 规则表生成于 2026-10-12:下面的「已收录 / 未收录」是那天 GitHub 全局 advisory 库的状态,之后可能已补收。 【判定】async-http-client 2.16.1 中了 5 条,其中 1 条 Dependabot / OSV 看不见(GitHub 全局 advisory 库未收录): CVE-2026-107230 high 连接池仍会跨身份复用 NTLM/Negotiate/代理登录的连接(GHSA-vvp4 修复不完整) 区间 2.0.0, 2.16.1 → 修复版 无(2.x 线已停止维护) · Dependabot/全局库:已收录 CVE-2026-107227 high WebSocket permessage-deflate 解压无上限 - 解压炸弹(要开 WebSocket 压缩,默认关) 区间 2.2.0, 2.16.1 → 修复版 无(2.x 线已停止维护) · Dependabot/全局库:已收录 CVE-2026-107228 medium CookieStore 覆盖 setHeader 显式设置的 Cookie 头(CVE-2024-53990 修复被绕过) 区间 2.1.0, 2.16.1 → 修复版 无(2.x 线已停止维护) · Dependabot/全局库:已收录 CVE-2026-107226 medium 明文 HTTP 收到的 cookie 可种入/覆盖/删除 HTTPS 的 Secure cookie 区间 2.1.0, 2.16.1 → 修复版 无(2.x 线已停止维护) · Dependabot/全局库:已收录 CVE-2026-107229 medium 默认 cookie 存储来源检查不完整 - 可向公共后缀/IP 主机种 cookie 区间 2.16.0, 2.16.1 → 修复版 无(2.x 线已停止维护) · Dependabot/全局库:未收录 其中 5 条在 2.x 线上没有修复版。官方原文: The 2.x line is end of life and will not receive a fix. Upgrade to 3.0.14. → 这已经是 2.x 线能到的最高修复状态,仍中这 5 条。 → 要修完只能迁到 3.x 线的 3.0.14(跨大版本,不是只改一个版本号)。 结论:async-http-client 需要升到 3.0.14(从 2.x 线迁移)输出第二行印的是规则表的生成日期。第一版吃的亏就在这里:「未收录」三个字印在 jar 里不会自己过期,现在它会告诉你这是哪一天的状态。判定表不是手抄的:由脚本从 AHC 仓库级公告生成,生成时逐条查全局库,断言不过就拒绝出表。这次新加的一条断言是:修复版为空,只有在公告原文写明该线停止维护时才认作「无修复版」,否则当脏数据停下——不许把「没有修复版」读成「不受影响」。退出码:0 没中 · 1 中了 · 2 用法错误 / 版本认不出 · 4 有文件读不动(坏 jar 不会被当成「干净」)。工具、判定表生成脚本、发文前复核脚本都在仓库里(Apache-2.0):https://github.com/xiaoqiMikko/async-http-client-check—— 可直接下载的 jar 在 Release v0.2.0。这篇能证明什么、不能证明什么能:截至 2026-10-12,官方仓库 26 条公告,3.x 全部修完要 3.0.14;2.x 终版 2.16.1 仍在 5 条公告的区间里、修复版为空、原文写明不再修;全局库仍缺 9 条(逐条查与按包列表两种查法对得上);OSV 对 3.0.14 返回零漏洞、对 2.16.1 返回 4 条。不能:不能证明你一定会被攻击(两条 high 都要特定用法,cookie 那三条要一个 client 访问多个源或混用明文与 HTTPS);没有测过 2.x 迁到 3.x 要改多少代码,那是跨大版本升级,请看上游的发布说明;也不能保证这些数字下个月还对——这篇文章自己就是这么过时的。