CVE-2026-22732

What it actually does

This flaw can cause Spring Security Servlet applications to omit configured HTTP security response headers when using the default lazy header-writing behavior. Headers commonly managed by Spring Security include Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and cache-control directives. If these headers are not emitted, browser-side protections that the application depends on may silently fail. The issue does not by itself provide remote code execution, but it can materially weaken protections against clickjacking, content sniffing, insecure transport downgrade behavior, data leakage through caching or referrers, and some client-side injection abuse paths. Affected Spring Security versions include 5.7.0 through 5.7.21, 5.8.0 through 5.8.23, 6.3.0 through 6.3.14, 6.4.0 through 6.4.14, 6.5.0 through 6.5.8, and 7.0.0 through 7.0.3.

Why it matters to the business

Applications may appear to be protected by standard web security controls while actually serving responses without those controls. This can increase the risk of account compromise, unauthorized data exposure, fraudulent user actions through clickjacking, and compliance findings around missing required browser security headers. The CVSS rating is high because exploitation is network-accessible, unauthenticated, and low complexity, but the currently reported EPSS is low and there is no known CISA KEV listing or reported ransomware use, so remediation should be prioritized for internet-facing and sensitive applications rather than treated as confirmed widespread exploitation.

How an attack unfolds

An attacker first identifies a Spring Security Servlet application running an affected version and confirms that security headers are inconsistently or entirely absent from HTTP responses. They then select an abuse technique that depends on the missing header. For example, if X-Frame-Options or a restrictive Content-Security-Policy frame-ancestors directive is absent, the attacker can embed the application in a malicious page and lure a victim into performing actions through clickjacking. If Strict-Transport-Security is absent, an attacker with a suitable network position may have more opportunity to downgrade or intercept first-visit traffic. If X-Content-Type-Options or CSP is absent, browser content handling and script restrictions may be weaker, making other application bugs easier to exploit. The attacker does not need credentials to trigger vulnerable responses, but successful impact often depends on victim interaction with the application or chaining with another client-side or web application weakness.

How to fix it

Upgrade Spring Security to a version that is not in the affected ranges. Based on the disclosed affected ranges, versions after 5.7.21, 5.8.23, 6.3.14, 6.4.14, 6.5.8, and 7.0.3 should be treated as the target patched lines when available from the vendor, and organizations should follow the official Spring Security release advisory for the exact fixed build in their supported branch. If immediate upgrade is not possible, add defense-in-depth controls that set required security headers outside the vulnerable lazy Spring Security path, such as a high-priority servlet filter, application server configuration, ingress controller, API gateway, reverse proxy, or CDN response-header policy. Ensure these compensating controls cover all relevant paths, status codes, redirects, and error responses. Avoid relying only on application documentation or intended configuration; verify the headers are actually emitted at runtime.

How to confirm the fix worked

Confirm the application no longer uses an affected Spring Security version by checking dependency manifests, lockfiles, SBOMs, build output, container layers, and runtime classpath artifacts. For Maven and Gradle applications, verify the resolved version of spring-security-web, spring-security-config, spring-security-core, and related Spring Security modules. Perform dynamic validation by sending HTTP requests to representative endpoints and confirming that expected headers are present on normal responses, redirects, authentication flows, access-denied responses, error responses, and cacheable/static paths. Use tools such as curl, browser developer tools, OWASP ZAP, Burp Suite, securityheaders.com-style scanners, or automated integration tests. Validation should include negative cases where responses are committed early, forwarded, redirected, or generated by error handlers, because header omission issues often appear only on specific response paths.

Typical attack path

1. Fingerprint a target web application and identify evidence of Spring Security or a Java/Spring Servlet stack.
2. Request multiple application routes, including unauthenticated pages, authenticated pages if accessible, redirects, errors, static-resource paths, and API endpoints.
3. Inspect HTTP responses for missing expected security headers such as Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, and cache-control headers.
4. Determine which browser-side protection is absent and choose an attack that benefits from that absence, such as clickjacking, content sniffing, downgrade exposure, or weaker script restrictions.
5. Host a malicious page or network position that abuses the missing browser protection.
6. Lure a user or administrator to interact with the malicious content, or chain the missing header with another web flaw to increase impact.
7. Use the resulting browser behavior to steal sensitive information, cause unintended actions, or bypass intended client-side security boundaries.

How to detect it

This vulnerability does not produce a reliable server-side compromise artifact by itself because exploitation is primarily the absence of expected HTTP headers and may occur entirely through browser behavior or by chaining with other weaknesses. To assess possible prior abuse, review web access logs for unusual referrers, framing attempts, suspicious campaign landing pages, spikes in requests to sensitive user-action endpoints, and requests associated with social-engineering flows. Check WAF, CDN, reverse proxy, and application logs for responses from affected applications where expected headers were absent, especially on authentication, account-management, payment, administrative, and state-changing endpoints. Investigate browser telemetry, EDR web events, proxy logs, and phishing reports for users visiting untrusted pages immediately before performing sensitive actions in the application. For clickjacking scenarios, look for external sites embedding the application in iframes, unusual referrer domains, and unexpected POST or state-changing requests preceded by cross-site navigation. For HSTS-related concerns, examine TLS downgrade indicators, HTTP requests to domains that should be HTTPS-only, and network security alerts. Because there are no known public exploit indicators, detection should focus on exposure verification, anomalous user workflows, suspicious referrers, and evidence of missing headers in historical response telemetry.

What your security team should do

• Inventory all Java Servlet applications using Spring Security and identify those running versions 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, or 7.0.0-7.0.3.
• Prioritize internet-facing applications, authentication portals, administrative interfaces, and applications handling regulated or sensitive data.
• Upgrade Spring Security to the vendor-fixed version for the active release line, or migrate to a supported non-affected branch.
• Where upgrades require change windows, deploy compensating response-header enforcement at the reverse proxy, gateway, servlet filter, or ingress layer.
• Add automated tests that fail builds or deployments when required security headers are missing from representative application responses.
• Run external and internal scans to identify missing security headers across production-like endpoints after remediation.
• Review clickjacking, CSP, HSTS, cache-control, and referrer-policy requirements to ensure the intended headers are explicitly defined rather than assumed from framework defaults.
• Monitor vendor advisories for final fixed-version details and any change in exploitation status, as the issue is high severity despite currently low EPSS and no KEV listing.