先说结论
2026-09-17,Jetty 发布了 CVE-2026-19203 (GHSA-xc35-c22g-239h,high / CVSS v4 8.3),是今年 6 月那条 CVE-2026-2332 走私的同族续作 ------都是 chunk 分块解析被一个换行字符提前截断,导致 HTTP 请求走私。区别在触发字符:2332 是 quoted-string 里的 \r\n,19203 是 chunk 扩展里的 \n(LF),官方按 Funky Chunks 研究的术语叫它 LF EXT.TERM 走私。
对还在用 Jetty 9.4 / 10 / 11 这三条已经 EOL 的老线的人,最扎心的一条事实是:
官方安全页叫你分别升到 9.4.64 / 10.0.32 / 11.0.32------而这三个版本在 Maven Central 上,一个都没有。
截至发文当天实测:
| 你在哪条线 | 官方叫你升到 | Maven Central 上 |
|---|---|---|
| 9.4.x(EOL) | 9.4.64 | 🔴 404 |
| 10.0.x(EOL) | 10.0.32 | 🔴 404 |
| 11.0.x(EOL) | 11.0.32 | 🔴 404 |
| 12.0.x | 12.0.38 | ✅ 200 |
| 12.1.x | 12.1.12 | ✅ 200 |
9.4 线的公开构件停在 9.4.58.v20250814,再往后 9.4.59~9.4.64 任何后缀都不存在。官方对这三条老线写的是 see details for availability------公开渠道拿不到,要走商业支持。
为什么你的扫描器可能没提醒你
19203 在 GitHub 全局漏洞库(Dependabot 用的那个)里已经是 reviewed 状态,但它的条目里 vulnerabilities 字段是空的------没有受影响的包、没有版本区间、没有修复版。
结果是:Dependabot 能告诉你「有 CVE-2026-19203 这个洞」,却给不出「你的哪个版本中了、要升到哪」。真正带区间的信息只在 Jetty 仓库级的 advisory 里(就是上面那张表的来源)。
🔴 这一条是截至 2026-09-18 的实测。GitHub 全局库补齐区间只是时间问题,补上之后 Dependabot 就能给出升级建议了。
一个容易被漏掉的区间:9.4.60 ~ 9.4.63
如果你之前用只覆盖 2332 的检查跑过一遍,注意一个盲区:
- 2332 的 9.4 区间到 9.4.59 为止;
- 19203 的 9.4 区间到 9.4.63。
也就是说,卡在 9.4.60 ~ 9.4.63 的构件,在只看 2332 的检查里是「干净」的,实际上中了 19203。而用户后台搜得最多的正是 jetty 9.4.63、jetty security 9.4.64 maven------恰好落在这一段。
12.1.x 是个例外:默认配置不受影响
一个必须说清楚、否则会误导人的点:
12.1.x 默认不受这条影响。 从 12.1.0 起(PR #12564),Jetty 默认用 RFC9110 合规模式,不允许 chunk 扩展里出现 LF。只有当你显式 把 HttpCompliance 配成 RFC7230 或 RFC2616 时,最新的 12.1.11 也会中招。
而 9.4 / 10 / 11 / 12.0 这几条线是默认就中招的(官方用 12.0.36 的 docker 镜像实测,一个请求打进去返回了两个响应)。
所以判断你中不中,不能只看版本号,还要看:①你在哪条线;②如果是 12.1.x,有没有改过合规模式。
顺手说清:这条洞的危害边界
走私类漏洞的危害有前提:你的 Jetty 前面还得有一个前端代理 / 负载均衡,且它和 Jetty 对同一个请求的边界解读不一致,攻击者才能把一个「走私」的请求藏在正常请求后面。裸跑一个 Jetty、前面什么都没有,是讲不出攻击故事的。这条 CVSS 是 v4 8.3,不是「谁装了谁完」。
但「命中受影响区间」「官方叫升的版本拿不到」这两件事是客观的构件事实,值得你先搞清楚自己在不在区间里。
一个把这些做完的工具
jetty-line-check 给它一个 Jetty 构件(部署目录 / war / Spring Boot fat jar),它回答:你中了这几条 2026 Jetty CVE 的哪些,以及官方叫你升的那一版在 Maven Central 上到底存不存在。
判据不是「jar 里有没有某个类」(这几条 CVE 的修复都是改方法体、没加类),而是你的完整坐标 + 版本线 → 判定表 + Central 真 jar 探测。判定表由脚本从 GitHub advisory 的一手数据 + Central HEAD 探测生成,八组断言不过就拒绝出表。
bash
java -jar jetty-line-check.jar /path/to/jetty # 扫部署目录 lib/*.jar
java -jar jetty-line-check.jar app.jar # Spring Boot fat jar
java -jar jetty-line-check.jar --table # 只看判定表对 9.4.63 的 jetty-http,它会告诉你:命中 CVE-2026-19203,官方点名 9.4.64,而 9.4.64 在 Central 上 404;对 12.1.11,它会额外标出「默认 RFC9110 不受影响,仅当配 RFC7230/2616 时命中」,不会对默认部署误报。
工具、判定表生成脚本、发文前复核脚本都在仓库里(MIT)。
这篇能证明什么、不能证明什么
- 能:19203 存在、是 2332 同族、官方叫升的老线版本 Central 404(逐版本 HEAD 实测)、全局库当前拿不到区间、9.4.60~63 是只看 2332 会漏的一段。
- 不能:不能证明你一定会被攻击(走私要前置代理解读不一致);不是说 GitHub 永远不会补上区间;不是说 12.1.x 默认部署有风险。