Plages affectées : 5.7.0–5.7.21, 5.8.0–5.8.23, 6.3.0–6.3.14, 6.4.0–6.4.14, 6.5.0–6.5.8, 7.0.0–7.0.3. Spring Boot 2.7.18 épingle Spring Security 5.7.11, en plein dans la première plage :

L'exécuter

run.sh épingle JAVA_HOME car Spring Boot 2.7.x ne peut pas s'exécuter sur le JDK 25 que mvn résout par défaut sur cette machine. Remplacez avec JAVA_HOME_17=/path/to/jdk17.

Il compile aussi avec -s settings-chainguard.xml par défaut, car le parent corrigé n'est pas sur Maven Central. Définissez MAVEN_SETTINGS=/path/to/your/settings.xml pour pointer ailleurs, ou MAVEN_SETTINGS= pour compiler uniquement depuis Central — ce qui ne fonctionne que pour le 2.7.18 d'origine.

exploit.sh lit les versions réelles de spring-security-web et spring-boot depuis target/*.jar, donc sa bannière rapporte toujours ce qui s'exécute réellement plutôt qu'une chaîne codée en dur.

La configuration

SecurityConfig n'applique aucune personnalisation d'en-tête — les valeurs par défaut de Spring Security sont en vigueur, ce qui est exactement ce sur quoi une application soucieuse de la sécurité s'appuie. Chaque endpoint renvoie le même corps sensible :

La seule chose qui varie est la façon dont le contrôleur écrit la réponse.

Résultats mesurés

Seul /vuln/content-length/account change d'état lorsque la CVE est corrigée, c'est donc le seul endpoint dont exploit.sh tire son verdict. Les autres sont des contrôles.

La CVE — setIntHeader("Content-Length", n) → contournement total

Trois lignes de code de contrôleur d'apparence ordinaire suppriment tous les en-têtes que Spring Security promettait :

Pas de X-Frame-Options, pas de X-Content-Type-Options, pas de Cache-Control, pas de Pragma, pas d'Expires, pas de X-XSS-Protection. Comparez avec /safe/account, qui porte les six. La réponse est encadrable par n'importe quelle origine, sensible au reniflage MIME et cachable — tout en servant un numéro de carte.

Le cas par conception — en-tête de cache défini par l'application → suppression du cache

Corrigé : une version antérieure de ce README appelait cela « exploit 2 » et affirmait qu'il s'agissait de la condition documentée par l'avis. Cela ne fait pas partie de CVE-2026-22732 et aucune mise à niveau ne le corrige. CacheControlHeadersWriter est identique octet pour octet en 5.7.11, 5.7.14-0.cgr.2, 6.5.8 (dernière vulnérable) et 6.5.9 (première corrigée) — vérifié en comparant les jars de sources. Sa Javadoc énonce le comportement sans détour : « Insère des en-têtes pour empêcher la mise en cache si aucun en-tête de contrôle du cache n'a été spécifié. »

Cela vaut quand même la peine d'être démontré, car la fuite est réelle et le risque résiduel survit au correctif. CacheControlHeadersWriter abandonne si Cache-Control, Expires ou Pragma est déjà présent, donc définir l'un des trois supprime toutes les directives no-store de Spring Security. Une seule ligne bien intentionnée suffit :

Expires compte comme « présent » dans le tableau ci-dessus, mais avec une valeur favorable à l'attaquant choisie par l'application — l'Expires: 0 de Spring Security a été remplacé, pas simplement supprimé. Les données du porteur de carte sont désormais stockables par chaque navigateur et proxy partagé sur le chemin jusqu'en 2099.

Sur la version corrigée, /vuln/content-length/account bascule vers NOT cacheable, tandis que /vuln/cache/account reste exactement comme ci-dessus. Seul le code applicatif ou un reverse proxy le corrige — ce qui est la chose utile à dire à voix haute dans une démo : mettre à niveau la bibliothèque ferme la CVE et laisse ceci intact.

Deux résultats négatifs, conservés à dessein

Plusieurs articles largement diffusés — y compris un dépôt de reproduction public — listent response.getOutputStream() et response.flushBuffer() comme déclencheurs, expliquant que « la réponse est validée avant que Spring Security puisse injecter ses en-têtes ». Sur Spring Security 5.7.11, c'est faux. Les deux endpoints délivrent les six en-têtes.

/diag/committed montre pourquoi l'explication ne tient pas. Après une écriture de 12 Ko, la réponse est réellement validée à l'intérieur du contrôleur, et pourtant les en-têtes arrivent toujours :

OnCommittedResponseWrapper redéfinit flushBuffer() et les écritures du flux de sortie, donc il obtient ses en-têtes avant ces validations. L'ordre de validation seul n'est pas le bug ; le chemin avec Content-Length déclaré l'est. L'avis Spring lui-même ne cautionne jamais l'histoire de l'ordre de validation.

Conserver ces deux endpoints rend la PoC falsifiable : elle montre ce qui ne se reproduit pas aussi clairement que ce qui se reproduit, et les deux restent verts à travers le correctif, ce qui rend le seul endpoint qui bascule significatif.

La transition vulnérable → corrigée

Une ligne dans pom.xml, rien d'autre. Aucun changement de source, aucun changement de propriété, aucune montée de version majeure de Spring Boot :

Cela ré-épingle spring-security.version de 5.7.11 à 5.7.14-0.cgr.2 (et spring-framework.version de 5.3.31 à 5.3.39-0.cgr.4) via le spring-boot-dependencies du parent. Mesuré :

Le backport est le correctif amont

En comparant les jars de sources de spring-security-web, un seul fichier compte. 5.7.11 → 5.7.14-0.cgr.2 ajoute les redéfinitions setHeader / setIntHeader / addIntHeader à OnCommittedResponseWrapper, chacune routant Content-Length via setContentLength() :

Avant le correctif, seul addHeader faisait cela, donc setIntHeader("Content-Length", n) laissait la longueur suivie par le wrapper à 0, onResponseCommitted() ne se déclenchait jamais, et HeaderWriterFilter n'écrivait jamais ses en-têtes avant que Tomcat ne valide la réponse.

Le même bloc apparaît mot pour mot en comparant l'amont 6.5.8 (dernière vulnérable) avec 6.5.9 (première corrigée), donc il s'agit du correctif officiel rétroporté, pas d'une réimplémentation. La version Chainguard ajoute deux gardes de nullité que l'amont 6.5.9 n'a pas (value != null sur la surcharge String, et (csq != null) ? csq.length() : 4 dans append).

Autres atténuations

Spring Security 5.7.x est en fin de vie en amont ; les correctifs OSS n'arrivent que dans 6.4.15 / 6.5.9 / 7.0.4+. Si une version 5.7.x reconstruite n'est pas une option :

1. Quitter la 5.7.x — une migration vers Spring Boot 3.x.
2. Contournement — définir HeaderWriterFilter.shouldWriteHeadersEagerly = true via un ObjectPostProcessor. Selon l'avis, cela change le comportement : les en-têtes écrits par l'application ne remplacent alors que des en-têtes spécifiques plutôt que de supprimer ceux de Spring Security. Celui-ci corrige aussi /vuln/cache/account, ce que la montée de version ne fait pas.
3. Support commercial — rétroportages Tanzu Spring Enterprise pour 5.7.x/5.8.x.
4. Défense en profondeur — définir les en-têtes au niveau du reverse proxy / ingress afin qu'un en-tête applicatif supprimé ne soit pas le seul contrôle. C'est la seule option listée qui couvre les deux endpoints.

Aucune de ces options n'est câblée dans ce projet, donc le comportement vulnérable est la valeur par défaut et l'état corrigé est atteignable par le seul changement de <version> ci-dessus.

Corriger le Tomcat embarqué sans mettre à niveau Spring Boot

Boot 2.7.18 épingle Tomcat 9.0.83, que grype . signale avec 34 CVE (4 Critiques). Toutes sont corrigées en 9.0.118 ou en dessous, et 9.0.118 est la dernière version 9.0.x — donc une seule propriété règle l'ensemble :

spring-boot-dependencies déclare chaque artefact tomcat-embed-* via cette seule propriété, donc la remplacer ré-épingle core, el et websocket ensemble. Vérifié :

Contrainte : restez sur la ligne 9.0.x. Tomcat 10+ a déplacé l'API Servlet vers jakarta.* tandis que Spring Framework 5.3 compile contre javax.servlet, donc une montée en 10.x/11.x échoue à l'exécution avec NoClassDefFoundError sur les types servlet.

Corriger tout le reste, toujours dans chaque ligne majeure

Même mécanisme appliqué au reste des dépendances gérées de Boot 2.7.18. Aucune montée de version majeure, et aucune mise à niveau de Spring Boot :

Ces remplacements interagissent avec le parent corrigé, donc sachez ce qu'ils font avant de faire la démo. Sur 2.7.18-0.cgr.3, le parent fournit déjà tomcat.version 9.0.118, logback.version 1.2.13 et snakeyaml.version 1.33 — ces trois lignes deviennent des doublons exacts et peuvent être supprimées sans rien changer. Les lignes jackson-bom.version et log4j2.version font encore un vrai travail : le parent corrigé conserve les 2.13.5 / 2.17.2 d'origine de Boot, donc les remplacements l'emportent et ces deux dépendances se résolvent en versions amont pures plutôt qu'en versions construites par Chainguard. spring-framework.version est commentée à dessein, ce qui laisse passer le 5.3.39-0.cgr.4 du parent.

Progression de grype .

Entièrement nettoyés : Tomcat (34), Jackson (7), log4j (1). Globalement 99 → 43, Highs 39 → 12.

Vérifié après chaque montée : l'application démarre sur Tomcat/9.0.118, les six endpoints renvoient 200, et la CVE se reproduit octet pour octet. Spring Boot est toujours 2.7.18 et Spring Security toujours 5.7.11, donc CVE-2026-22732 est intacte — ce qui est le but de cette section, et aussi sa limite honnête : corriger tout ce qui l'entoure ne fait rien pour la CVE du framework applicatif. Corriger celle-là nécessite la montée du parent, pas une propriété.

Pourquoi Logback s'arrête à 1.2.13

La dernière 1.x est 1.6.3 — même majeure, donc nominalement dans le périmètre. Cela ne fonctionne pas. Logback 1.3+ a remplacé le StaticLoggerBinder de SLF4J 1.7 par le fournisseur ServiceLoader de SLF4J 2.x, et le LogbackLoggingSystem de Boot 2.7 appelle StaticLoggerBinder directement. Mesuré avec 1.5.38 :

S'échapper de cela nécessite SLF4J 2.x (une montée majeure) et un système de journalisation Boot 3.x. 1.2.13 est le vrai plafond, laissant 6 constats Logback (2 Moyens, 4 Faibles) non corrigeables sur cette ligne.

Les 43 qui restent

Deux des trois Critiques restants méritent d'être lus correctement plutôt que par score :

• CVE-2016-1000027 (spring-web, correctif 6.0.0) — désérialisation via HttpInvokerServiceExporter. Cette application n'utilise pas HTTP Invoker, donc ce n'est pas atteignable ici.
• CVE-2024-38821 (spring-security-web, correctif 5.7.13) — contournement d'authentification des ressources statiques dans WebFlux. C'est une application servlet, donc également non atteignable. Elle est corrigeable dans la majeure (5.7.13/5.7.14 sont sur Central) et a été laissée uniquement pour garder cette section épinglée à 5.7.11. Le parent corrigé la nettoie comme effet secondaire, puisque 5.7.14-0.cgr.2 dépasse la version du correctif.
• CVE-2026-22732 — intentionnelle dans l'état vulnérable ; nettoyée par la montée du parent.

Le résidu est structurel : Spring Framework 5.3.x et Spring Security 5.7.x sont tous deux en fin de vie. C'est cela, pas Tomcat ou Jackson, le véritable argument pour une migration vers Boot 3.x.

Arborescence

L'authentification est permitAll et CSRF est désactivé pour que curl fonctionne sans authentification — ni l'un ni l'autre ne fait partie de cette CVE.

Sources

• spring.io/security/cve-2026-22732 — avis officiel
• GHSA-mf92-479x-3373
• NVD CVE-2026-22732
• Article Broadcom / Tanzu
• Analyse HeroDevs
• semgrep/cve-2026-22732-demo — la reproduction dont les affirmations stream/flush ne tenaient pas ici
• Red Hat Bugzilla #2449306