# CVE-2026-22732: Spring Security silently drops HTTP security headers

- **Published on:** 2026-03-19
- **Category:** Security
- **Original page:** https://linuxgratis.com/en/articles/cve-2026-22732-spring-security-cabeceras-http-omitidas

A critical flaw (CVSS 9.1) makes servlet apps using Spring Security lose headers like Content-Security-Policy and Strict-Transport-Security without warning. Affected versions and fix.

---

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.

## Source

- [NVD - CVE-2026-22732](https://nvd.nist.gov/vuln/detail/CVE-2026-22732)
- [Official Spring advisory](https://spring.io/security/cve-2026-22732/)