Package Instance

Broken Access Control in Spring Security With Direct Use of isFullyAuthenticated
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 https://docs.spring.io/spring-security/reference/servlet/authorization/authorize-http-requests.html

Erroneous authentication pass in Spring Security
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.

Spring Security's spring-security.xsd file is world writable
The spring-security.xsd file inside the spring-security-config jar is world writable which means that if it were extracted it could be written by anyone with access to the file system.

While there are no known exploits, this is an example of “CWE-732: Incorrect Permission Assignment for Critical Resource” and could result in an exploit. Users should update to the latest version of Spring Security to mitigate any future exploits found around this issue.

Spring Framework has Authorization Bypass for Case Sensitive Comparisons
The usage of String.toLowerCase() and String.toUpperCase() has some Locale dependent exceptions that could potentially result in authorization rules not working properly.

Incorrect Authorization
Spring Security versions 5.8 prior to 5.8.5, 6.0 prior to 6.0.5, and 6.1 prior to 6.1.2 could be susceptible to authorization rule misconfiguration if the application uses requestMatchers(String) and multiple servlets, one of them being Spring MVC’s DispatcherServlet. (DispatcherServlet is a Spring MVC component that maps HTTP endpoints to methods on @Controller-annotated classes.)

Specifically, an application is vulnerable when all of the following are true:

 * Spring MVC is on the classpath
 * Spring Security is securing more than one servlet in a single application (one of them being Spring MVC’s DispatcherServlet)
 * The application uses requestMatchers(String) to refer to endpoints that are not Spring MVC endpoints


An application is not vulnerable if any of the following is true:

 * The application does not have Spring MVC on the classpath
 * The application secures no servlets other than Spring MVC’s DispatcherServlet
 * The application uses requestMatchers(String) only for Spring MVC endpoints

Improper Handling of Inconsistent Structural Elements
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.