Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
30 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Vulnerability in Spring Spring Security. If an application is using the UserDetails#isEnabled, #isAccountNonExpired, or #isAccountNonLocked user attributes, to enable, expire, or lock users, then DaoAuthenticationProvider's timing attack defense can be bypassed for users who are disabled, expired, or locked. This issue affects Spring Security: from 5.7.0 through 5.7.22, from 5.8.0 through 5.8.24, from 6.3.0 through 6.3.15, from 6.5.0 through 6.5.9, from 7.0.0 through 7.0.4.
Recommended action: Upgrade to 7.0.5 or 6.5.10 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability in Spring Spring Security. Applications that explicitly configure One-Time Token login with JdbcOneTimeTokenService are vulnerable to a Time-of-check Time-of-use (TOCTOU) race condition. This issue affects Spring Security: from 6.4.0 through 6.4.15, from 6.5.0 through 6.5.9, from 7.0.0 through 7.0.4.
Recommended action: Upgrade to 7.0.5 or 6.5.10 by release line; some affected versions have no fix yet, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix applied in CVE-2025-22228 inadvertently broke the timing attack mitigation implemented in DaoAuthenticationProvider. This can allow attackers to infer valid usernames or other authentication behavior via response-time differences under certain configurations.
Recommended action: Upgrade to 6.4.5 or 6.3.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Spring Security annotation detection mechanism may not correctly resolve annotations on methods within type hierarchies with a parameterized super type with unbounded generics. This can be an issue when using @PreAuthorize and other method security annotations, resulting in an authorization bypass. Your application may be affected by this if you are using Spring Security's @EnableMethodSecurity feature. You are not affected by this if you are not using @EnableMethodSecurity or if you do not use security annotations on methods in generic superclasses or generic interfaces. This CVE is published in conjunction with CVE-2025-41249 https://spring.io/security/cve-2025-41249 .
Recommended action: Upgrade to 6.5.4 or 6.4.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Spring Security Aspects may not correctly locate method security annotations on private methods. This can cause an authorization bypass. Your application may be affected by this if the following are true: You are using @EnableMethodSecurity(mode=ASPECTJ) and spring-security-aspects, and You have Spring Security method annotations on a private method In that case, the target method may be able to be invoked without proper authorization. You are not affected if: You are not using @EnableMethodSecurity(mode=ASPECTJ) or spring-security-aspects, or You have no Spring Security-annotated private methods
Recommended action: Upgrade to 6.4.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Spring Security 6.4.0 - 6.4.3 may not correctly locate method security annotations on parameterized types or methods. This may cause an authorization bypass. You are not affected if you are not using @EnableMethodSecurity, or you do not have method security annotations on parameterized types or methods, or all method security annotations are attached to target methods
Recommended action: Upgrade to 6.4.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
6.3.55.7.146.0.145.8.166.1.126.2.8· Vendor fix available
Issue
The usage of String.toLowerCase() and String.toUpperCase() has some Locale dependent exceptions that could potentially result in authorization rules not working properly.
Recommended action: Upgrade to 6.3.5, 6.2.8, 6.1.12 or 3 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Missing Authorization When Using @AuthorizeReturnObject in Spring Security 6.3.0 and 6.3.1 allows attacker to render security annotations inaffective.
Recommended action: Upgrade to 6.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Spring Security, versions 5.7.x prior to 5.7.12, 5.8.x prior to 5.8.11, versions 6.0.x prior to 6.0.9, versions 6.1.x prior to 6.1.8, versions 6.2.x prior to 6.2.3, an application is possible vulnerable to broken access control when it directly uses the AuthenticatedVoter#vote passing a null Authentication parameter. Specifically, an application is vulnerable if: The application uses AuthenticatedVoter directly and a null authentication parameter is passed to it resulting in an erroneous true return value. An application is not vulnerable if any of the following is true: The application does not use AuthenticatedVoter#vote directly. The application does not pass null to AuthenticatedVoter#vote. Note that AuthenticatedVoter is deprecated since 5.8, use implementations of AuthorizationManager as a replacement.
Recommended action: Upgrade to 6.2.3, 6.1.8, 5.8.11 or 5.7.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Spring Security, versions 6.1.x prior to 6.1.7 and versions 6.2.x prior to 6.2.2, an application is vulnerable to broken access control when it directly uses the AuthenticationTrustResolver.isFullyAuthenticated(Authentication) method. Specifically, an application is vulnerable if: The application uses AuthenticationTrustResolver.isFullyAuthenticated(Authentication) directly and a null authentication parameter is passed to it resulting in an erroneous true return value. An application is not vulnerable if any of the following is true: The application does not use AuthenticationTrustResolver.isFullyAuthenticated(Authentication) directly. The application does not pass null to AuthenticationTrustResolver.isFullyAuthenticated The application only uses isFullyAuthenticated via Method Security https://docs.spring.io/spring-security/reference/servlet/authorization/method-security.html or HTTP Request Security…
Recommended action: Upgrade to 6.2.2 or 6.1.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Spring Security, versions 5.7.x prior to 5.7.8, versions 5.8.x prior to 5.8.3, and versions 6.0.x prior to 6.0.3, the logout support does not properly clean the security context if using serialized versions. Additionally, it is not possible to explicitly save an empty security context to the HttpSessionSecurityContextRepository. This vulnerability can keep users authenticated even after they performed logout. Users of affected versions should apply the following mitigation. 5.7.x users should upgrade to 5.7.8. 5.8.x users should upgrade to 5.8.3. 6.0.x users should upgrade to 6.0.3.
Recommended action: Upgrade to 6.0.3, 5.8.3 or 5.7.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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)
Recommended action: Upgrade to 5.7.5 or 5.6.9 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Spring Security versions 5.5.6 and 5.5.7 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.
Recommended action: Upgrade to 5.6.4, 5.5.7 or 5.4.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Spring Security versions 5.5.x prior to 5.5.7, 5.6.x prior to 5.6.4, and earlier unsupported versions contain an integer overflow vulnerability. When using the BCrypt class with the maximum work factor (31), the encoder does not perform any salt rounds, due to an integer overflow error. The default settings are not affected by this CVE.
Recommended action: Upgrade to 5.6.4 or 5.5.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
CRLF injection vulnerability in the logout functionality in VMware SpringSource Spring Security before 2.0.7 and 3.0.x before 3.0.6 allows remote attackers to inject arbitrary HTTP headers and conduct HTTP response splitting attacks via the spring-security-redirect parameter.
Recommended action: Upgrade to 3.0.6 or 2.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
DaoAuthenticationProvider in VMware SpringSource Spring Security before 2.0.8, 3.0.x before 3.0.8, and 3.1.x before 3.1.3 does not check the password if the user is not found, which makes the response delay shorter and might allow remote attackers to enumerate valid usernames via a series of login requests.
Recommended action: Upgrade to 3.1.3, 3.0.8 or 2.0.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Race condition in the RunAsManager mechanism in VMware SpringSource Spring Security before 2.0.7 and 3.0.x before 3.0.6 stores the Authentication object in the shared security context, which allows attackers to gain privileges via a crafted thread.
Recommended action: Upgrade to 3.0.6 or 2.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Spring Framework 3.0.0 through 3.0.5, Spring Security 3.0.0 through 3.0.5 and 2.0.0 through 2.0.6, and possibly other versions deserialize objects from untrusted sources, which allows remote attackers to bypass intended security restrictions and execute untrusted code by (1) serializing a java.lang.Proxy instance and using InvocationHandler, or (2) accessing internal AOP interfaces, as demonstrated using deserialization of a DefaultListableBeanFactory instance to execute arbitrary commands via the java.lang.Runtime class.
Recommended action: Upgrade to 3.0.6 or 2.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An issue was discovered in Pivotal Spring Security 4.2.0.RELEASE through 4.2.2.RELEASE, and Spring Security 5.0.0.M1. When configured to enable default typing, Jackson contained a deserialization vulnerability that could lead to arbitrary code execution. Jackson fixed this vulnerability by blacklisting known "deserialization gadgets." Spring Security configures Jackson with global default typing enabled, which means that (through the previous exploit) arbitrary code could be executed if all of the following is true: (1) Spring Security's Jackson support is being leveraged by invoking SecurityJackson2Modules.getModules(ClassLoader) or SecurityJackson2Modules.enableDefaultTyping(ObjectMapper); (2) Jackson is used to deserialize data that is not trusted (Spring Security does not perform deserialization using Jackson, so this is an explicit choice of the user); and (3) there is an unknown (Jackson is not blacklisting it already) "deserialization gadget" that allows code execution present…
Recommended action: Upgrade to 5.0.0.M2 or 4.2.3.RELEASE by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ActiveDirectoryLdapAuthenticator in Spring Security 3.2.0 to 3.2.1 and 3.1.0 to 3.1.5 does not check the password length. If the directory allows anonymous binds then it may incorrectly authenticate a user who supplies an empty password.
Recommended action: Upgrade to 3.2.2.RELEASE or 3.1.5.RELEASE by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Spring Security versions 5.5.x prior to 5.5.1, 5.4.x prior to 5.4.7, 5.3.x prior to 5.3.10 and 5.2.x prior to 5.2.11 are susceptible to a Denial-of-Service (DoS) attack via the initiation of the Authorization Request in an OAuth 2.0 Client Web and WebFlux application. A malicious user or attacker can send multiple requests initiating the Authorization Request for the Authorization Code Grant, which has the potential of exhausting system resources using a single session or multiple sessions.
Recommended action: Upgrade to 5.5.1, 5.4.7, 5.3.10 or 5.2.11 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
3.2.10.RELEASE4.2.1.RELEASE4.1.4.RELEASE· Vendor fix available
Issue
Spring Security does not consider URL path parameters when processing security constraints. By adding a URL path parameter with an encoded "/" to a request, an attacker may be able to bypass a security constraint. The root cause of this issue is a lack of clarity regarding the handling of path parameters in the Servlet Specification (see below). Some Servlet containers include path parameters in the value returned for getPathInfo() and some do not. Spring Security uses the value returned by getPathInfo() as part of the process of mapping requests to security constraints. The unexpected presence of path parameters can cause a constraint to be bypassed. Users of Apache Tomcat (all current versions) are not affected by this vulnerability since Tomcat follows the guidance previously provided by the Servlet Expert group and strips path parameters from the value returned by getContextPath(), getServletPath() and getPathInfo() [1]. Users of other Servlet containers based on Apache Tomcat…
Recommended action: Upgrade to 4.2.1.RELEASE, 4.1.4.RELEASE or 3.2.10.RELEASE by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When using Spring Security's CAS Proxy ticket authentication 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. Mitigation Users of affected versions should apply the following mitigation: - Users of 3.2x should upgrade to 3.2.5 or later - Users of 3.1.x should upgrade to 3.1.7 or later Credit This issue was identified by David Ohsie and brought to our attention by the CAS Development team.
Recommended action: Upgrade to 3.2.5 or 3.1.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
5.3.25.0.165.1.105.2.44.2.16· Vendor fix available
Issue
Spring Security versions 5.3.x prior to 5.3.2, 5.2.x prior to 5.2.4, 5.1.x prior to 5.1.10, 5.0.x prior to 5.0.16 and 4.2.x prior to 4.2.16 use a fixed null initialization vector with CBC Mode in the implementation of the queryable text encryptor. A malicious user with access to the data that has been encrypted using such an encryptor may be able to derive the unencrypted values using a dictionary attack.
Recommended action: Upgrade to 5.3.2, 5.2.4, 5.1.10 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Spring Security versions 5.2.x prior to 5.2.4 and 5.3.x prior to 5.3.2 contain a signature wrapping vulnerability during SAML response validation. When using the spring-security-saml2-service-provider component, a malicious user can carefully modify an otherwise valid SAML response and append an arbitrary assertion that Spring Security will accept as valid.
Recommended action: Upgrade to 5.3.2 or 5.2.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.