Spring Security Advisories

Spring Web Services, versions 2.4.3, 3.0.4, and older unsupported versions of all three projects, were susceptible to XML External Entity Injection (XXE) when receiving XML data from untrusted sources.

Spring Batch versions 3.0.9, 4.0.1, 4.1.0, and older unsupported versions, were susceptible to XML External Entity Injection (XXE) when receiving XML data from untrusted sources.

Spring Security versions 5.1.x prior to 5.1.2 contain an authorization bypass vulnerability during JWT issuer validation. In order to be impacted, the same private key for an honest issuer and a malicious user must be used when signing JWTs. In that case, a malicious user could fashion signed JWTs with the malicious issuer URL that may be granted for the honest issuer.

Spring Security OAuth, versions 2.3 prior to 2.3.4, and 2.2 prior to 2.2.3, and 2.1 prior to 2.1.3, and 2.0 prior to 2.0.16, and older unsupported versions could be susceptible to a privilege escalation under certain conditions. A malicious user or attacker can craft a request to the approval endpoint that can modify the previously saved authorization request and lead to a privilege escalation on the subsequent approval. This scenario can happen if the application is configured to use a custom approval endpoint that declares AuthorizationRequest as a controller method argument.

This vulnerability exposes applications that meet all of the following requirements:

• Act in the role of an Authorization Server (e.g. @EnableAuthorizationServer)
• Use a custom Approval Endpoint that declares AuthorizationRequest as a controller method argument

This vulnerability does not expose applications that:

• Act in the role of an Authorization Server and use the default Approval Endpoint
• Act in the role of a Resource Server only (e.g. @EnableResourceServer)
• Act in the role of a Client only (e.g. @EnableOAuthClient)

Spring Framework, version 5.1, versions 5.0.x prior to 5.0.10, versions 4.3.x prior to 4.3.20, and older unsupported versions on the 4.2.x branch provide support for range requests when serving static resources through the ResourceHttpRequestHandler, or starting in 5.0 when an annotated controller returns an org.springframework.core.io.Resource. A malicious user (or attacker) can add a range header with a high number of ranges, or with wide ranges that overlap, or both, for a denial of service attack.

This vulnerability affects applications that depend on either spring-webmvc or spring-webflux. Such applications must also have a registration for serving static resources (e.g. JS, CSS, images, and others), or have an annotated controller that returns an org.springframework.core.io.Resource.

Spring Boot applications that depend on spring-boot-starter-web or spring-boot-starter-webflux are ready to serve static resources out of the box and are therefore vulnerable.

spring-amqp, 1.x versions prior to 1.7.10, 2.x versions prior to 2.0.6 expose a man-in-the middle vulnerability.

The Spring RabbitMQ Java Client does not perform hostname validation.

This means that SSL certificates of other hosts are blindly accepted as long as they are trusted.

To exploit this vulnerability an attacker has to perform a man-in-the-middle (MITM) attack between a Java application using the Spring RabbitMQ Java Client and an RabbitMQ server it's connecting to.

TLS normally protects users and systems against MITM attacks, it cannot if certificates from other trusted hosts are accepted by the client.

Spring AMQP uses the RabbitMQ amqp-client java library for communication with RabbitMQ.

It uses the RabbitConnectionFactoryBean to create/configure the connection factory.

Spring Framework, versions 5.0.x prior to 5.0.7, versions 4.3.x prior to 4.3.18, and older unsupported versions, allows web applications to enable cross-domain requests via JSONP (JSON with Padding) through AbstractJsonpResponseBodyAdvice for REST controllers, and MappingJackson2JsonView for browser requests. Both are not enabled by default in Spring Framework nor Spring Boot. However when MappingJackson2JsonView is configured in an application, JSONP support is automatically ready to use through the "jsonp" and "callback" JSONP parameters, enabling cross-domain requests.

Allowing cross-domain requests from untrusted origins may expose user information to 3rd party browser scripts.

This vulnerability applies to applications that:

• Explicitly configure MappingJackson2JsonView.
• And do not set the jsonpParameterNames property of MappingJackson2JsonView to an empty set.
• And expose sensitive user information over endpoints that can render content with JSONP.

Spring Framework (versions 5.0.x prior to 5.0.7, versions 4.3.x prior to 4.3.18, and older unsupported versions) allow web applications to change the HTTP request method to any HTTP method (including TRACE) using the HiddenHttpMethodFilter in Spring MVC. If an application has a pre-existing XSS vulnerability, a malicious user (or attacker) can use this filter to escalate to an XST (Cross Site Tracing) attack.

spring-integration-zip , versions prior to 1.0.2, exposes an arbitrary file write vulnerability, that can be achieved using a specially crafted zip archive (affects other archives as well, bzip2, tar, xz, war, cpio, 7z), that holds path traversal filenames. So when the filename gets concatenated to the target extraction directory, the final path ends up outside of the target folder. The previous CVE-2018-1261 prevented the framework itself from writing the file. While the framework itself now does not write such files, it does present the errant path to the user application, which could inadvertently write the file using that path.

This specifically applies to the unzip transformer.

This can only happen if an application using this library accepts and unpacks zip files from untrusted sources.

spring-integration-zip , versions prior to 1.0.1, exposes an arbitrary file write vulnerability, that can be achieved using a specially crafted zip archive (affects other archives as well, bzip2, tar, xz, war, cpio, 7z), that holds path traversal filenames. So when the filename gets concatenated to the target extraction directory, the final path ends up outside of the target folder.

This specifically applies to the unzip transformer.

This can only happen if an application using this library accepts and unpacks zip files from untrusted sources.