CVE-2026-22732: Spring Security Silently Drops HTTP Security Headers

Open source powers the modern software stack, but its security depends on a shared commitment to finding and fixing weaknesses before they become incidents.

At HeroDevs, that's our mission: secure open source. We do it in two ways:

1. Remediating known CVEs across critical ecosystems, and
2. Proactively researching vulnerabilities before attackers can exploit them.

A new Critical-severity vulnerability, CVE-2026-22732, has been disclosed in Spring Security affecting servlet applications. Under certain conditions, the HTTP security headers that Spring Security is configured to write may not be written to the response. For organizations running Spring Security 4.2.x, 5.5.x, 5.7.x, 5.8.x, 6.2.x, 6.3.x, or 6.4.x, those versions have reached end of life and the upstream Spring project provides no OSS patch. NES for Spring delivers backported fixes for all affected EOL versions.

What is CVE-2026-22732?

CVE-2026-22732 is a security header omission vulnerability in Spring Security's servlet support layer. When applications configure Spring Security to write HTTP security response headers, those headers may, under certain conditions, not be written to the response at all.

HTTP security headers are a critical defense layer. Headers like Cache-Control, X-Content-Type-Options, X-Frame-Options, Strict-Transport-Security, and Content-Security-Policy are not cosmetic. They are instructions to browsers and intermediate caches that constrain how responses are stored and rendered. When these headers are absent, every protection they provide is lost.

CVSS 3.1 Score: 9.1 Critical

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Note: The CVSS score and vector above are sourced from the Spring security advisory (CNA: VMware). NVD enrichment was pending at time of publication. Verify the NVD-assigned score at https://nvd.nist.gov/vuln/detail/CVE-2026-22732.

The vector breaks down as follows:

• AV:N: Network-accessible. No physical or local access required.
• AC:L: Low attack complexity. No special conditions or race conditions required to trigger the omission.
• PR:N: No privileges required. An unauthenticated attacker can exploit the resulting exposure.
• UI:N: No user interaction required.
• C:H and I:H: Both confidentiality and integrity impacts are rated High.

The combination of no required authentication, no required user interaction, and High confidentiality and integrity impact places this firmly in the Critical tier.

Who is affected?

CVE-2026-22732 affects every actively maintained Spring Security branch, and extends to older EOL versions confirmed vulnerable by the Spring advisory and HeroDevs research:

Spring Security 5.7.x and 5.8.x reached end of life on August 31, 2024. These versions align with Spring Framework 5.3.x and are typically deployed in Spring Boot 2.7 applications, one of the most widely deployed Spring Boot generations in enterprise production today. The upstream Spring project does not backport security patches to EOL versions.

Spring Security 6.3.x and 6.4.x are in a similar position. Fixes for those versions are available only from Broadcom Enterprise Support, which requires a separate commercial agreement. For organizations without that agreement, NES is the actionable path.

Spring Security 6.2.x, 5.5.x, and 4.2.x are EOL and receive no patches from either the upstream project or Broadcom Enterprise Support. HeroDevs NES covers these versions regardless of whether the upstream maintainers formally attribute the CVE to those releases.

Root cause and mechanism

Spring Security's header-writing infrastructure for servlet applications centers on OnCommittedResponseWrapper, which defers security header writes until the response is about to be committed.  To do that correctly, the wrapper tracks Content-Length so it knows when the response body has been fully written and the headers must be flushed.

The bug: the wrapper only tracked Content-Length when set via addHeader(), but not via setHeader(), setIntHeader(), or addIntHeader(). If Content-Length is set through one of those untracked methods, the wrapper does not correctly track the body length. The response is committed, and Spring Security’s headers are omitted.

For Spring Framework 6.x and earlier, calls such as setHeader("Content-Length", ...), setIntHeader(“Content-Length”, ...), or addIntHeader("Content-Length", ...) on the HttpServletResponse are the main application-level risk pattern to search for. If you find those calls in your code, filters, servlet wrappers, or dependencies, treat that as a confirmed risk path and upgrade.

For Spring Framework 7.x, a code search is not enough. The vulnerable path can be reached through framework-internal handling of Content-Length, even if your own code never calls these APIs directly. The best course of action is to upgrade to the latest patch immediately.

In practice, this appears as a silent omission of expected security headers rather than an obvious application failure. Responses are still returned, but tests that only verify status codes or response bodies may miss the issue. Detecting it requires checking for the presence of the expected security headers in the response.

The fix, available in Spring Security 6.5.9 and 7.0.4, adds consistent handling for the relevant Content-Length setter paths so body length tracking works regardless of which supported API path sets the  header.

Impact

When security headers are absent, browsers and intermediate caches treat the response as if no security policy was declared. The affected headers and their practical consequences:

Sensitive data exposure via caching. Without Cache-Control: no-store, authenticated responses may be stored by shared proxies, CDN edge nodes, or the browser's own cache. A subsequent request to the same URL, from a different user or an attacker, may be served the cached response without the request ever reaching the application. This includes back-button exposure on shared workstations and proxy-layer data leakage in multi-tenant environments.

Clickjacking. Without X-Frame-Options, the application can be embedded in a hostile iframe, allowing an attacker to trick users into performing actions they did not intend.

Content-type sniffing attacks. Without X-Content-Type-Options: nosniff, some browsers may reinterpret response content in unsafe ways, weakening protections against MIME-sniffing attacks.

Weakened transport security. Where Strict-Transport-Security is expected to be added by Spring Security, its omission removes an important browser-side HTTPS enforcement signal.

Mitigation guidance

The OSS fix versions (6.5.9 and 7.0.4) are available through standard Maven Central and Spring repositories. No commercial agreement is required for those versions.

Taking action

For teams on Spring Security 6.5.x or 7.0.x, the path is clear: upgrade to the patched version. For teams on Spring Security 5.7.x, 5.8.x, 6.3.x, or 6.4.x, the upstream project offers no OSS fix. Those versions are EOL.

If your organization depends on any of those EOL Spring Security versions, this is exactly the gap NES for Spring is designed to close. NES delivers backported security patches for EOL Spring Security versions as drop-in replacements, with no migration required. Your team gets the fix for CVE-2026-22732 and every subsequent CVE, on the version you are already running, while you plan your migration on your own timeline.

‍

‍

CVE-2026-22732 was identified and responsibly reported by Wyfrel.

‍