Deux CVE critiques publiées cette semaine sur deux projets open source sans rapport l'un avec l'autre : X-SpringBoot, un socle d'application Spring Boot, et Contrast, d'Edgeless Systems, qui orchestre des conteneurs confidentiels sur Kubernetes.
Le fil conducteur : dans les deux cas, le mécanisme de sécurité existe et semble fonctionner, mais il ne vérifie pas la chose qui compte. Un code de vérification qui ne vérifie rien, une politique d'intégrité qui laisse passer une image non vérifiée.
| X-SpringBoot | Contrast | |
|---|---|---|
| CVE | CVE-2026-97063 | CVE-2026-100833 |
| CVSS 3.1 | 9.1 CRITICAL | 9.6 CRITICAL |
| Vecteur | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N | AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N |
| Publication NVD | 2026-09-25 | 2026-09-27 |
| Versions (NVD) | jusqu'à 6.0 incluse | 1.14.0 à 1.23.0 |
| Correctif | aucun mentionné | 1.23.1 |
| CISA KEV | non (à la date de rédaction) | non (à la date de rédaction) |
X-SpringBoot — CVE-2026-97063 : le code de connexion renvoyé à l'attaquant
X-SpringBoot through 6.0 returns login verification codes in HTTP responses from unauthenticated endpoints [...] without sending them to account owners.
La connexion par code SMS ou email repose sur une seule hypothèse : seul le titulaire du téléphone ou de la boîte mail reçoit le code. Ici, les endpoints qui génèrent ces codes les renvoient directement dans la réponse HTTP, à quiconque les appelle, sans authentification.
Conséquence : connaître le numéro de mobile ou l'adresse email d'un utilisateur suffit pour se connecter à sa place. NVD parle explicitement de prise de contrôle de compte. Pas d'interaction de la victime, pas de complexité : d'où le 9.1.
NVD ne dit pas comment le défaut est apparu. Il ressemble à un classique : un code renvoyé dans la réponse pour faciliter les tests, jamais retiré avant la production.
Versions et correctif
NVD indique « through 6.0 » : toutes les versions jusqu'à 6.0 incluse sont concernées, et aucune version corrigée n'est mentionnée à la date de rédaction. Vérifie le dépôt du projet pour un éventuel correctif. Comme X-SpringBoot est un socle qu'on forke pour bâtir sa propre application, ton code dérivé hérite probablement du défaut même si tu ne suis plus l'amont.
Détection
- Dans ton code : les contrôleurs de demande de code SMS / email renvoient-ils le code dans leur réponse ? Une revue de quelques minutes suffit à trancher
- Dans les journaux : volume anormal de demandes de code pour des comptes différents depuis une même source
- Connexions par code sans envoi SMS ou email correspondant côté fournisseur
Mitigation
- Retirer le code de la réponse HTTP : il ne doit transiter que par le canal SMS ou email.
- Limiter le débit des demandes de code, par compte et par adresse IP.
- Invalider les sessions ouvertes par code depuis la mise en production du défaut, si les journaux ne permettent pas d'écarter un abus.
Contrast — CVE-2026-100833 : une image de conteneur substituable
Contrast (edgelesssys/contrast) versions 1.14.0 before 1.23.1 generate runtime policies that fail to detect all container image substitutions.
Contrast exécute des conteneurs dans des environnements d'exécution confidentiels (Kata Containers sur matériel à chiffrement mémoire). Sa promesse est forte : même l'administrateur du cluster Kubernetes ne doit pas pouvoir altérer la charge de travail. Ce qui la garantit, c'est une politique d'exécution générée par Contrast, qui fige l'empreinte des images autorisées.
Selon NVD, un rebase raté lors d'une mise à jour de Kata Containers a réintroduit une règle de politique qui accepte certaines entrées de stockage sans vérifier l'empreinte (digest) de l'image. Un attaquant ayant accès à l'API de l'agent Kata — typiquement un administrateur du cluster, qui est précisément dans le modèle de menace de Contrast — peut alors substituer une autre image à celle attendue, à condition qu'elle respecte les autres règles de la politique.
Le PR:L peut sembler rassurant. Il ne l'est pas ici : l'attaquant visé par Contrast est quelqu'un qui a des privilèges sur l'infrastructure. Le S:C traduit la rupture de la frontière que le produit promet.
Versions et correctif
NVD est explicite : versions 1.14.0 à 1.23.1 exclue. Corrigé en 1.23.1.
Détection
- Version de Contrast utilisée pour générer les politiques de chaque déploiement : toute politique générée entre 1.14.0 et 1.23.0 est concernée
- Empreintes des images effectivement lancées dans les pods confidentiels, comparées aux empreintes attendues
- Journaux d'audit Kubernetes : modifications de pods ou de déploiements confidentiels par des comptes d'administration
Mitigation
- Passer en Contrast 1.23.1.
- Régénérer les politiques d'exécution avec cette version et redéployer : mettre à jour l'outil ne corrige pas les politiques déjà générées.
- Revoir l'attestation : les secrets délivrés à des charges dont l'intégrité n'était pas garantie sont à considérer comme exposés et à faire tourner.
Pourquoi surveiller en continu vos dépendances open source
Ni l'un ni l'autre de ces projets n'apparaît dans un inventaire de logiciels « classiques » : l'un est forké dans du code maison, l'autre est un outil d'infrastructure. C'est justement là que les CVE critiques passent inaperçues.
Avec cveo.tech, déclare aussi tes composants open source et tes outils d'infrastructure, et reçois une alerte dès qu'une CVE critique les concerne.