Vulnerabilities (CVE)

Filtered by vendor Vmware Subscribe
Filtered by product Spring Security
CVE Vendors Products Updated CVSS v2 CVSS v3
CVE-2023-34034 1 Vmware 1 Spring Security 2023-08-14 N/A 9.8 CRITICAL
Using "**" as a pattern in Spring Security configuration for WebFlux creates a mismatch in pattern matching between Spring Security and Spring WebFlux, and the potential for a security bypass.
CVE-2022-31692 2 Netapp, Vmware 2 Active Iq Unified Manager, Spring Security 2023-08-08 N/A 9.8 CRITICAL
Spring Security, versions 5.7 prior to 5.7.5 and 5.6 prior to 5.6.9 could be susceptible to authorization rules bypass via forward or include dispatcher types. Specifically, an application is vulnerable when all of the following are true: The application expects that Spring Security applies security to forward and include dispatcher types. The application uses the AuthorizationFilter either manually or via the authorizeHttpRequests() method. The application configures the FilterChainProxy to apply to forward and/or include requests (e.g. spring.security.filter.dispatcher-types = request, error, async, forward, include). The application may forward or include the request to a higher privilege-secured endpoint.The application configures Spring Security to apply to every dispatcher type via authorizeHttpRequests().shouldFilterAllDispatcherTypes(true)
CVE-2022-22978 1 Vmware 1 Spring Security 2022-07-25 7.5 HIGH 9.8 CRITICAL
In Spring Security versions 5.5.6 and 5.6.3 and older unsupported versions, RegexRequestMatcher can easily be misconfigured to be bypassed on some servlet containers. Applications using RegexRequestMatcher with `.` in the regular expression are possibly vulnerable to an authorization bypass
CVE-2014-3527 1 Vmware 1 Spring Security 2021-06-08 7.5 HIGH 9.8 CRITICAL
When using the CAS Proxy ticket authentication from Spring Security 3.1 to 3.2.4 a malicious CAS Service could trick another CAS Service into authenticating a proxy ticket that was not associated. This is due to the fact that the proxy ticket authentication uses the information from the HttpServletRequest which is populated based upon untrusted information within the HTTP request. This means if there are access control restrictions on which CAS services can authenticate to one another, those restrictions can be bypassed. If users are not using CAS Proxy tickets and not basing access control decisions based upon the CAS Service, then there is no impact to users.