Overview 5 matches · 0 protected · 0 exploited · 0 CISA KEV · 2 public PoC · 0 EPSS ≥ 0.5
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
2
40.0%
No exploit published
3
60.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
5
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
2
40.0%
Forecast only
0
0.0%
No public exploit
3
60.0%
split by
peak 2 / year
20171
No exploit published1
Critical1
not blocked1
No public exploit1
20180
20190
20200
20210
20222
Mitigation candidate2
Critical2
not blocked2
Proof of concept only2
20231
No exploit published1
Critical1
not blocked1
No public exploit1
20241
No exploit published1
Critical1
not blocked1
No public exploit1
20172018201920202021202220232024
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2024-38821 | Critical | 2024-10-28 | No exploit published | No public exploit | Spring WebFlux applications that have Spring Security authorization rules on static resources can be bypassed under certain circumstances. For this to impact an application, all of the following must be true: * It must be a WebFlux application * It must be using Spring's static resources support * It must have a non-permitAll authorization rule applied to the static resources support |
| CVE-2023-34034 | Critical | 2023-07-19 | No exploit published | No public exploit | 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 | Critical | 2022-10-31 | Mitigation candidate | Proof of concept only | 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 | Critical | 2022-05-19 | Mitigation candidate | Proof of concept only | In spring security versions prior to 5.4.11+, 5.5.7+ , 5.6.4+ 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 | Critical | 2017-05-25 | No exploit published | No public exploit | 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. |