Spring Cloud Config 这个 CVE 的补丁,Maven Central 上根本没有

Spring Cloud Config 在 2026-05-07 公布了 CVE-2026-40982:spring-cloud-config-server 存在目录穿越,无需认证,可读取服务器上的任意文件。

这个洞本身不算稀奇。真正让我意外的是去查怎么修的时候 ------ 有三条版本线的修复版,在 Maven Central 上根本不存在。

官方给的修复版,一半是买不到的

先看官方 advisory 原文列的修复版本:

版本线	修复版	官方标注
3.1.x	3.1.14	Enterprise Support Only
4.1.x	4.1.10	Enterprise Support Only
4.2.x	4.2.7	Enterprise Support Only
4.3.x	4.3.3	OSS
5.0.x	5.0.3	OSS

「Enterprise Support Only」这几个字很容易被扫过去。它的实际含义是:这三个版本只发给买了商业支持的客户,不会出现在 Maven Central 上。

自己验一下,一条 curl 就够:

bash 复制代码

curl -sI https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-config-server/4.2.7/
# HTTP/1.1 404 Not Found

3.1.14、4.1.10 一样是 404。

对照 Maven Central 上这几条线实际能拿到的最高版本:

版本线	公开仓库最高版	官方要求升到	差距
3.1.x	3.1.10	3.1.14	差 4 个版本
4.1.x	4.1.7	4.1.10	差 3 个
4.2.x	4.2.4	4.2.7	差 3 个

也就是说:如果你在这三条线上,把小版本升到顶,你依然是受影响的。

查版本时别用 search.maven.org 的 solrsearch 接口 ------ 我查的时候它说这个构件最新版是 4.3.0,而 repo1.maven.org 的 maven-metadata.xml 里明明白白是 5.0.4。两个数据源打架时,以 repo1 的 metadata 为准,它才是仓库本身。

为什么你的扫描器不会提醒你这件事

这一段是我觉得最值得说的。

看 GitHub advisory GHSA-6g23-24mc-hx6x 的结构化数据:

json 复制代码

{"range": "<= 3.1.13",          "first_patched_version": null}
{"range": ">= 4.1.0, <= 4.1.9", "first_patched_version": null}
{"range": ">= 4.2.0, <= 4.2.6", "first_patched_version": null}
{"range": ">= 4.3.0, <= 4.3.2", "first_patched_version": "4.3.3"}
{"range": ">= 5.0.0, <= 5.0.2", "first_patched_version": "5.0.3"}

前三条的 first_patched_version 是 null。

Dependabot、OSV 以及一大批 SCA 工具消费的正是这份数据。它们的核心逻辑是「当前版本 → 建议升到 first_patched_version」,而这里没有可升的目标。

所以这三条线上的用户,大概率既不会收到一个可执行的升级建议,也不会被明确告知「你这条线没有免费补丁」。信息不是被藏起来了,是它落在了数据结构的空档里。

说清楚边界,免得我自己也说过头:这不是「Dependabot 对这个 CVE 完全不管」。对 4.3.x / 5.0.x,它能正常给出 4.3.3 / 5.0.3。问题只出在那三条 null 的线上。

那这三条线该怎么办

只有两条路,没有第三条:

跨版本线升级 ------ 升到 4.3.3+ 或 5.0.3+。这不是小版本升级,要过 Spring Boot / Spring Cloud release train 的兼容性,该测就得测。
买商业支持(Tanzu Spring),拿 3.1.14 / 4.1.10 / 4.2.7。

在升级窗口期之前,至少先把暴露面收掉:Config Server 不要直接暴露在公网 ,前面挂网关并对 /{application}/{profile} 这类路径做鉴权。目录穿越再狠,打不到也没用。

顺便:一个很容易搞混的点

spring-cloud-config-server 是服务端。本 CVE 只影响它。

而 spring-cloud-starter-config 是客户端 (你的业务服务用它去 Config Server 拉配置),不受这个漏洞影响。

按 GitHub 代码搜索,pom.xml 里出现 spring-cloud-config-server 的仓库约 2.4 万 ,而出现 spring-cloud-starter-config 的约 9.9 万 ------ 也就是说,大部分看到这条 CRITICAL 而紧张的人,其实并不受影响。 先分清自己是哪一边。

写了个小工具

scc-check,零依赖单 jar,离线跑:

bash 复制代码

java -jar scc-check.jar /opt/apps          # 扫目录
java -jar scc-check.jar myapp.jar          # 扫 Spring Boot fat-jar
java -jar scc-check.jar target/ --utf8     # Windows 中文乱码时加这个

它和一般 SCA 的区别就是多输出一列:你这条线在公开仓库里有没有能升的安全版。

scss 复制代码

[CRITICAL] /opt/apps/config-server.jar
           版本 4.2.4(4.2 线,依据: Maven 元数据(pom.properties))
           受影响。官方修复版属 Enterprise Support,Maven Central 上不存在
           (该线公开最高版仅 4.2.4)。唯一出路:跨版本线升到 4.3.3+ 或 5.0.3+,
           或购买商业支持。

   线     受影响区间            官方修复版    OSS最高    公开仓库能升到安全版吗
   3.1   <= 3.1.13            (未给出)      3.1.10    不能 ------ 仅商业支持
   4.1   4.1.0 ~ 4.1.9        (未给出)      4.1.7     不能 ------ 仅商业支持
   4.2   4.2.0 ~ 4.2.6        (未给出)      4.2.4     不能 ------ 仅商业支持
   4.3   4.3.0 ~ 4.3.2        4.3.3         4.3.4     能
   5.0   5.0.0 ~ 5.0.2        5.0.3         5.0.4     能

几个刻意的取舍:

判定表是生成的,不是手抄的。 一个脚本从 GitHub advisory 和 repo1.maven.org 的 metadata 直接编译成 Java 表,并带断言:区间数不足、null 的条数不对、版本线解析不出来,直接中止,不生成文件。手抄的表在源数据变化时不会报错,只会安静地过期。
不判 4.0.x。 advisory 的任何区间都没覆盖 4.0.x(4.0.0 > 3.1.13,不落在无下界那条里)。工具只报「不在官方覆盖范围内」,不报 CRITICAL ------ 靠推测填判定表,会让人做错决定。
读不出版本时明说「判不了」。 Spring Cloud 用 release train BOM 统一管版本,pom.xml 里常常根本没有 <version>;scope 是 test / provided 的不传递;被 XML 注释包住的依赖会被剥掉。这几种情况都不会被当成「安全」。

它不是什么

不是通用 SCA,只查这一个 CVE。
只做版本比对,不检测你的 Config Server 是否真的暴露在公网、有没有 WAF。判定结果是排查起点,不是安全结论。
CVSS 官方给的是 8.2 (High)(GitHub 那边标 critical,以 spring.io 为准)。

地址

仓库:github.com/xiaoqiMikko...
下载:github.com/xiaoqiMikko...

MIT,我写的。31 个单元测试,并用 Maven Central 上真实的 3.1.10 / 4.2.4 / 5.0.4 三个构件复验过判定结果。

发现误报或漏报请提 issue。 安全工具最怕让人误以为安全,任何一条误判都值得提。