惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

H
Help Net Security
大猫的无限游戏
大猫的无限游戏
雷峰网
雷峰网
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
博客园 - 聂微东
V
Visual Studio Blog
爱范儿
爱范儿
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
美团技术团队
有赞技术团队
有赞技术团队
云风的 BLOG
云风的 BLOG
Google DeepMind News
Google DeepMind News
Blog — PlanetScale
Blog — PlanetScale
The Cloudflare Blog
Engineering at Meta
Engineering at Meta
博客园 - 三生石上(FineUI控件)
WordPress大学
WordPress大学
Vercel News
Vercel News
F
Fortinet All Blogs
Last Week in AI
Last Week in AI
M
MIT News - Artificial intelligence
小众软件
小众软件
月光博客
月光博客
A
About on SuperTechFans

Spring Security Advisories

CVE-2026-47835: Spring AI vector store metadata filtering to handle special characters in Elasticsearch, OpenSearch, and GemFire Vector Stores CVE-2026-41862: Kryo deserialization of persisted context without class allowlist CVE-2026-41708: Spring Cloud Sleuth instrumentation of Spring TX DoS vulnerability CVE-2026-47825: Spring Cloud Gateway Server Forwards Headers from Untrusted Proxies in certain situations CVE-2026-40985: Data Binding Vulnerability in Spring Web Flow with Unified EL Parser CVE-2026-40986: Spring Web Flow JS RemotingHandler renders non-HTML Response as HTML CVE-2026-40987: Remote-file synchronizer in Spring Integration writes server-supplied filename under localDirectory without canonicalization CVE-2026-40994: Wss4jSecurityInterceptor disables WS-I BSP validation by default CVE-2026-40995: X.509 authentication bypasses Spring Security account checks CVE-2026-40997: SOAP security faults leak Spring Security account state CVE-2026-40998: Jaxp13 XPath XXE via StreamSource and SAXSource CVE-2026-40999: Spring WS SSRF via unvalidated WS-Addressing reply destinations CVE-2026-41000: WSS4J validation does not use configured replay cache CVE-2026-40996: Inbound WS-Security allows RSA PKCS#1 v1.5 key transport by default CVE-2026-40992: Mail Auto-Configuration Does Not Enable SSL Hostname Verification CVE-2026-41001: Predictable Temp Directory in Artemis Auto-configuration CVE-2026-41699: Unsafe Deserialization in Spring GraphQL CVE-2026-41700: Cross-Site WebSocket Hijacking in Spring for GraphQL CVE-2026-41856: Spring GraphQL Annotation Detection Vulnerability CVE-2026-41695: Denial of Service in Spring Data Commons Property Path Resolution CVE-2026-41696: Spring Data MongoDB Bind Parameter Literal Quoting Breakout CVE-2026-41697: Spring Data Relational Parameter not Escaped for Query By Example LIKE Pattern CVE-2026-41711: Potential Denial of Service through crafted Sort Parameters CVE-2026-41716: Spring Data web support unbounded negative-result cache keyed on attacker-supplied property names CVE-2026-41717: Spring Data MongoDB - SpEL Expression Injection via Annotated Query Parameter Binding CVE-2026-41719: Spring Data KeyValue - SpEL Injection vulnerability in SpelPropertyComparator CVE-2026-40991: XML External Entity (XXE) injection when documenting untrusted XML content CVE-2026-41721: Spring Data Commons Denial of Service via Data Binding CVE-2026-41728: Spring Data REST JSON Patch bypasses Jackson read-only property protection on nested objects and collections CVE-2026-40993: Unfiltered Java Native Deserialization of SAML 2.0 Asserting Party Credentials BLOB Database Entry
cve-2026-22732: Under Some Conditions Spring Security HTT...
2026-03-19 · via Spring Security Advisories

Description

When applications specify HTTP response headers for servlet applications using Spring Security, there is the possibility that the HTTP Headers will not be written. This can open up applications to various attacks including exposing sensitive data via caching mechanisms.

Affected Spring Products and Versions

Spring Security Servlet applications using lazy (default) writing of HTTP Headers:

  • 5.7.0 - 5.7.21
  • 5.8.0 - 5.8.23
  • 6.3.0 - 6.3.14
  • 6.4.0 - 6.4.14
  • 6.5.0 - 6.5.8
  • 7.0.0 - 7.0.3
  • Older, unsupported versions may also be affected

Mitigation

Users of affected versions should upgrade to the corresponding fixed version.

Affected version(s) Fix version Availability
5.7.21 5.7.22 Enterprise Support Only
5.8.23 5.8.24 Enterprise Support Only
6.3.14 6.3.15 Enterprise Support Only
6.4.14 6.4.15 Enterprise Support Only
6.5.8 6.5.9 OSS
7.0.3 7.0.4 OSS

Workarounds

Applications can work around the issue by setting the HeaderWriterFilter.shouldWriteHeadersEagerly property to true. However, it should be noted that this will change the application behavior. For example, with shouldWriteHeadersEagerly=false (default), then if any cache related headers are set by the application, then Spring Security will not write any cache related headers. However, with shouldWriteHeadersEagerly=true, application specific headers that are written will only override that specific header with no way to remove any HTTP Headers that were explicitly written.

Java Based Configuration Workaround

If you are comfortable changing the application behavior as described above, then you can set the shouldWriteHeadersEagerly using an ObjectPostProcessor:

@Bean
SecurityFilterChain springSecurity(HttpSecurity http) throws Exception {
    // @formatter:off
    http
        // ...
        .headers()
            // ...
            .addObjectPostProcessor(new ObjectPostProcessor<HeaderWriterFilter>() {
                @Override
                public HeaderWriterFilter postProcess(HeaderWriterFilter filter) {
                    filter.setShouldWriteHeadersEagerly(true);
                    return filter;
                }
            });
    return http.build();
    // @formatter:on
}

XML Based Configuration Workaround

If you are comfortable changing the application behavior as described above, then you can set the shouldWriteHeadersEagerly using a custom BeanPostProcessor:

To start define a custom BeanPostProcessor that sets shouldWriteHeadersEagerly:

public class EagerHeadersBeanPostProcessor implements BeanPostProcessor {

	@Override
	public Object postProcessAfterInitialization(Object bean, String beanName) throws BeansException {
		if (bean instanceof HeaderWriterFilter headerWriterFilter) {
			headerWriterFilter.setShouldWriteHeadersEagerly(true);
		}
		return bean;
	}

}

Then ensure to add the BeanPostProcessor as a Bean:

<!-- Ensure that this matches the full class name of the BeanPostProcessor that you created -->
<bean class="org.example.EagerHeadersBeanPostProcessor"/>

Credit

The issue was identified and responsibly reported by Wyfrel.

References