如果你在排查 CVE-2026-40982(Spring Cloud Config 目录穿越),想升级到官方给的修复版本,可能会遇到一件很困惑的事:Maven 拉不到那个版本。不是网络问题,也不是仓库没同步 —— 是那个版本压根就不在公开仓库里。本文把这件事查清楚:哪几条版本线没有免费补丁、怎么自己验证、为什么 Dependabot 不会提醒你、以及该怎么办。官方给的修复版,一半是买不到的先看官方 advisory 原文列的修复版本:版本线修复版官方标注3.1.x3.1.14Enterprise Support Only4.1.x4.1.10Enterprise Support Only4.2.x4.2.7Enterprise Support Only4.3.x4.3.3OSS5.0.x5.0.3OSS「Enterprise Support Only」这几个字很容易被扫过去。它的实际含义是:这三个版本只发给买了商业支持的客户,不会出现在 Maven Central 上。自己验一下,一条 curl 就够:curl-sIhttps://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-config-server/4.2.7/# HTTP/1.1 404 Not Found3.1.14、4.1.10 一样是 404。对照 Maven Central 上这几条线实际能拿到的最高版本:版本线公开仓库最高版官方要求升到差距3.1.x3.1.103.1.14差 4 个版本4.1.x4.1.74.1.10差 3 个4.2.x4.2.44.2.7差 3 个也就是说:如果你在这三条线上,把小版本升到顶,你依然是受影响的。查版本时别用 search.maven.org 的 solrsearch 接口 —— 我查的时候它说这个构件最新版是 4.3.0,而 repo1.maven.org 的 maven-metadata.xml 里明明白白是 5.0.4。两个数据源打架时,以 repo1 的 metadata 为准,它才是仓库本身。为什么你的扫描器不会提醒你这件事这一段是我觉得最值得说的。看 GitHub advisoryGHSA-6g23-24mc-hx6x的结构化数据:{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,离线跑:java-jarscc-check.jar /opt/apps# 扫目录java-jarscc-check.jar myapp.jar# 扫 Spring Boot fat-jarjava-jarscc-check.jar target/--utf8# Windows 中文乱码时加这个它和一般 SCA 的区别就是多输出一列:你这条线在公开仓库里有没有能升的安全版。[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 为准)。地址仓库:https://github.com/xiaoqiMikko/scc-check下载:https://github.com/xiaoqiMikko/scc-check/releasesMIT,我写的。31 个单元测试,并用 Maven Central 上真实的 3.1.10 / 4.2.4 / 5.0.4 三个构件复验过判定结果。发现误报或漏报请提 issue。安全工具最怕让人误以为安全,任何一条误判都值得提。