xiaoqimikko/scc-checkVerificatore offline per Spring Cloud Config CVE-2026-40982 — ti dice se la tua linea di versione dispone di una correzione OSS (3.1.x/4.1.x/4.2.x: non la dispone)
Strumento di verifica offline per Spring Cloud Config CVE-2026-40982 —— zero dipendenze, singolo jar, nessuna connessione di rete.
Non risponde alla domanda «sono interessato o no», ma a quella più scomoda:
La mia linea di versione ha davvero una versione sicura a cui aggiornare su Maven Central?
Per le tre linee 3.1.x / 4.1.x / 4.2.x, la risposta è no.
L'advisory ufficiale (spring.io/security/cve-2026-40982) indica come versione corretta:
| Linea di versione | Versione ufficiale corretta | Disponibilità | Versione massima di quella linea su Maven Central | Puoi aggiornare? |
|---|---|---|---|---|
| 3.1.x | 3.1.14 | Solo Enterprise Support | 3.1.10 | ❌ |
| 4.1.x | 4.1.10 | Solo Enterprise Support | 4.1.7 | ❌ |
| 4.2.x | 4.2.7 | Solo Enterprise Support | 4.2.4 | ❌ |
| 4.3.x | 4.3.3 | OSS | 4.3.4 | ✅ |
| 5.0.x | 5.0.3 | OSS | 5.0.4 | ✅ |
Quelle tre versioni correttive non sono nei repository pubblici. Chiunque può verificarlo:
curl -sI https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-config-server/4.2.7/
# HTTP/1.1 404 Not Found
E gli strumenti automatizzati non te lo diranno — nei dati strutturati dei GitHub advisory,
il first_patched_version di queste tre linee è proprio null:
{"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"}
Dependabot / OSV consumano esattamente questi dati. Senza una destinazione di aggiornamento, non è possibile fornire suggerimenti di aggiornamento.
java -jar scc-check.jar <目录或 jar/war 路径>
# 中文乱码时(Windows 控制台代码页与 Java 判断常常对不上):
java -jar scc-check.jar target/ --utf8
Richiede Java 17+. Zero dipendenze a runtime, può essere inserito direttamente in un ambiente offline.
Codici di uscita: 2 linea di versione non aggiornabile · 1 interessato ma aggiornabile / non determinabile · 0 non trovato · 3 errore di utilizzo o percorso
.jar / .warBOOT-INF/lib/, WEB-INF/lib/)META-INF/maven/.../pom.properties) — riconoscibili anche se il jar è stato rinominatopom.xml1. Non considera il client come interessato.
Questa CVE interessa solo il spring-cloud-config-server lato server. I progetti che includono spring-cloud-starter-config
(client) non sono interessati; lo strumento te lo dice esplicitamente, invece di farti preoccupare inutilmente.
2. Non emette verdetti per la 4.0.x.
Nessun intervallo dell'advisory ufficiale copre la 4.0.x (4.0.0 > 3.1.13, non rientra nell'intervallo senza limite inferiore).
Lo strumento segnala solo «al di fuori della copertura ufficiale», non riporta CRITICAL — riempire la tabella dei verdetti basandosi su supposizioni porta a decisioni sbagliate.
3. Quando non riesce a leggere la versione, dice esplicitamente «non determinabile», mai la considera sicura.
Spring Cloud gestisce le versioni tramite release train, e nel pom.xml spesso non c'è affatto <version>.
In questo caso lo strumento ti indica di scansionare gli artefatti di build, invece di fingere di non aver trovato problemi.
Allo stesso modo, le dipendenze con scope pari a test / provided non vengono propagate agli utilizzatori e non contano come superficie esposta;
le dipendenze racchiuse in commenti XML vengono rimosse.
tools/gen_rules.py compila RuleTable.java da due fonti dati primarie:
GHSA-6g23-24mc-hx6x → intervalli interessati + versione corretta ufficialemaven-metadata.xml di repo1.maven.org → versioni effettivamente esistenti nel repository pubblicoCon quattro asserzioni: numero di intervalli ≥5, first_patched=null ≥3, linee di versione ≥5, verdetti
ENTERPRISE_ONLY ≥3. Se una qualsiasi non è soddisfatta, si interrompe immediatamente e non genera il file —
altrimenti un singolo errore di parsing produrrebbe una tabella vuota, e i test unitari resterebbero comunque tutti verdi su una tabella vuota.
python tools/gen_rules.py # 重新生成判定表
mvn test # 31 个测试
Questo strumento esegue solo il confronto delle versioni e non verifica se il tuo Config Server sia effettivamente esposto su Internet pubblico, se disponga di un WAF o se sia già stato mitigato in altro modo. Il risultato è un punto di partenza per l'indagine, non una conclusione di sicurezza. Fai riferimento agli advisory ufficiali.
MIT
Questo strumento risponde alla domanda «sono stato colpito o no». Le seguenti domande non è in grado di rispondere, ma puoi contattarmi per farlo:
📮 [email protected] —— Descrivi la situazione e entro 24 ore ti fornirò una risposta scritta di una pagina: se è fattibile, dov'è la difficoltà, all'incirca quanto tempo serve. Questo passo è gratuito e non richiede alcun impegno da parte tua.
| Codice | Significato |
|---|---|
0 | Scansione completata, e ogni file è stato effettivamente letto, nessun risultato che richieda un tuo intervento |
4 | Ci sono file illeggibili —— non è uno zip, contenuto troncato, o lettura fallita |
🔴 Il codice 4 è stato aggiunto il 2026-09-09, e vale la pena spiegare il motivo.
Prima di allora, i file illeggibili lasciavano solo una riga di avviso nell'output, mentre il codice di uscita restava 0 ——
la traccia è per le persone, mentre CI e script guardano il codice di uscita, quindi «non sono riuscito a leggerlo» in automazione equivaleva a «superato».
Un jar corrotto, cifrato o scaricato in modo incompleto diventava silenziosamente un «nessun problema rilevato».
«Non riesco a leggerlo» e «sei al sicuro» devono essere due frasi distinte.
⚠️ Un jar vuoto legittimo non conta come illeggibile (un record EOCD di 22 byte è uno zip vuoto reale) e non attiva 4 ——
con troppi falsi allarmi, nessuno guarda più quelli veri.
Per il significato degli altri codici di uscita, vedi le sezioni precedenti sui livelli di verdetto e le istruzioni d'uso.