Spring Security s’encarrega, entre altres coses, d’afegir les capçaleres de resposta que blinden una aplicació web: Cache-Control, X-Frame-Options, Strict-Transport-Security, Content-Security-Policy. El problema de CVE-2026-22732 és que, sota certes condicions, aquestes capçaleres mai no arriben al navegador. I ho fa sense llançar cap error, així que l’aplicació sembla protegida quan no ho està.
L’equip de Spring (VMware/Broadcom) li ha assignat un CVSS de 9.1, gravetat crítica. El vector és de xarxa, complexitat baixa, sense privilegis ni interacció de l’usuari.
Què passa per dins
Spring Security escriu les seves capçaleres de seguretat de manera mandrosa (lazy) per defecte. Les injecta tard en el cicle de la resposta, a través del seu HeaderWriterFilter. El problema apareix quan el controlador compromet la resposta abans d’hora: si escrius directament a response.getOutputStream(), crides response.flushBuffer() o fixes la llargada amb setIntHeader("Content-Length", ...), la resposta es dona per enviada (committed) abans que Spring Security tingui ocasió d’afegir les capçaleres. El navegador rep la pàgina sense les proteccions esperades.
No és un cas estrany. Qualsevol endpoint que retorni contingut escrivint al stream de sortida (descàrregues de fitxers, generació de PDF, streaming de dades) pot caure-hi.
A qui afecta
Aplicacions servlet que facin servir Spring Security amb escriptura mandrosa de capçaleres (el comportament per defecte). Les branques afectades són:
- 5.7.0 a 5.7.21
- 5.8.0 a 5.8.23
- 6.3.0 a 6.3.14
- 6.4.0 a 6.4.14
- 6.5.0 a 6.5.8
- 7.0.0 a 7.0.3
Les aplicacions reactives (WebFlux) no entren en aquest supòsit; el problema és específic del model servlet.
Per què importa
Que falti Content-Security-Policy o X-Frame-Options no tomba el servidor, però deixa la porta oberta al clickjacking, que dades sensibles acabin en una memòria cau compartida per culpa d’un Cache-Control absent, o que es degradin les proteccions de transport si no s’envia Strict-Transport-Security. El pitjor és el caràcter silenciós: la teva configuració de seguretat continua allà, sembla correcta al codi, però no fa efecte a la resposta. Una auditoria que només miri el codi font no detecta el forat; cal inspeccionar les capçaleres reals que rep el client.
Mitigació
Actualitza a una versió corregida: 5.7.22 o superior, 5.8.24 o superior, 6.3.15 o superior, 6.4.15 o superior, 6.5.9 o superior, o 7.0.4 o superior.
Si no pots actualitzar de seguida, hi ha un workaround: forçar l’escriptura primerenca de les capçaleres posant la propietat HeaderWriterFilter.shouldWriteHeadersEagerly a true. Així les capçaleres s’afegeixen abans que el controlador pugui comprometre la resposta.
Sigui quin sigui el camí, convé verificar les capçaleres de les respostes reals (amb curl -I o les eines de desenvolupament del navegador) als endpoints que escriuen directament al stream, que són els que tenen més números d’haver estat exposats.