One of Spring Security’s jobs is adding the response headers that harden a web app: Cache-Control, X-Frame-Options, Strict-Transport-Security, Content-Security-Policy. CVE-2026-22732 is about those headers never reaching the browser under certain conditions. It happens without throwing any error, so the application looks protected when it isn’t.
The Spring team (VMware/Broadcom) rated it CVSS 9.1, critical. The vector is network, low complexity, no privileges and no user interaction.
What goes wrong
Spring Security writes its security headers lazily by default. It injects them late in the response cycle through its HeaderWriterFilter. The trouble starts when the controller commits the response too early: if you write directly to response.getOutputStream(), call response.flushBuffer(), or set the length with setIntHeader("Content-Length", ...), the response is considered committed before Spring Security gets a chance to add its headers. The browser then receives the page without the expected protections.
This isn’t an edge case. Any endpoint that returns content by writing to the output stream (file downloads, PDF generation, data streaming) can hit it.
Who’s affected
Servlet applications using Spring Security with lazy header writing, which is the default. The affected branches are:
- 5.7.0 to 5.7.21
- 5.8.0 to 5.8.23
- 6.3.0 to 6.3.14
- 6.4.0 to 6.4.14
- 6.5.0 to 6.5.8
- 7.0.0 to 7.0.3
Reactive (WebFlux) applications fall outside this case; the problem is specific to the servlet model.
Why it matters
A missing Content-Security-Policy or X-Frame-Options won’t crash the server, but it leaves the door open to clickjacking, to sensitive data ending up in a shared cache because Cache-Control is gone, or to weaker transport protection if Strict-Transport-Security isn’t sent. The worst part is how quiet it is: your security configuration is still there, it looks correct in the code, yet it has no effect on the response. An audit that only reads source code won’t catch the gap; you have to inspect the actual headers the client receives.
Mitigation
Upgrade to a fixed version: 5.7.22 or later, 5.8.24 or later, 6.3.15 or later, 6.4.15 or later, 6.5.9 or later, or 7.0.4 or later.
If you can’t upgrade right away, there’s a workaround: force eager header writing by setting the HeaderWriterFilter.shouldWriteHeadersEagerly property to true. That adds the headers before the controller can commit the response.
Either way, check the headers of real responses (with curl -I or the browser dev tools) on endpoints that write directly to the stream, since those are the ones most likely to have been exposed.