xiaoqimikko/scc-checkVérificateur hors ligne pour Spring Cloud Config CVE-2026-40982 — vous indique si votre ligne de version dispose d'un correctif OSS (3.1.x/4.1.x/4.2.x : ce n'est pas le cas).
Outil de diagnostic hors ligne pour Spring Cloud Config CVE-2026-40982 —— zéro dépendance, un seul jar, sans connexion réseau.
Il ne répond pas à la question « suis-je affecté ? », mais à la question plus pénible :
Sur ma branche de version, existe-t-il sur Maven Central une version sécurisée vers laquelle migrer ?
Pour les trois branches 3.1.x / 4.1.x / 4.2.x, la réponse est non.
Avis officiel (spring.io/security/cve-2026-40982) indiquant la version corrigée :
| Ligne de version | Version corrigée officielle | Disponibilité | Version la plus élevée de cette ligne sur Maven Central | Pouvez-vous effectuer la mise à niveau |
|---|---|---|---|---|
| 3.1.x | 3.1.14 | Enterprise Support Only | 3.1.10 | ❌ |
| 4.1.x | 4.1.10 | Enterprise Support Only | 4.1.7 | ❌ |
| 4.2.x | 4.2.7 | Enterprise Support Only | 4.2.4 | ❌ |
| 4.3.x | 4.3.3 | OSS | 4.3.4 | ✅ |
| 5.0.x | 5.0.3 | OSS | 5.0.4 | ✅ |
Ces trois versions correctives ne se trouvent pas dans les dépôts publics. N'importe qui peut le vérifier :
curl -sI https://repo1.maven.org/maven2/org/springframework/cloud/spring-cloud-config-server/4.2.7/
# HTTP/1.1 404 Not Found
Et les outils automatisés ne vous le diront pas — dans les données structurées des avis GitHub,
le first_patched_version de ces trois lignes est tout simplement 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 consomment précisément ces données. Sans cible de mise à niveau, aucune recommandation de mise à niveau ne peut être fournie.
java -jar scc-check.jar <目录或 jar/war 路径>
# 中文乱码时(Windows 控制台代码页与 Java 判断常常对不上):
java -jar scc-check.jar target/ --utf8
Nécessite Java 17+. Zéro dépendance à l'exécution, peut être déposé directement dans un environnement hors ligne.
Codes de sortie : 2 une branche de version ne peut pas être mise à niveau · 1 affecté mais peut être mis à niveau / indéterminable · 0 non détecté · 3 erreur d'utilisation ou de chemin
.jar / .warBOOT-INF/lib/, WEB-INF/lib/)META-INF/maven/.../pom.properties) — reconnaissables même si le jar a été renommépom.xml1. Ne compte pas le client comme affecté.
Cette CVE n'affecte que le spring-cloud-config-server côté serveur. Les projets qui incluent spring-cloud-starter-config
(client) ne sont pas affectés ; l'outil vous le dit clairement, plutôt que de vous faire paniquer inutilement.
2. Ne rend pas de verdict sur 4.0.x.
Aucune des plages de l'avis officiel ne couvre 4.0.x (4.0.0 > 3.1.13, ne tombe pas dans la plage sans borne inférieure).
L'outil signale seulement « hors du périmètre couvert par l'avis officiel », sans signaler CRITICAL — remplir la table de verdicts par conjecture ferait prendre de mauvaises décisions.
3. Lorsqu'il ne peut pas lire la version, il dit explicitement « indéterminable », jamais ne la considère comme sûre.
Spring Cloud gère les versions via des release trains, et le pom.xml n'a souvent aucun <version>.
Dans ce cas, l'outil vous indique d'analyser les artefacts de build, plutôt que de prétendre qu'aucun problème n'a été trouvé.
De même, les dépendances dont le scope est test / provided ne sont pas transmises aux consommateurs et ne comptent pas comme surface d'exposition ;
les dépendances entourées de commentaires XML sont supprimées.
tools/gen_rules.py compile RuleTable.java à partir de deux sources de données primaires :
GHSA-6g23-24mc-hx6x → plages affectées + versions officiellement corrigéesmaven-metadata.xml de repo1.maven.org → versions réellement existantes dans le dépôt publicAvec quatre assertions : nombre de plages ≥5, first_patched=null ≥3, branches de version ≥5, verdicts
ENTERPRISE_ONLY ≥3. Si l'une d'elles n'est pas satisfaite, l'exécution s'arrête immédiatement, aucun fichier n'est généré —
sinon, un échec d'analyse produirait une table vide, et les tests unitaires passeraient tous au vert face à une table vide.
python tools/gen_rules.py # 重新生成判定表
mvn test # 31 个测试
Cet outil se contente de comparer des versions ; il ne vérifie pas si votre Config Server est réellement exposé sur l'Internet public, s'il dispose d'un WAF, ou s'il a déjà été atténué par d'autres moyens. Le résultat du verdict est un point de départ pour l'investigation, pas une conclusion de sécurité. Référez-vous aux avis officiels.
MIT
Cet outil répond à la question « suis-je touché ou non ». Les cas suivants, il ne peut pas les traiter ; vous pouvez faire appel à moi pour :
📮 [email protected] —— exposez la situation, je vous fournis une réponse écrite d'une page sous 24 heures : est-ce faisable, où sont les difficultés, combien de temps environ. Cette étape est gratuite, et vous n'avez rien à vous engager à l'avance.
| Code | Signification |
|---|---|
0 | Analyse terminée, et chaque fichier a réellement été lu, aucune découverte nécessitant votre action |
4 | Un fichier est illisible —— ce n'est pas un zip, contenu tronqué, ou échec de lecture |
🔴 Le code 4 a été ajouté le 2026-09-09, et la raison de son ajout mérite d'être expliquée.
Avant cela, un fichier illisible ne laissait qu'une ligne d'avertissement dans la sortie, alors que le code de sortie restait 0 ——
la trace est destinée aux humains, tandis que la CI et les scripts regardent le code de sortie ; ainsi, « je n'ai pas pu le lire » équivalait à « validé » dans l'automatisation.
Un jar corrompu, chiffré ou téléchargé incomplètement se transformait silencieusement en un « aucun problème détecté ».
« Je ne peux pas le lire » et « vous êtes en sécurité » doivent être deux phrases distinctes.
⚠️ Un jar vide légitime ne compte pas comme illisible (un enregistrement EOCD de 22 octets est un vrai zip vide), et ne déclenche pas 4 ——
trop de fausses alertes, et plus personne ne regarde les vraies.