Spring Boot Security Vulnerabilities in 2026: CVE-2026-40976 (CVSS 9.1), Zombie Dependencies & the Java Hardening GuideVulnérabilités Spring Boot en 2026 : CVE-2026-40976 (CVSS 9.1), Dépendances Zombies & Guide de Durcissement Java

Spring Boot powers an estimated 30% of all Java backend applications in production — and 2026 has been a rough year for it. The Spring ecosystem logged 37 CVEs in just two months, according to HeroDevs’ April 2026 roundup. The headline vulnerability, CVE-2026-40976 (CVSS 9.1), affects Spring Boot 4.0 in a particularly insidious way: a dependency split introduced in 4.0 can cause the entire default security filter chain to become ineffective, leaving all application endpoints unauthenticated — with no error, no warning, and no indication that protection has been silently disabled. Beyond direct Spring CVEs, HeroDevs’ May 2026 patch roundup identified 24 upstream CVEs across Tomcat, Netty, Thymeleaf, Jetty, and pgjdbc that reach Spring Boot applications through the managed-dependency BOM but will never be fixed in end-of-life versions. And the MavenGate research reminds us that 18% of Maven Central dependency domains are available for purchase — ready to be turned into a supply chain attack. This guide covers the real CVEs, how to detect exposure, and the concrete steps to harden your Spring Boot dependency pipeline in 2026.

Spring Boot alimente environ 30 % de toutes les applications Java backend en production — et 2026 a été une année difficile. L’écosystème Spring a enregistré 37 CVE en seulement deux mois, selon le bilan d’avril 2026 de HeroDevs. La vulnérabilité phare, CVE-2026-40976 (CVSS 9.1), touche Spring Boot 4.0 d’une manière particulièrement insidieuse : une scission de dépendance introduite en 4.0 peut rendre la chaîne de filtres de sécurité par défaut complètement inefficace, laissant tous les endpoints de l’application non authentifiés — sans erreur, sans avertissement, sans aucune indication que la protection a été silencieusement désactivée. Au-delà des CVE Spring directes, le bilan de mai 2026 de HeroDevs a identifié 24 CVE en amont touchant Tomcat, Netty, Thymeleaf, Jetty et pgjdbc qui atteignent les applications Spring Boot via le BOM de dépendances gérées, mais ne seront jamais corrigées dans les versions en fin de vie. Et la recherche MavenGate rappelle que 18 % des domaines de dépendances Maven Central sont disponibles à l’achat — prêts à être transformés en attaques supply chain. Ce guide couvre les CVE réelles, comment détecter l’exposition et les étapes concrètes pour durcir votre pipeline de dépendances Spring Boot en 2026.

CVE-2026-40976 (CVSS 9.1): When Spring Boot’s Default Security Silently Disappears

CVE-2026-40976 (CVSS 9.1) : Quand la Sécurité par Défaut de Spring Boot Disparaît Silencieusement

Spring Boot 4.0 split the spring-boot-actuator module into two separate dependencies: spring-boot-actuator-autoconfigure and spring-boot-health. This architectural change introduced a critical edge case: applications that depend on spring-boot-actuator-autoconfigure but not on spring-boot-health trigger an unintended condition where Spring Boot’s default web security filter chain becomes completely inoperative. The result is that every endpoint in the application becomes reachable without authentication, including sensitive admin endpoints, internal APIs, and business data endpoints.

Spring Boot 4.0 a scindé le module spring-boot-actuator en deux dépendances séparées : spring-boot-actuator-autoconfigure et spring-boot-health. Ce changement architectural a introduit un cas limite critique : les applications qui dépendent de spring-boot-actuator-autoconfigure mais pas de spring-boot-health déclenchent une condition non voulue où la chaîne de filtres de sécurité web par défaut de Spring Boot devient complètement inopérante. Le résultat : chaque endpoint de l’application devient accessible sans authentification, y compris les endpoints admin sensibles, les API internes et les endpoints de données métier.

The vulnerability only affects applications that meet all four conditions:

La vulnérabilité n’affecte que les applications qui réunissent les quatre conditions :

• Servlet-based web application (not reactive/WebFlux)
• Application web basée sur les servlets (pas reactive/WebFlux)
• No custom Spring Security configuration — relying entirely on the default filter chain
• Pas de configuration Spring Security personnalisée — repose entièrement sur la chaîne de filtres par défaut
• Depends on spring-boot-actuator-autoconfigure
• Dépend de spring-boot-actuator-autoconfigure
• Does not depend on spring-boot-health
• Ne dépend pas de spring-boot-health

Affected versions: Spring Boot 4.0.0 through 4.0.5. Fix: upgrade to Spring Boot 4.0.6 (released April 23, 2026). Alternatively, add an explicit Spring Security configuration to your application, which bypasses the default chain entirely.

Versions affectées : Spring Boot 4.0.0 à 4.0.5. Correctif : passer à Spring Boot 4.0.6 (publié le 23 avril 2026). Alternativement, ajouter une configuration Spring Security explicite dans l’application, ce qui contourne complètement la chaîne par défaut.

<!-- pom.xml — upgrade to fix CVE-2026-40976 -->
<parent>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter-parent</artifactId>
  <version>4.0.6</version>  <!-- was 4.0.0–4.0.5 -->
</parent>

// build.gradle.kts — upgrade to fix CVE-2026-40976
plugins {
    id("org.springframework.boot") version "4.0.6"  // was 4.0.0–4.0.5
}

The Full CVE Picture: 37 Spring Vulnerabilities in 2 Months

Le Tableau Complet des CVE : 37 Vulnérabilités Spring en 2 Mois

CVE-2026-40976 is the most severe, but it is far from alone. HeroDevs’ April 2026 roundup catalogued 37 Spring-ecosystem CVEs across Spring Boot, Spring Security, Spring Framework, and Spring Cloud Config. Here are the key ones developers must understand:

CVE-2026-40976 est la plus sévère, mais elle est loin d’être seule. Le bilan d’avril 2026 de HeroDevs a répertorié 37 CVE dans l’écosystème Spring — Spring Boot, Spring Security, Spring Framework et Spring Cloud Config. Voici les principales que les développeurs doivent comprendre :

The Zombie Dependency Problem: 24 Upstream CVEs Spring Boot Can’t Fix

Le Problème des Dépendances Zombies : 24 CVE en Amont que Spring Boot Ne Peut Pas Corriger

The direct Spring CVEs are just one part of the problem. Spring Boot uses a managed-dependency BOM (Bill of Materials) that pins specific versions of hundreds of third-party libraries: Tomcat, Netty, Thymeleaf, Jetty, pgjdbc, Jackson, Hibernate, and more. When Spring Boot reaches end-of-life, the framework stops receiving BOM updates — but the upstream libraries keep accumulating CVEs.

Les CVE Spring directes ne représentent qu’une partie du problème. Spring Boot utilise un BOM (Bill of Materials) de dépendances gérées qui épinglé des versions spécifiques de centaines de bibliothèques tierces : Tomcat, Netty, Thymeleaf, Jetty, pgjdbc, Jackson, Hibernate et bien d’autres. Lorsque Spring Boot atteint sa fin de vie, le framework cesse de recevoir des mises à jour du BOM — mais les bibliothèques en amont continuent d’accumuler des CVE.

HeroDevs’ May 2026 patch roundup found 24 unique upstream CVEs across just five components that are reachable through the Spring Boot managed-dependency BOM. These are real CVEs in widely-used components, but teams running EOL Spring Boot versions will never receive a BOM update that addresses them:

Le bilan de patch de mai 2026 de HeroDevs a trouvé 24 CVE en amont uniques dans seulement cinq composants accessibles via le BOM de dépendances gérées de Spring Boot. Ce sont de vraies CVE dans des composants largement utilisés, mais les équipes exécutant des versions Spring Boot en fin de vie ne recevront jamais de mise à jour du BOM qui les corrige :

• Apache Tomcat — embedded servlet container, new CVEs every quarter
• Apache Tomcat — conteneur servlet embarqué, nouvelles CVE chaque trimestre
• Netty — async networking layer used by Spring WebFlux
• Netty — couche réseau asynchrone utilisée par Spring WebFlux
• Thymeleaf — SSTI vulnerabilities in 3.1.4 and 3.1.5 (CVSS 9.0+)
• Thymeleaf — vulnérabilités SSTI dans 3.1.4 et 3.1.5 (CVSS 9.0+)
• Jetty — alternative embedded server option in Spring Boot
• Jetty — option de serveur embarqué alternatif dans Spring Boot
• pgjdbc — PostgreSQL JDBC driver, data layer exposure
• pgjdbc — driver JDBC PostgreSQL, exposition de la couche de données

The implication is stark: checking only your direct Spring Boot version is not enough. You must also audit the transitive dependency tree for CVEs in these embedded components. Tools like OWASP Dependency-Check, Gradle dependency verification, or a continuous scanner like OptiBot are required for complete coverage.

L’implication est claire : vérifier uniquement votre version directe de Spring Boot ne suffit pas. Vous devez également auditer l’arbre de dépendances transitives pour les CVE dans ces composants embarqués. Des outils comme OWASP Dependency-Check, la vérification des dépendances Gradle, ou un scanner continu comme OptiBot sont nécessaires pour une couverture complète.

Thymeleaf SSTI: When Your View Layer Becomes a Remote Code Execution Vector

Thymeleaf SSTI : Quand Votre Couche Vue Devient un Vecteur d’Exécution de Code à Distance

Thymeleaf Server-Side Template Injection (SSTI) is a recurring vulnerability class in Spring MVC applications. CVE-2026-40478 and CVE-2026-41901 (both CVSS 9.0+) are the latest incarnations: they allow RCE when user-controlled input reaches a Thymeleaf expression context. The classic pattern is passing unsanitized user input directly into a Thymeleaf template path or model attribute that is then used in an expression:

L’injection de template côté serveur (SSTI) Thymeleaf est une classe de vulnérabilité récurrente dans les applications Spring MVC. CVE-2026-40478 et CVE-2026-41901 (toutes deux CVSS 9.0+) en sont les dernières occurrences : elles permettent une RCE lorsque des entrées contrôlées par l’utilisateur atteignent un contexte d’expression Thymeleaf. Le pattern classique consiste à passer des entrées utilisateur non assainies directement dans un chemin de template Thymeleaf ou un attribut de modèle utilisé dans une expression :

// VULNERABLE — user input reaches template resolution
@GetMapping("/view")
public String renderView(@RequestParam String template, Model model) {
    // Attacker sends: template=__${T(java.lang.Runtime).getRuntime().exec('...')}__::
    return template;  // NEVER use user input as template name
}

// SAFE — use allowlist for template names
@GetMapping("/view")
public String renderView(@RequestParam String page, Model model) {
    List<String> allowed = List.of("home", "profile", "dashboard");
    if (!allowed.contains(page)) {
        throw new ResponseStatusException(HttpStatus.BAD_REQUEST);
    }
    return page;
}

The fix is straightforward: never use user input to determine the template name or path. Use a strict allowlist. Also upgrade to Thymeleaf 3.1.6+ which addresses CVE-2026-40478 and CVE-2026-41901 — but note that Spring Boot EOL versions will not pin this version automatically in their BOM.

Le correctif est simple : ne jamais utiliser les entrées utilisateur pour déterminer le nom ou le chemin du template. Utilisez une liste blanche stricte. Passez également à Thymeleaf 3.1.6+ qui corrige CVE-2026-40478 et CVE-2026-41901 — mais notez que les versions Spring Boot en fin de vie n’épingleront pas automatiquement cette version dans leur BOM.

Securing Spring Boot Actuator: The Endpoint That Developers Keep Forgetting

Sécuriser Spring Boot Actuator : L’Endpoint que les Développeurs Oublient Toujours

Spring Boot Actuator provides production-ready endpoints — /actuator/health, /actuator/env, /actuator/heapdump, /actuator/loggers — that expose sensitive application internals. CVE-2026-22731 and CVE-2026-22733 exploit improper endpoint mapping to bypass Actuator authentication. Beyond these CVEs, misconfigured Actuator is a perennial finding in Spring Boot security audits: /actuator/env exposes all environment variables including secrets, /actuator/heapdump can leak credentials from heap memory, and /actuator/jolokia (if present) enables JMX-based RCE.

Spring Boot Actuator fournit des endpoints prêts pour la production — /actuator/health, /actuator/env, /actuator/heapdump, /actuator/loggers — qui exposent des informations internes sensibles de l’application. CVE-2026-22731 et CVE-2026-22733 exploitent un mappage incorrect des endpoints pour contourner l’authentification Actuator. Au-delà de ces CVE, un Actuator mal configuré est une découverte pérenne lors des audits de sécurité Spring Boot : /actuator/env expose toutes les variables d’environnement, y compris les secrets, /actuator/heapdump peut faire fuiter des identifiants de la mémoire heap, et /actuator/jolokia (si présent) permet une RCE basée sur JMX.

# application.yml — Actuator hardening (2026 best practices)
management:
  endpoints:
    web:
      exposure:
        include: "health,info"   # Expose only what you need
        exclude: "env,heapdump,jolokia,shutdown,loggers"
  endpoint:
    health:
      show-details: "when-authorized"
  server:
    port: 8081   # Separate management port, not exposed publicly

spring:
  security:
    # Explicitly protect management endpoints
    # Never rely solely on Spring Boot's default filter chain

MavenGate: 6,170 Maven Central Domains Available for Hijacking Today

MavenGate : 6 170 Domaines Maven Central Disponibles au Détournement Aujourd’hui

The supply chain threat for Java extends well beyond direct CVEs. The MavenGate research from Oversecured analyzed 33,938 domain names corresponding to Maven Central dependencies and found that 6,170 (18.18%) of them were available for purchase. Because Maven Central uses domain-based group ID ownership verification (e.g., com.example requires ownership of example.com), purchasing an expired domain grants the attacker the ability to publish packages under that group ID and inject malicious code into any project that pulls those dependencies. Affected companies notified in the original research included Google, Facebook, Amazon, Microsoft, Adobe, LinkedIn, and Netflix.

La menace supply chain pour Java s’étend bien au-delà des CVE directes. La recherche MavenGate d’Oversecured a analysé 33 938 noms de domaine correspondant à des dépendances Maven Central et a constaté que 6 170 (18,18%) d’entre eux étaient disponibles à l’achat. Parce que Maven Central utilise la vérification de propriété du group ID basée sur le domaine (ex. : com.example nécessite la propriété de example.com), l’achat d’un domaine expiré donne à l’attaquant la possibilité de publier des packages sous ce group ID et d’injecter du code malveillant dans tout projet qui tire ces dépendances. Les entreprises notifiées lors de la recherche originale incluaient Google, Facebook, Amazon, Microsoft, Adobe, LinkedIn et Netflix.

The practical defense is dependency verification. Both Maven and Gradle support checksum and signature verification:

La défense pratique est la vérification des dépendances. Maven et Gradle prennent tous deux en charge la vérification des sommes de contrôle et des signatures :

// build.gradle.kts — enable dependency verification (Gradle 6.2+)
// Run: ./gradlew --write-verification-metadata sha256 to generate
// This creates gradle/verification-metadata.xml with checksums for all deps

dependencyVerification {
    // Will fail build if any dependency checksum doesn't match
}

<!-- Maven: use maven-enforcer-plugin to require dependency checksums -->
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-enforcer-plugin</artifactId>
  <version>3.5.0</version>
  <dependencies>
    <dependency>
      <groupId>org.commonjava.maven.enforcer</groupId>
      <artifactId>artifactsize-enforcer-rule</artifactId>
    </dependency>
  </dependencies>
</plugin>

OWASP Dependency-Check & Gradle Dependency Locking: Your CI/CD Security Gate

OWASP Dependency-Check & Verrouillage des Dépendances Gradle : Votre Porte de Sécurité CI/CD

OWASP Dependency-Check scans your project’s dependencies against the NVD CVE database. The Gradle plugin (v12.2.2 as of May 2026) and Maven plugin integrate directly into your build pipeline. The key configuration is setting a failBuildOnCVSS threshold — start at 9.0 for critical-only gating, then progressively lower to 7.0 as false positives are suppressed:

OWASP Dependency-Check analyse les dépendances de votre projet par rapport à la base de données CVE du NVD. Le plugin Gradle (v12.2.2 en mai 2026) et le plugin Maven s’intègrent directement dans votre pipeline de build. La configuration clé est la définition d’un seuil failBuildOnCVSS — commencez à 9.0 pour un blocage critique uniquement, puis abaissez progressivement à 7.0 au fur et à mesure que les faux positifs sont supprimés :

// build.gradle.kts
plugins {
    id("org.owasp.dependencycheck") version "12.2.2"
}

dependencyCheck {
    failBuildOnCVSS = 9.0f          // Start strict, lower over time
    suppressionFile = "owasp-suppressions.xml"
    formats = listOf("HTML", "JSON", "SARIF")
    nvd {
        apiKey = System.getenv("NVD_API_KEY")  // Faster updates
    }
    analyzers {
        ossIndex {
            enabled = true           // Sonatype OSS Index for broader coverage
        }
    }
}

<!-- pom.xml — OWASP Dependency-Check Maven plugin -->
<plugin>
  <groupId>org.owasp</groupId>
  <artifactId>dependency-check-maven</artifactId>
  <version>12.2.2</version>
  <configuration>
    <failBuildOnCVSS>9</failBuildOnCVSS>
    <suppressionFiles>
      <suppressionFile>owasp-suppressions.xml</suppressionFile>
    </suppressionFiles>
    <formats>HTML,JSON,SARIF</formats>
  </configuration>
</plugin>

For Gradle projects, also enable dependency locking to prevent unexpected version resolution changes (which could be a vector for dependency confusion attacks):

Pour les projets Gradle, activez également le verrouillage des dépendances pour prévenir les changements de résolution de version inattendus (qui pourraient être un vecteur pour des attaques de confusion de dépendances) :

// build.gradle.kts — Gradle dependency locking
dependencyLocking {
    lockAllConfigurations()  // Creates gradle.lockfile
    lockMode.set(LockMode.STRICT)  // Fail if resolved != locked
}

// Generate/update lockfile:
// ./gradlew dependencies --write-locks

Spring Boot Version Support in 2026: Which Versions Still Receive Patches?

Support des Versions Spring Boot en 2026 : Quelles Versions Reçoivent Encore des Patches ?

Understanding which Spring Boot version you’re running — and whether it’s still supported — is the foundation of dependency security. CVE-2026-40976 affects Spring Boot 4.0.0–4.0.5, but other 2026 CVEs span versions 2.7.x through 4.0.x. Multiple branches are in end-of-life status:

Comprendre quelle version de Spring Boot vous exécutez — et si elle reçoit encore du support — est le fondement de la sécurité des dépendances. CVE-2026-40976 touche Spring Boot 4.0.0–4.0.5, mais d’autres CVE 2026 couvrent les versions 2.7.x à 4.0.x. Plusieurs branches sont en statut fin de vie :

• Spring Boot 2.7.x — EOL. No more patches. Affected by 2026 CVEs — no fix available from upstream.
• Spring Boot 2.7.x — Fin de vie. Plus de patches. Touchée par des CVE 2026 — aucun correctif disponible en amont.
• Spring Boot 3.2.x / 3.3.x — EOL. Many 2026 CVEs still apply. Upgrade required.
• Spring Boot 3.2.x / 3.3.x — Fin de vie. De nombreuses CVE 2026 s’appliquent encore. Mise à niveau requise.
• Spring Boot 3.4.x — Community support until late 2026. Currently receiving patches.
• Spring Boot 3.4.x — Support communautaire jusqu’à fin 2026. Reçoit actuellement des patches.
• Spring Boot 3.5.x — Current (as of May 2026). Active support.
• Spring Boot 3.5.x — Actuel (en mai 2026). Support actif.
• Spring Boot 4.0.x — Latest. 4.0.6 fixes CVE-2026-40976.
• Spring Boot 4.0.x — Dernière version. 4.0.6 corrige CVE-2026-40976.

Teams on EOL branches can use commercial support providers (HeroDevs offers Never-Ending Support for EOL Spring versions), but the cleanest solution is upgrading to a supported branch and setting up automated CVE scanning.

Les équipes sur des branches en fin de vie peuvent utiliser des prestataires de support commercial (HeroDevs propose un support sans fin pour les versions Spring EOL), mais la solution la plus propre est la mise à niveau vers une branche supportée et la mise en place d’une analyse CVE automatisée.

Spring Boot Dependency Security Checklist for 2026

Checklist de Sécurité des Dépendances Spring Boot pour 2026

Here is a practical checklist covering the most impactful controls for Spring Boot security in 2026:

Voici une checklist pratique couvrant les contrôles les plus importants pour la sécurité Spring Boot en 2026 :

Frequently Asked Questions

Questions Fréquentes