CVE-2026-22732: Spring Security: HTTP Headers Not Written in Servlet Applications
CVE-2026-22732 affects Spring Security servlet applications that use the default lazy writing of HTTP headers, where headers specified by the application may not be written. The CNA assigned a CVSS score of 9.1 and listed affected ranges across several branches. No confirmed exploitation appears in the sources consulted, and the record lists no fixed versions, so upgrade boundaries are inferred from the affected ranges.
Overview
Spring Security has published CVE-2026-22732, in which HTTP response headers specified by servlet applications may not be written to the response. The issue arises under the default lazy writing mode for headers. The record associates it with CWE-425 and a CVSS score of 9.1 assigned by the CNA. See the vendor advisory for the official statement.
Impact
- The CVSS vector in the record describes a network-reachable issue requiring no privileges and no user interaction, with high confidentiality and integrity impact and no availability impact.
- Missing security headers can weaken browser-side protections applied to responses. The practical effect depends on which headers the application relies on, which the record does not detail.
Affected products and versions
- Servlet applications using Spring Security with the default lazy writing of HTTP headers.
- From 5.7.0 up to and including 5.7.21
- From 5.8.0 up to and including 5.8.23
- From 6.3.0 up to and including 6.3.14
- From 6.4.0 up to and including 6.4.14
- From 6.5.0 up to and including 6.5.8
- From 7.0.0 up to and including 7.0.3
The affected ranges in the record indicate that the first versions outside them, per branch, are 5.7.22, 5.8.24, 6.3.15, 6.4.15, 6.5.9 and 7.0.4. The record's fixes list is empty, so this is an inference from the range boundaries and should be confirmed against the vendor advisory.
Exploitation status
The record shows no CISA KEV listing (kev.listed is false). No confirmed exploitation in the wild appears in the sources consulted. The vendor reference is tagged 'Exploit' in the record, but that tag does not establish exploitation activity. The SSVC data lists exploitation as 'none' and automatable as 'yes'. The EPSS probability is 0.00489 with a percentile of 0.41177.
Remediation and mitigation
- Upgrade to a release outside the affected ranges for your branch, as described in the vendor advisory.
- If an upgrade cannot be applied immediately, review the application's header configuration and confirm that responses carry the expected headers. The record describes no specific workaround, so none is stated here.
- Inventory where Spring Security is used, including transitive dependencies, to plan upgrades.
Detection guidance
- Compare expected security headers with actual responses in staging and production for representative endpoints, including static content and error responses.
- Check dependency manifests and software bills of materials for the affected versions.
- Monitor for unexpected changes in header behavior after deployments.
Limitations of the available information
- The record does not identify which headers are affected or the exact request conditions.
- The fixes list is empty; corrected versions are inferred from range boundaries.
- The record gives a CWE ID for CWE-425 but no name.
- The sources consulted include no proof of concept or root-cause analysis, and none is provided here.
- The record does not state the support status of the affected branches.
Frequently asked questions
Is this vulnerability being actively exploited?
The record shows no CISA KEV listing, and no confirmed exploitation in the wild appears in the sources consulted.
Which applications are affected?
Servlet applications using Spring Security with the default lazy writing of HTTP headers, within the version ranges listed in the record.
What should teams do now?
Check whether they use an affected branch, plan an upgrade to a release outside the ranges, and verify response headers in the meantime.
This analysis was drafted with AI assistance from verified source data and automatically checked against it.