Retour au blog
JavaSpringCVE

Java et Spring4Shell : ce que CVE-2022-22965 a vraiment appris aux equipes Spring

Publié le 2026-04-116 min de lectureFlorian

Spring4Shell n etait pas un deuxieme Log4Shell

CVE-2022-22965 a ete rapidement surnomme Spring4Shell. Le rapprochement mediatiquement utile avec Log4Shell a fonctionne, mais il a aussi brouille la comprehension technique. La page officielle Spring est claire : la faille concernait des applications Spring MVC ou Spring WebFlux sur JDK 9+, deployeees en WAR sur Tomcat. Une application Spring Boot embarquee en jar n etait pas exposee a l exploit public de reference.

Pourquoi la faille reste importante

Elle reste une des failles les plus marquantes de l ecosysteme Spring parce qu elle a rappelle une verite peu confortable : un framework tres mature peut devenir critique quand plusieurs preconditions apparemment banales se combinent.

Spring a documente officiellement les versions affectees et recommande le passage a 5.3.18+ ou 5.2.20+.

Ce que cette faille a revele

Le sujet central n etait pas seulement une erreur de code. C etait aussi la distance entre ce que les equipes pensent deployer et ce qu elles deployent reellement. Beaucoup d entreprises disaient nous sommes sur Spring Boot donc nous sommes tranquilles, sans verifier si certaines applications historiques restaient packagees en WAR derriere Tomcat.

Spring4Shell a donc expose un risque classique des grandes bases Java : l heterogeneite. Meme au sein d une meme organisation, le mot Spring peut recouvrir des modes de deploiement tres differents.

Ce qu une equipe Spring doit verifier en 2026

  • la version exacte du framework ;
  • le mode de packaging reel ;
  • le conteneur servlet utilise ;
  • les applications historiques qui ne suivent plus le chemin standard Spring Boot ;
  • la capacite a patcher vite sans attendre un grand chantier de migration.
  • Notre lecture

    Si Log4Shell est la faille symbole des dependances Java, Spring4Shell est la faille symbole des hypotheses d architecture trop rapides. Elle rappelle qu une stack moderne n est pas seulement un nom de framework. C est une combinaison de versions, de packaging, de runtime et de pratiques de deploiement.

    Dire nous utilisons Spring ne dit pas grand-chose sur le risque. Dire nous utilisons telle branche, en jar ou en WAR, sur tel runtime, avec tel cycle de patch, dit beaucoup plus.

    Articles liés

    Trois analyses proches pour continuer la lecture sur la meme surface de risque.

    Besoin d'une revue externe de votre SaaS RH ?

    Expliquez votre produit, votre stack et votre contexte client. Nous revenons vers vous avec le bon niveau de revue.

    Parler de votre audit