2026-10-05 更正(两处;原文保留,逐处标了现状)① 「GitHub 全局漏洞库没收录、Dependabot 不报」已过时。本文写于 09-14,当时成立。这 4 条已于2026-09-28被 GitHub 全局漏洞库收录(10-05 按 GHSA 编号重查,四条都查得到),Dependabot 现在会报。OSV 按 Maven 坐标查 2.21.5,也已能查出其中 3 条(另一条 77310 在 2.21.5 已修,本就不该出现)。从仓库发布到进全局库,隔了 27~38 天。② 「升到 2.21.6 / 2.18.10 / 3.1.6 就修完」已不够。09-30 FasterXML 又发了 2 条 high(CVE-2026-91776、CVE-2026-91777,都是拒绝服务)。现在一次修完的版本是2.18.11 / 2.21.7 / 2.22.3 / 3.1.7 / 3.2.3。这两条发布当天就进了全局库,Dependabot 会报。没变的:这 4 条公告的内容和触发条件、jar 里的补丁标记、「逐条求交集才知道该升到哪」这个做法。另外,jackson-core是独立坐标,10-01 它也新发了 2 条 high,同样要升到上面那组版本号。先说结论截至2026-10-05:你现在的版本线一次修完的版本本文 09-14 写的(已不够)2.18.x2.18.112.18.102.21.x2.21.72.21.62.22.x2.22.32.22.23.1.x(tools.jackson.core)3.1.73.1.63.2.x(tools.jackson.core)3.2.33.2.2这几个版本在 Maven Central 上都能下载。如果你是照我 08-07 那篇(jackson-databind 升到 2.21.4 就安全了吗?)升到了 2.21.5,那个答案不够了:截至 10-05,2.21.5 中 5 条(本文讲的 3 条 09-30 新发的 2 条)。照本文 09-14 的建议升到 2.21.6 的,还中 09-30 那 2 条。这 5 条 Dependabot 现在都会报。这 4 条是什么FasterXML 在自己仓库的 Security 页上发了 4 条:编号发布严重度内容修复版CVE-2026-6849708-21high 7.5JSON 字符串绑定到javax.xml.datatype.Duration/XMLGregorianCalendar时,数字长度没有上限,可耗尽 CPU2.18.10 / 2.21.6 / 2.22.2 / 3.1.6 / 3.2.2CVE-2026-1903208-21medium 5.3反序列化java.nio.file.Path时不限制 URI scheme,可驱动已注册的FileSystemProvider同上CVE-2026-7731008-21medium 5.3CVE-2026-54514 修得不完整:InetAddress分支仍会立即做 DNS 解析2.18.9 / 2.21.5 / 2.22.1 / 3.1.5 / 3.2.1CVE-2026-8355709-01medium 5.6默认PolymorphicTypeValidator的拒绝列表漏了Comparable2.18.10 / 2.21.6 / 2.22.2 / 3.1.6 / 3.2.2最值得先看的是 68497。advisory 原文说,默认的JsonMapper.builder().build()就能触发,不需要开多态,也不需要特殊配置,只要你的 DTO 里有javax.xml.datatype.Duration或XMLGregorianCalendar字段。为什么扫描器当时不报(09-28 起已经报了)本节是09-14 的记录。10-05 重跑下面的命令,四条都查得到(全局库收录日期 2026-09-28)。留着它,是因为「官方仓库发了、全局库还没收」这段空窗每次都会再出现一遍。GitHub 全局漏洞库查不到。这 4 条是 FasterXML 在自己仓库里发布的 advisory。按 GHSA 编号去 GitHub 全局漏洞库查:gh api advisories/GHSA-q4xh-88c3-wmh7# 68497 → 404gh api advisories/GHSA-wjgm-6hv5-3cvf# 19032 → 404gh api advisories/GHSA-vvgp-rfg2-7rr6# 77310 → 404gh api advisories/GHSA-gx83-3vf8-gh7j# 83557 → 404gh api advisories/GHSA-5gvw-p9qm-jgwh# 对照:07-10 发的那条 → 查得到GitHub 官方文档写的是:「Only advisories reviewed by GitHub trigger alerts.」没被 GitHub 审核收录的 advisory,不会触发 Dependabot 告警。这不是说 GitHub 永远不收。拿之前几条做对照:advisory仓库发布进全局库间隔GHSA-j3rv-43j4-c7qm06-1606-237 天GHSA-5gvw-p9qm-jgwh07-1007-2111 天这 4 条08-21 / 09-0109-28(09-14 写本文时还没收)27~38 天OSV 按 Maven 坐标也查不到。OSV 里有这几条 CVE 的记录,但只写了 Git 提交区间,没有 Maven 包的版本区间。于是按坐标查:curl-XPOST https://api.osv.dev/v1/query-d{package:{name:com.fasterxml.jackson.core:jackson-databind,ecosystem:Maven},version:2.21.5}# → 09-14:空,这 4 条一条都没有# → 10-05 重查:已能查出 68497 / 19032 / 83557(77310 在 2.21.5 已修,不该出现)# 对照:同样查 2.21.4,能查出 GHSA-5gvw-p9qm-jgwh09-14 时,按 Maven 坐标查 OSV 的工具同样看不到这 4 条;现在看得到了。2.21.5 为什么不够了08-07 那批 11 条逐条求交集,2.21 线的答案是 2.21.5。新发的 4 条里,77310 在 2.21.5 就修了,另外 3 条(68497 / 19032 / 83557)要 2.21.6。所以停在 2.21.5 的项目,09-14 时是这样:版本落在受影响区间内的:3 条其中 Dependabot 会报的:0 条2.18 线同理,2.18.9 还差 3 条,要 2.18.10;3.1 线 3.1.5 还差 3 条,要 3.1.6。10-05 的现状:这 3 条 Dependabot 都会报了;同时 09-30 新发的 91776 / 91777 把每条线又往上顶了一格 —— 2.21.6 还中这 2 条,要2.21.7;2.18 线要2.18.11;3.1 线要3.1.7。09-30 新发严重度触发条件CVE-2026-91776high 7.5用了JsonTypeInfo(use Id.NAME, defaultImpl …),攻击者能反复提交不同的未知 type id,且 mapper 长期复用:每个未知 id 都在缓存里留一条,内存只增不减CVE-2026-91777high 7.5把不可信 JSON 反序列化进带JsonIdentityInfo的集合或 Map:前向引用按逆序补定义时,比较次数约 N²/2不等漏洞库:补丁在 jar 里能直接看到漏洞库什么时候收录不由你决定,但修复版里的补丁是看得见的。拿相邻两个版本的 jar,比较类文件里的字符串:CVE补丁标记修复版里前一版里19032_isSchemeAllowed(新加的 scheme 白名单检查)2.21.6、3.1.6 有2.21.5、3.1.5 没有68497_validateTimestampLength(新加的长度校验)2.21.6 有2.21.5 没有83557拒绝列表类里多了java/lang/Comparable2.21.6 有2.21.5 没有77310新增类InetAddressValidator2.21.5 有2.21.4 没有每一行都是双向核的:修复版里必须有,前一版里必须没有。只看一个方向的话,「本来就有」和「补丁加的」分不开。09-30 那 2 条用同样的办法也核过(2.18 / 2.21 / 3.1 三条线):CVE补丁标记修复版里前一版里91776MAX_CACHED_TYPE_IDS(给那个缓存加的上限)2.21.7 有2.21.6 没有91777_unresolvedById(把线性查找换成按 id 索引)2.21.7 有2.21.6 没有你真的中了吗版本落在区间里不等于一定中招,每条都有前提:68497:DTO 里有javax.xml.datatype.Duration或XMLGregorianCalendar字段,并且会接收外部 JSON。注意java.time.Duration不是这一条。19032:DTO 里有java.nio.file.Path字段并接收外部 JSON。原文明说:只有 JDK 自带的文件系统时,解析出来的路径无害;要产生挂载、网络访问之类的副作用,classpath 上得有第三方FileSystemProvider(比如 jimfs、各种云存储的 NIO 实现)。77310:DTO 里有InetAddress字段并接收外部 JSON,绑定时会发起 DNS 查询。83557:JsonTypeInfo标在Comparable类型的属性上,并且没配自定义的PolymorphicTypeValidator。原文说activateDefaultTyping()必须传 validator,不受影响。advisory 里的一个笔误77310 的 advisory 在 2.22 线写的是区间 2.22.0, 2.22.1,修复版却填了2.21.1,比区间下限还低。照抄会让 2.22.0 的用户去「升」到 2.21.1。按区间看,正确的修复版是 2.22.1,在 Central 上存在。一个把这些做完的工具jackson-check 在 v0.2.0 把这 4 条并进了判定表;现在是 v0.4.0(10-05),又并入了 09-30 / 10-01 新发的 4 条,jackson-databind和jackson-core两个坐标一共 26 条:java-jarjackson-check.jar ./target ./src它会:从构建产物里读出实际装的 jackson-databind / jackson-core 版本和 groupId(2.x 是com.fasterxml.jackson.core,3.x 是tools.jackson.core);标出哪些条目 GitHub 全局漏洞库还没收录;扫源码里有没有上面那些字段类型,扫依赖 jar 里有没有注册第三方FileSystemProvider;逐条求交集,给出一次修完的版本。一个停在 2.21.5 的项目,10-05 用 v0.4.0 扫出来是这样(真实输出):你的版本落在受影响区间内的:5 条 其中 Dependabot 会报的:5 条(GitHub 全局漏洞库已收录) ... com.fasterxml.jackson.core:jackson-databind 现在 2.21.5 → 升到 2.21.7 盖住 5 条;把目标顶到这么高的是 CVE-2026-9177609-14 用 v0.2.0 扫同一个 jar,印的是「3 条,Dependabot 会报 0 条,升到 2.21.6」。判定表由脚本从一手数据生成:它会逐个按 GHSA 编号去全局库复核「查不到」,并用一条查得到的做对照。09-14 我写「GitHub 哪天收录了,重新生成一次,这个数字就会自己变回 0」—— 10-05 重新生成,databind 这一侧确实从 4 变回了 0。但已经下载的旧 jar 不会自己变,它会继续印 2.21.6。请换 v0.4.0。纯 Java,零依赖,不联网。这篇能证明什么、不能证明什么能证明的:这 4 条 advisory 在 FasterXML 仓库已发布;09-14 在 GitHub 全局漏洞库按编号查是 404,09-28 被收录;09-14 时 OSV 按 Maven 坐标查 2.21.5 查不出这 4 条,10-05 已能查出 3 条;截至 10-05,2.21.6 / 2.18.10 / 3.1.6 还差 09-30 的 2 条,补丁标记在修复版 jar 里双向可见。不能证明的:不是说 GitHub 不会收录。之前的条目都收了,这 4 条最后也收了,只是慢;不是说商业 SCA 也查不到,那些我没有查;不是说版本落在区间里就一定中招,每条都有触发前提;19032 在只有 JDK 自带文件系统时是无害的,不是高危。实际建议:升到 2.21.7 / 2.18.11 / 3.1.7(或同线最新版)。这个版本号本身会过期 —— 本文发出 16 天后它就变了一次。