Developer Docs: Check for Exposure to CVE-2026-22732

‍

Series: Developer Danger | CVE: CVE-2026-22732 | Severity: 9.1 Critical | Ecosystem: Spring Security (all versions)

CVE-2026-22732 is a Critical-severity vulnerability in Spring Security where HTTP security headers can silently not be written to servlet responses under affected conditions. The application continues serving the response, but security headers such as Cache-Control, X-Frame-Options, X-Content-Type-Options, etc. may be absent.

This can weaken browser-side protections against unintended caching, clickjacking, and content-type sniffing. In deployments that use shared caching layers such as CDNs or reverse proxies, it may also increase the risk of sensitive content being cached or served more broadly than intended, depending on configuration.

‍

Search your codebase right now

Open your project and search for any of these calls on the HttpServletResponse:

response.setIntHeader("Content-Length", ...)
response.setHeader("Content-Length", ...)
response.addIntHeader("Content-Length", ...)

For Spring Framework 6.x and earlier, these calls are the key application-level risk pattern to search. If you find any of these calls in your code, your filters, or your servlet wrappers, you should treat this as a confirmed risk and upgrade immediately.

For Spring Framework 7.x, a code search is not enough. In affected applications using 7.x versions, 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.

But here is the harder truth: you may not find them in your own code at all. Spring Framework itself sets Content-Length internally via these methods. Your application code did not change. A transitive framework dependency update changed which internal method gets called, and that silently disabled your entire security header configuration.

That means the absence of these strings in your codebase is not a clean bill of health. If you are on an affected Spring Security version and you serve servlet-based responses, you may be exposed regardless.

Am I on an affected version?

Based on the versions below, am I at risk?

‍

Spring Security 7.0.0 - 7.0.3 --> Yes. Upgrade to 7.0.4.

Spring Security 6.5.0 - 6.5.8 --> Yes. Upgrade to 6.5.9.

Spring Security 6.4.x and earlier --> Yes. No OSS patch exists.

Spring Security 5.x --> Yes. No OSS patch exists.

Spring Security 4.x --> Yes. No OSS patch exists.

‍

If you are on 6.5.x or 7.0.x, patch today. Both fixes are available on Maven Central now.

If you are on anything older, the upstream project will not issue a patch for your version. Those branches are EOL. Contact HeroDevs today to have a secure drop in replacement.

How to verify you are actually affected

Do not rely on logs. Do not rely on smoke tests that check HTTP status codes. Ensure your integration tests explicitly assert common security headers you expect to be present.

Java
mockMvc.perform(get("/any-endpoint"))
	.andExpect(header().exists("Cache-Control"))    
    .andExpect(header().exists("X-Frame-Options"))    
    .andExpect(header().exists("X-Content-Type-Options"))    
    .andExpect(header().exists("X-XSS-Protection"))    
    .andExpect(header().exists("...others"));

If those assertions fail against your current version, you have confirmed the vulnerability in your environment. If they pass after upgrading, your fix is verified.

On EOL versions

For teams running Spring Security 4.x, 5.x, 6.2.x, 6.3.x, or 6.4.x, there is no upstream patch. The Spring project does not backport security fixes to EOL branches.

NES for Spring from HeroDevs patches this CVE across all affected EOL versions as a drop-in replacement. No migration required.

‍

Full technical writeup: CVE-2026-22732: Spring Security Silently Drops HTTP Security Headers