EUVD-2026-35896
GHSA-x2r2-rvhq-2mqv
Severity by source
AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
Primary rating from Vendor (vmware) · only source for this CVE.
CVSS VectorVendor: vmware
Lifecycle Timeline
2Blast Radius
ecosystem impact- 181 maven packages depend on org.springframework.security:spring-security-web (25 direct, 156 indirect)
Ecosystem-wide dependent count for version 7.0.0.
DescriptionCVE.org
Spring Security's CookieRequestCache and CookieServerRequestCache store the pre-authentication request URL in a browser cookie so that users can be redirected back to their intended destination after a successful login. In affected versions, the full absolute URL is stored in the cookie and is used without validation as the post-login redirect target.
Affected versions: Spring Security 5.7.0 through 5.7.23; 5.8.0 through 5.8.25; 6.3.0 through 6.3.16; 6.4.0 through 6.4.16; 6.5.0 through 6.5.10; 7.0.0 through 7.0.5.
AnalysisAI
Open redirect in Spring Security's cookie-based saved-request components allows remote unauthenticated attackers to redirect authenticated users to arbitrary external URLs immediately after a successful login. The CookieRequestCache (servlet stack) and CookieServerRequestCache (reactive/WebFlux stack) store the full pre-authentication URL in a browser cookie and use it without origin validation as the post-login Location target, making this exploitable via a socially engineered link. No active exploitation is confirmed (not in CISA KEV) and no public exploit code has been identified at time of analysis, though the S:C scope change and PR:N attack profile make this a meaningful phishing enabler in any Spring Security deployment using cookie-backed saved requests.
Technical ContextAI
Spring Security is the de facto Java security framework for Spring and Spring Boot applications, handling authentication, authorization, and session management. The CookieRequestCache (used in the servlet/MVC stack) and CookieServerRequestCache (used in the reactive/WebFlux stack) implement a UX pattern where the pre-authentication destination URL is persisted in a browser cookie so users are transparently redirected to their intended page after logging in. The root cause is CWE-601 (URL Redirection to Untrusted Site / Open Redirect): the stored URL value is read back from the cookie and used directly in the HTTP Location response header without validating that the URL belongs to the same origin or is on a permitted allowlist. An attacker who can deliver a crafted URL to a victim - one that sets or influences the redirect cookie value to point to an external site - can hijack the post-login redirect. Both the synchronous MVC and asynchronous reactive stacks are affected, broadening the exposure across the full range of Spring web application deployment models.
RemediationAI
The primary remediation is to upgrade Spring Security to a patched release per the vendor advisory at https://spring.io/security/cve-2026-41706. Exact fixed version numbers for each affected branch (5.7.x, 5.8.x, 6.3.x, 6.4.x, 6.5.x, 7.0.x) were not confirmed in the provided data and must be verified directly against the advisory before applying. If immediate patching is not feasible, a compensating control is to implement a custom SavedRequestAwareAuthenticationSuccessHandler (servlet) or custom ServerRedirectStrategy (reactive) that validates the redirect URL against an explicit allowlist of permitted origins before issuing the Location response - rejecting or defaulting to '/' any URL whose host does not match the application's own domain. This mitigation requires application code changes but fully eliminates the redirect vector. A secondary layer is WAF-based inspection of Set-Cookie headers on login responses to flag or strip cookie values containing external URLs, though this is operationally fragile and should not substitute for the code-level fix. Note that switching from CookieRequestCache to HttpSessionRequestCache avoids this specific class of cookie-based attack surface but introduces server-side session state requirements, which may have scalability trade-offs in stateless deployments.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
Share
External POC / Exploit Code
Leaving vuln.today