CVE-2026-40976 : Spring Boot expose Actuator sans auth (9.1)

Les faits

Spring a publié le 24 avril 2026 un advisory concernant la CVE-2026-40976, une faille de contournement d'autorisation qui affecte les versions 4.0.0 à 4.0.5 de Spring Boot. Notée 9.1 sur l'échelle CVSS 3.1, elle s'exploite à distance, sans authentification ni interaction utilisateur. Le défaut se situe dans la chaîne de filtres de sécurité activée par défaut : celle-ci cesse silencieusement d'appliquer les règles d'autorisation lorsqu'une combinaison précise de configuration et de routage est rencontrée. Concrètement, la vulnérabilité CVE-2026-40976 Spring Boot Actuator laisse les endpoints de supervision — /actuator/env, /actuator/heapdump, /actuator/mappings — accessibles à tout requêteur, exposant variables d'environnement, secrets applicatifs et cartographie interne des services. Un attaquant peut ainsi collecter des identifiants réutilisables et préparer un déplacement latéral. Les équipes exécutant une version 4.0.x doivent vérifier sans délai leur exposition et appliquer le correctif publié.

Les conditions d'exposition sont précises : application web servlet, absence de configuration Spring Security personnalisée, dépendance sur spring-boot-actuator-autoconfigure, et absence de la dépendance spring-boot-health. Dans cette configuration, tous les endpoints Actuator deviennent accessibles à un attaquant réseau anonyme. La faille a été annoncée en parallèle d'autres correctifs (CVE-2026-40972 attaque temporelle DevTools, CVE-2026-40973 contournement de sécurité), pour un total de huit vulnérabilités corrigées dans le cycle d'avril.

Impact et exposition

Les endpoints Actuator ne sont pas anodins. /actuator/env divulgue les variables d'environnement (souvent porteuses de credentials, clés API, URLs de base de données). /actuator/heapdump permet de télécharger l'intégralité du tas Java, où dorment tokens, sessions et secrets en mémoire. /actuator/configprops expose la configuration applicative complète, et /actuator/loggers laisse modifier dynamiquement les niveaux de logs. La chaîne d'exploitation classique consiste à extraire les secrets via /env ou heapdump, puis pivoter vers les bases de données ou services internes avec ces credentials.

L'ACN italienne a relayé l'alerte le 24 avril en classant le risque comme critique, et plusieurs CERT européens ont suivi. La vulnérabilité touche potentiellement des dizaines de milliers d'applications, Spring Boot étant le framework Java le plus utilisé en entreprise. Le piège est insidieux : il ne s'agit pas d'une mauvaise configuration mais du comportement par défaut documenté du framework.

Recommandations

• Mettre à jour vers Spring Boot 4.0.6 ou supérieur via Maven Central
• Vérifier l'exposition des endpoints Actuator depuis l'extérieur du périmètre
• Configurer management.server.port pour exposer Actuator sur un port d'administration distinct
• Restreindre management.endpoints.web.exposure.include à la liste minimale nécessaire
• Ajouter une configuration Spring Security explicite avec règles d'autorisation sur /actuator/**
• Auditer les heapdumps existants en cas de fuite suspecte

Le sujet rejoint la vague récente de RCE Java côté middleware, notamment CVE-2026-34197 sur Apache ActiveMQ Jolokia et CVE-2026-40477 SSTI Thymeleaf. Ces failles partagent un dénominateur commun : des endpoints d'observabilité ou d'administration exposés par défaut, mal protégés.

Décomposition du score CVSS 3.1

Le vecteur complet de la CVE-2026-40976 est AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N, ce qui traduit une exploitation particulièrement accessible. L'accès réseau (AV:N) combiné à une complexité d'attaque faible (AC:L) et à l'absence de privilège requis (PR:N) ou d'interaction utilisateur (UI:N) place cette faille dans la catégorie des vulnérabilités "point-and-click" : un attaquant n'a besoin que de l'URL de l'application. L'impact fort sur la confidentialité (C:H) et l'intégrité (I:H) s'explique par la capacité à lire des secrets en mémoire via /actuator/heapdump et à modifier la configuration applicative via /actuator/env ou /actuator/loggers, sans toutefois affecter directement la disponibilité (A:N) du service.

Comment savoir si mon application est vulnérable ?

Trois vérifications rapides permettent de qualifier l'exposition. D'abord, un scan de dépendances (mvn dependency:tree ou gradle dependencies) pour confirmer la présence de spring-boot-starter-actuator sans spring-boot-health et l'absence de spring-boot-starter-security configuré explicitement. Ensuite, un test direct depuis l'extérieur du réseau : une requête curl -i https://cible/actuator/env renvoyant un code 200 avec un corps JSON contenant des variables d'environnement confirme l'exposition. Un code 401, 403 ou 404 indique en revanche une protection effective ou un endpoint désactivé. Enfin, les outils de gestion de surface d'attaque (Shodan, Censys, ou un scanner interne type Nuclei avec le template dédié à cette CVE) permettent d'auditer un parc applicatif entier en quelques minutes et de prioriser les cibles exposées publiquement.

La segmentation réseau suffit-elle en attendant le patch ?

La segmentation réduit le risque mais ne l'élimine pas. Restreindre l'accès aux endpoints Actuator via un pare-feu applicatif, un reverse proxy filtrant les chemins /actuator/*, ou une règle réseau limitant l'accès au port de management aux seules IP d'administration constitue une mitigation efficace contre un attaquant externe non authentifié. Elle ne protège cependant pas contre un mouvement latéral : un attaquant déjà présent sur le réseau interne, via une autre compromission, conserverait un accès direct aux secrets exposés. La configuration recommandée par Spring — séparer le port de gestion (management.server.port) du port applicatif principal et le binder sur une interface non exposée (127.0.0.1) — reste une mesure complémentaire utile mais temporaire. Seule la montée de version vers Spring Boot 4.0.6 corrige la cause racine du problème, à savoir l'échec silencieux de l'application des règles d'autorisation par défaut.

Ce type de faille rappelle les précédents de 2023-2024 sur Spring Boot Actuator, où plusieurs incidents de fuite de credentials en environnement cloud avaient été tracés à des endpoints /env laissés accessibles par défaut lors de migrations rapides vers des architectures conteneurisées, sans revue systématique de la configuration de sécurité héritée.