Intervalli interessati: 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 fissa Spring Security 5.7.11, pienamente all'interno del primo intervallo:

Esecuzione

run.sh fissa JAVA_HOME perché Spring Boot 2.7.x non può girare sul JDK 25 che mvn risolve per default su questa macchina. Sovrascrivi con JAVA_HOME_17=/path/to/jdk17.

Compila anche con -s settings-chainguard.xml per default, perché il parent corretto non è su Maven Central. Imposta MAVEN_SETTINGS=/path/to/your/settings.xml per puntare altrove, oppure MAVEN_SETTINGS= per compilare esclusivamente da Central — cosa che funziona solo con il 2.7.18 originale.

exploit.sh legge le versioni effettive di spring-security-web e spring-boot da target/*.jar, quindi il suo banner riporta sempre ciò che è realmente in esecuzione anziché una stringa hardcoded.

Il setup

SecurityConfig non applica nessuna personalizzazione degli header — sono in vigore i default di Spring Security, che è esattamente ciò su cui si basa un'app attenta alla sicurezza. Ogni endpoint restituisce lo stesso body sensibile:

L'unica cosa che varia è come il controller scrive la risposta.

Risultati misurati

Solo /vuln/content-length/account cambia stato quando la CVE viene corretta, quindi è l'unico endpoint da cui exploit.sh deriva il suo verdetto. Gli altri sono controlli.

La CVE — setIntHeader("Content-Length", n) → bypass totale

Tre righe di codice del controller dall'aspetto ordinario eliminano ogni header che Spring Security aveva promesso:

Nessun X-Frame-Options, nessun X-Content-Type-Options, nessun Cache-Control, nessun Pragma, nessun Expires, nessun X-XSS-Protection. Confronta con /safe/account, che li porta tutti e sei. La risposta è incorniciabile da qualsiasi origine, MIME-sniffable e cacheable — mentre serve un numero di carta.

Il caso by-design — header di cache impostato dall'applicazione → soppressione della cache

Corretto: una versione precedente di questo README lo chiamava "exploit 2" e sosteneva fosse la condizione documentata nell'advisory. Non fa parte di CVE-2026-22732 e nessun aggiornamento lo corregge. CacheControlHeadersWriter è identico byte per byte in 5.7.11, 5.7.14-0.cgr.2, 6.5.8 (ultima vulnerabile) e 6.5.9 (prima corretta) — verificato confrontando i sources jar. Il suo Javadoc afferma esplicitamente il comportamento: "Inserts headers to prevent caching if no cache control headers have been specified."

Vale comunque la pena dimostrarlo, perché la fuga è reale e il rischio residuo sopravvive alla patch. CacheControlHeadersWriter si ferma se Cache-Control, Expires o Pragma è già presente, quindi impostare uno qualsiasi dei tre sopprime tutte le direttive no-store di Spring Security. Una sola riga ben intenzionata lo fa:

Expires conta come "presente" nella tabella sopra, ma con un valore favorevole all'attaccante scelto dall'app — l'Expires: 0 di Spring Security è stato sostituito, non semplicemente eliminato. I dati del titolare della carta sono ora memorizzabili da ogni browser e proxy condiviso sul percorso fino al 2099.

Sulla build corretta /vuln/content-length/account passa a NOT cacheable, mentre /vuln/cache/account resta esattamente come sopra. Solo il codice dell'applicazione o un reverse proxy lo corregge — che è la cosa utile da dire ad alta voce in una demo: aggiornare la libreria chiude la CVE e lascia questo intatto.

Due risultati negativi, mantenuti di proposito

Diversi write-up ampiamente diffusi — incluso un repo pubblico di riproduzione — elencano response.getOutputStream() e response.flushBuffer() come trigger, spiegando che "la risposta è committed prima che Spring Security possa iniettare i suoi header". Su Spring Security 5.7.11 questo è sbagliato. Entrambi gli endpoint consegnano tutti e sei gli header.

/diag/committed mostra perché la spiegazione non regge. Dopo una scrittura di 12 KB la risposta è davvero committed all'interno del controller, eppure gli header arrivano comunque:

OnCommittedResponseWrapper sovrascrive flushBuffer() e le scritture dell'output-stream, quindi emette i suoi header prima di quei commit. Il solo ordinamento dei commit non è il bug; il percorso con Content-Length dichiarato lo è. L'advisory di Spring stesso non avalla mai la storia dell'ordinamento dei commit.

Mantenere questi due endpoint rende il PoC falsificabile: mostra ciò che non si riproduce con la stessa chiarezza di ciò che si riproduce, ed entrambi restano verdi attraverso la patch, che è ciò che rende significativo l'unico endpoint che effettivamente cambia.

La transizione vulnerabile → corretta

Una riga nel pom.xml, nient'altro. Nessuna modifica al sorgente, nessuna modifica alle proprietà, nessun bump di major di Spring Boot:

Questo ri-fissa spring-security.version da 5.7.11 a 5.7.14-0.cgr.2 (e spring-framework.version da 5.3.31 a 5.3.39-0.cgr.4) tramite le spring-boot-dependencies del parent. Misurato:

Il backport è la correzione upstream

Confrontando i sources jar di spring-security-web, conta un solo file. 5.7.11 → 5.7.14-0.cgr.2 aggiunge gli override setHeader / setIntHeader / addIntHeader a OnCommittedResponseWrapper, ciascuno instrada Content-Length attraverso setContentLength():

Prima della correzione solo addHeader faceva questo, quindi setIntHeader("Content-Length", n) lasciava la lunghezza tracciata dal wrapper a 0, onResponseCommitted() non scattava mai, e HeaderWriterFilter non scriveva mai i suoi header prima che Tomcat facesse il commit della risposta.

Lo stesso hunk appare identico confrontando l'upstream 6.5.8 (ultima vulnerabile) con 6.5.9 (prima corretta), quindi questa è la correzione ufficiale backportata, non una reimplementazione. La build Chainguard aggiunge due null-guard che l'upstream 6.5.9 non ha (value != null sull'overload String, e (csq != null) ? csq.length() : 4 in append).

Altre mitigazioni

Spring Security 5.7.x è end-of-life upstream; le correzioni OSS arrivano solo in 6.4.15 / 6.5.9 / 7.0.4+. Se una 5.7.x ricompilata non è un'opzione:

1. Aggiornare fuori da 5.7.x — una migrazione a Spring Boot 3.x.
2. Workaround — impostare HeaderWriterFilter.shouldWriteHeadersEagerly = true tramite un ObjectPostProcessor. Secondo l'advisory questo cambia il comportamento: gli header scritti dall'applicazione sovrascrivono poi solo header specifici anziché sopprimere quelli di Spring Security. Questo corregge anche /vuln/cache/account, cosa che il bump di versione non fa.
3. Supporto commerciale — backport Tanzu Spring Enterprise per 5.7.x/5.8.x.
4. Difesa in profondità — impostare gli header a livello di reverse proxy / ingress così che un header applicativo eliminato non sia l'unico controllo. Questa è l'unica opzione elencata che copre entrambi gli endpoint.

Nessuna di queste è cablata in questo progetto, quindi il comportamento vulnerabile è il default e lo stato corretto è raggiungibile con il singolo cambio di <version> sopra.

Correggere il Tomcat embedded senza aggiornare Spring Boot

Boot 2.7.18 fissa Tomcat 9.0.83, che grype . segnala con 34 CVE (4 Critical). Tutte sono corrette alla 9.0.118 o inferiore, e la 9.0.118 è la release 9.0.x più recente — quindi una sola proprietà le elimina tutte:

spring-boot-dependencies dichiara ogni artefatto tomcat-embed-* attraverso quella singola proprietà, quindi sovrascriverla ri-fissa core, el e websocket insieme. Verificato:

Vincolo: resta sulla linea 9.0.x. Tomcat 10+ ha spostato la Servlet API su jakarta.* mentre Spring Framework 5.3 compila contro javax.servlet, quindi un bump a 10.x/11.x fallisce a runtime con NoClassDefFoundError sui tipi servlet.

Correggere tutto il resto, restando all'interno di ciascuna linea major

Stesso meccanismo applicato al resto delle dipendenze gestite di Boot 2.7.18. Nessun bump di major-version, e nessun aggiornamento di Spring Boot:

Questi override interagiscono con il parent corretto, quindi sappi cosa fanno prima di fare la demo. Su 2.7.18-0.cgr.3 il parent fornisce già tomcat.version 9.0.118, logback.version 1.2.13 e snakeyaml.version 1.33 — quelle tre righe diventano duplicati esatti e possono essere eliminate senza cambiare nulla. Le righe jackson-bom.version e log4j2.version fanno ancora lavoro reale: il parent corretto mantiene le 2.13.5 / 2.17.2 stock di Boot, quindi gli override vincono e quelle due dipendenze si risolvono su build upstream normali anziché su quelle costruite da Chainguard. spring-framework.version è commentata di proposito, ed è ciò che lascia passare la 5.3.39-0.cgr.4 del parent.

Progressione di grype .

Completamente risolte: Tomcat (34), Jackson (7), log4j (1). Complessivamente 99 → 43, High 39 → 12.

Verificato dopo ogni bump: l'app si avvia su Tomcat/9.0.118, tutti e sei gli endpoint restituiscono 200, e la CVE si riproduce byte per byte. Spring Boot è ancora 2.7.18 e Spring Security ancora 5.7.11, quindi CVE-2026-22732 è intatta — che è il punto di questa sezione, e anche il suo onesto limite: correggere tutto ciò che la circonda non fa nulla per la CVE dell'application-framework. Correggere quella richiede il bump del parent, non una proprietà.

Perché Logback si ferma alla 1.2.13

L'ultima 1.x è la 1.6.3 — stessa major, quindi nominalmente in ambito. Non funziona. Logback 1.3+ ha sostituito lo StaticLoggerBinder di SLF4J 1.7 con il provider ServiceLoader di SLF4J 2.x, e il LogbackLoggingSystem di Boot 2.7 chiama StaticLoggerBinder direttamente. Misurato con la 1.5.38:

Uscire da questo richiede SLF4J 2.x (un bump di major) e un logging system di Boot 3.x. La 1.2.13 è il vero tetto, lasciando 6 risultati Logback (2 Medium, 4 Low) non correggibili su questa linea.

I 43 che rimangono

Due delle tre Critical rimanenti meritano una lettura attenta anziché basata sul punteggio:

• CVE-2016-1000027 (spring-web, fix 6.0.0) — deserializzazione tramite HttpInvokerServiceExporter. Questa app non usa HTTP Invoker, quindi non è raggiungibile qui.
• CVE-2024-38821 (spring-security-web, fix 5.7.13) — bypass di autenticazione su risorse statiche in WebFlux. Questa è un'app servlet, quindi anch'essa non raggiungibile. È correggibile in-major (5.7.13/5.7.14 sono su Central) ed è stata lasciata solo per mantenere questa sezione fissata alla 5.7.11. Il parent corretto la risolve come effetto collaterale, poiché 5.7.14-0.cgr.2 è oltre la versione di correzione.
• CVE-2026-22732 — intenzionale nello stato vulnerabile; risolta dal bump del parent.

Il residuo è strutturale: Spring Framework 5.3.x e Spring Security 5.7.x sono entrambe EOL. Questo, non Tomcat o Jackson, è il vero argomento per una migrazione a Boot 3.x.

Struttura

L'autenticazione è permitAll e CSRF è disattivato così curl funziona senza autenticazione — nessuno dei due fa parte di questa CVE.

Fonti

• spring.io/security/cve-2026-22732 — advisory ufficiale
• GHSA-mf92-479x-3373
• NVD CVE-2026-22732
• Broadcom / Tanzu write-up
• HeroDevs analysis
• semgrep/cve-2026-22732-demo — la riproduzione le cui affermazioni su stream/flush non hanno retto qui
• Red Hat Bugzilla #2449306