| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| Pivotal Spring AMQP, 1.x versions prior to 1.7.10 and 2.x versions prior to 2.0.6, expose a man-in-the-middle vulnerability due to lack of hostname validation. A malicious user that has the ability to intercept traffic would be able to view data in transit. |
| Missing Authorization When Using @AuthorizeReturnObject in Spring Security 6.3.0 and 6.3.1 allows attacker to render security annotations inaffective. |
| In Spring Framework versions 6.0.0 - 6.0.6, 5.3.0 - 5.3.25, 5.2.0.RELEASE - 5.2.22.RELEASE, and older unsupported versions, it is possible for a user to provide a specially crafted SpEL expression that may cause a denial-of-service (DoS) condition. |
| In Spring Vault, versions 3.0.x prior to 3.0.2 and versions 2.3.x prior to 2.3.3 and older versions, an application is vulnerable to insertion of sensitive information into a log file when it attempts to revoke a Vault batch token. |
| Spring Framework running version 6.0.0 - 6.0.6 or 5.3.0 - 5.3.25 using "**" as a pattern in Spring Security configuration with the mvcRequestMatcher creates a mismatch in pattern matching between Spring Security and Spring MVC, and the potential for a security bypass. |
| In Spring Boot versions 2.7.0 - 2.7.17, 3.0.0-3.0.12 and 3.1.0-3.1.5, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition.
Specifically, an application is vulnerable when all of the following are true:
* the application uses Spring MVC or Spring WebFlux
* org.springframework.boot:spring-boot-actuator is on the classpath |
| In Spring Framework versions 6.0.0 - 6.0.13, it is possible for a user to provide specially crafted HTTP requests that may cause a denial-of-service (DoS) condition.
Specifically, an application is vulnerable when all of the following are true:
* the application uses Spring MVC or Spring WebFlux
* io.micrometer:micrometer-core is on the classpath
* an ObservationRegistry is configured in the application to record observations
Typically, Spring Boot applications need the org.springframework.boot:spring-boot-actuator dependency to meet all conditions. |
| In Spring Session version 3.0.0, the session id can be logged to the standard output stream. This vulnerability exposes sensitive information to those who have access to the application logs and can be used for session hijacking. Specifically, an application is vulnerable if it is using HeaderHttpSessionIdResolver. |
| In spring framework versions prior to 5.2.24 release+ ,5.3.27+ and 6.0.8+ , it is possible for a user to provide a specially crafted SpEL expression that may cause a denial-of-service (DoS) condition. |
| 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. |
| In Spring Boot versions 3.0.0 - 3.0.6, 2.7.0 - 2.7.11, 2.6.0 - 2.6.14, 2.5.0 - 2.5.14 and older unsupported versions, there is potential for a denial-of-service (DoS) attack if Spring MVC is used together with a reverse proxy cache. |
| The fix for CVE-2022-22968 made disallowedFields patterns in DataBinder case insensitive. However, String.toLowerCase() has some Locale dependent exceptions that could potentially result in fields not protected as expected. |
| Applications that parse ETags from "If-Match" or "If-None-Match" request headers are vulnerable to DoS attack.
Users of affected versions should upgrade to the corresponding fixed version.
Users of older, unsupported versions could enforce a size limit on "If-Match" and "If-None-Match" headers, e.g. through a Filter. |
| In Spring Cloud Data Flow versions prior to 2.11.4, a malicious user who has access to the Skipper server api can use a crafted upload request to write an arbitrary file to any location on the file system which could lead to compromising the server |
| An issue in Dromara SaToken version 1.36.0 and before allows a remote attacker to escalate privileges via a crafted payload to the URL. |
|
In spring AMQP versions 1.0.0 to
2.4.16 and 3.0.0 to 3.0.9 , allowed list patterns for deserializable class
names were added to Spring AMQP, allowing users to lock down deserialization of
data in messages from untrusted sources; however by default, when no allowed
list was provided, all classes could be deserialized.
Specifically, an application is
vulnerable if
* the
SimpleMessageConverter or SerializerMessageConverter is used
* the user
does not configure allowed list patterns
* untrusted
message originators gain permissions to write messages to the RabbitMQ
broker to send malicious content
|
| A batch loader function in Spring for GraphQL versions 1.1.0 - 1.1.5 and 1.2.0 - 1.2.2 may be exposed to GraphQL context with values, including security context values, from a different session. An application is vulnerable if it provides a DataLoaderOptions instance when registering batch loader functions through DefaultBatchLoaderRegistry.
|
| In Spring for Apache Kafka 3.0.9 and earlier and versions 2.9.10 and earlier, a possible deserialization attack vector existed, but only if unusual configuration was applied. An attacker would have to construct a malicious serialized object in one of the deserialization exception record headers.
Specifically, an application is vulnerable when all of the following are true:
* The user does not configure an ErrorHandlingDeserializer for the key and/or value of the record
* The user explicitly sets container properties checkDeserExWhenKeyNull and/or checkDeserExWhenValueNull container properties to true.
* The user allows untrusted sources to publish to a Kafka topic
By default, these properties are false, and the container only attempts to deserialize the headers if an ErrorHandlingDeserializer is configured. The ErrorHandlingDeserializer prevents the vulnerability by removing any such malicious headers before processing the record.
|
|
Reactive web applications that use Spring HATEOAS to produce hypermedia-based responses might be exposed to malicious forwarded headers if they are not behind a trusted proxy that ensures correctness of such headers, or if they don't have anything else in place to handle (and possibly discard) forwarded headers either in WebFlux or at the level of the underlying HTTP server.
For the application to be affected, it needs to satisfy the following requirements:
* It needs to use the reactive web stack (Spring WebFlux) and Spring HATEOAS to create links in hypermedia-based responses.
* The application infrastructure does not guard against clients submitting (X-)Forwarded… headers.
|
| 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
|
