This affects Spring Data JPA in versions up to and including 2.1.6, 2.0.14 and 1.11.20. Using ExampleMatcher.StringMatcher.STARTING, ExampleMatcher.StringMatcher.ENDING or ExampleMatcher.StringMatcher.CONTAINING could return more results than anticipated when a maliciously crafted example value is supplied.
Affected Spring Products and Versions
Spring Data JPA 2.1 to 2.1.7
Spring Data JPA 2.0 to 2.0.14
Spring Data JPA 1.11 to 1.11.21
Older unsupported versions are also affected
Mitigation
Users of affected versions should apply the following mitigation:
2.1.x users should upgrade to 2.1.8 (included in Spring Boot 2.1.5)
2.0.x users should upgrade to 2.1.8 (included in Spring Boot 2.1.5)
1.11.x users should upgrade to 1.11.22 (included in Spring Boot 1.5.20)
Older versions should upgrade to a supported branch
There are no other mitigation steps necessary. Note, that with the current releases, the 2.0 branch of both Spring Data and Spring Boot is EOL and we highly recommend to upgrade
Credit
This issue was identified and responsibly reported by Thaveethu Vignesh
Spring Cloud Config, versions 2.1.x prior to 2.1.2, versions 2.0.x prior to 2.0.4, and versions 1.4.x prior to 1.4.6, and older unsupported versions allow applications to serve arbitrary configuration files through the spring-cloud-config-server module. A malicious user, or attacker, can send a request using a specially crafted URL that can lead a directory traversal attack.
Affected Spring Products and Versions
Spring Cloud Config 2.1.0 to 2.1.1
Spring Cloud Config 2.0.0 to 2.0.3
Spring Cloud Config 1.4.0 to 1.4.5
Older unsupported versions are also affected
Mitigation
Users of affected versions should apply the following mitigation:
2.1.x users should upgrade to 2.1.2
2.0.x users should upgrade to 2.0.4
1.4.x users should upgrade to 1.4.6
Older versions should upgrade to a supported branch
Note that spring-cloud-config-server should only be available on internal networks to clients that require it and it should be secured with Spring Security, this limits exposure to this vulnerability to those with internal network access and those users with proper authentication.
Credit
This issue was identified and responsibly reported by Vern ([email protected] from PingAn Galaxy Lab).
This affects Spring Data JPA in versions up to and including 2.1.5, 2.0.13 and 1.11.19. Derived queries using any of the predicates ‘startingWith’, ‘endingWith’ or ‘containing’ could return more results than anticipated when a maliciously crafted query parameter value is supplied. Also, LIKE expressions in manually defined queries could return unexpected results if the parameter values bound did not have escaped reserved characters properly.
Affected Spring Products and Versions
Spring Data JPA 2.0 to 2.0.13
Spring Data JPA 2.1 to 2.1.5
Spring Data JPA 1.11 to 1.11.19
Older unsupported versions are also affected
Mitigation
Users of affected versions should apply the following mitigation:
2.1.x users should upgrade to 2.1.6 (included in <a href="https://spring.io/blog/2019/04/04/spring-boot-2-1-4-released">Spring Boot 2.1.4</a>)
2.0.x users should upgrade to 2.0.14 (included in <a href="https://spring.io/blog/2019/04/03/spring-boot-2-0-9-released">Spring Boot 2.0.9</a>)
1.11.x users should upgrade to 1.11.20 (included in <a href="https://spring.io/blog/2019/04/03/spring-boot-1-5-20-available-now">Spring Boot 1.5.20</a>)
Older versions should upgrade to a supported branch
There are no other mitigation steps necessary. Note, that with the current releases, the 2.0 branch of both Spring Data and Spring Boot is EOL and we highly recommend to upgrade
Credit
This issue was identified and responsibly reported by Maruthi Adithya G
Spring Security versions 4.2.x prior to 4.2.12, 5.0.x prior to 5.0.12, and 5.1.x prior to 5.1.5 contain an insecure randomness vulnerability when using SecureRandomFactoryBean#setSeed to configure a SecureRandom instance. In order to be impacted, an honest application must provide a seed and make the resulting random material available to an attacker for inspection.
Affected Spring Products and Versions
Spring Security 4.2 to 4.2.11
Spring Security 5.0 to 5.0.11
Spring Security 5.1 to 5.1.4
Mitigation
Users of affected versions should apply the following mitigation:
4.2.x users should upgrade to 4.2.12
5.0.x users should upgrade to 5.0.12
5.1.x users should upgrade to 5.1.5
Credit
This issue was identified and responsibly reported by Thijs Alkemade.
Spring Security OAuth, versions 2.3 prior to 2.3.5, and 2.2 prior to 2.2.4, and 2.1 prior to 2.1.4, and 2.0 prior to 2.0.17, and older unsupported versions could be susceptible to an open redirector attack that can leak an authorization code. A malicious user or attacker can craft a request to the authorization endpoint using the authorization code grant type, and specify a manipulated redirection URI via the "redirect_uri" parameter. This can cause the authorization server to redirect the resource owner user-agent to a URI under the control of the attacker with the leaked authorization code.
This vulnerability exposes applications that meet all of the following requirements:
Act in the role of an Authorization Server (e.g. @EnableAuthorizationServer)
Uses the DefaultRedirectResolver in the AuthorizationEndpoint
This vulnerability does not expose applications that:
Act in the role of an Authorization Server and uses a different RedirectResolver implementation other than DefaultRedirectResolver
Act in the role of a Resource Server only (e.g. @EnableResourceServer)
Act in the role of a Client only (e.g. @EnableOAuthClient)
Affected Spring Products and Versions
Spring Security OAuth 2.3 to 2.3.4
Spring Security OAuth 2.2 to 2.2.3
Spring Security OAuth 2.1 to 2.1.3
Spring Security OAuth 2.0 to 2.0.16
Older unsupported versions are also affected
Mitigation
Users of affected versions should apply the following mitigation:
<strong>2.3.x</strong> users should upgrade to <strong>2.3.5</strong>
<strong>2.2.x</strong> users should upgrade to <strong>2.2.4</strong>
<strong>2.1.x</strong> users should upgrade to <strong>2.1.4</strong>
<strong>2.0.x</strong> users should upgrade to <strong>2.0.17</strong>
Older versions should upgrade to a supported branch
There are no other mitigation steps necessary.
For users of Spring Boot 1.5.x and Spring IO Platform Cairo, it is highly recommended to override the spring-security-oauth version to the latest version containing the patch for the CVE. In order to override the version, you need to declare/set the property spring-security-oauth.version.
Below are instructions for users of Spring Boot 1.5.x.
To override a property using Maven, declare the property in your pom’s section:
2.0.17.RELEASE
To override a property using Gradle, configure the value in your build.gradle script:
NOTE: The same instructions apply for users of Spring IO Platform Cairo. However, the version to specify is 2.2.4.RELEASE.
Credit
This issue was identified and responsibly reported by Dirk Koehler (github.com/phrinx) from dotloop. Special thanks to Macchinetta Framework Development Team from NTT, NTT Comware, NTT DATA…
Spring Integration (spring-integration-xml and spring-integration-ws modules), versions 4.3.18, 5.0.10, 5.1.1, and older unsupported versions, were susceptible to XML External Entity Injection (XXE) when receiving XML data from untrusted sources.
Affected Spring Products and Versions
Spring Integration versions 5.1.1, 5.0.10, 4.3.18 and older
Mitigation
Users of affected versions should apply the following mitigation:
Upgrade spring-integration-ws, spring-integration-xml to 4.3.19, 5.0.11, 5.1.2 or later.
Spring Integration components that exhibited this vulnerability now disable the features as advised in the reference cheat sheet [1] by default, but allow user configuration of the components if the feature can be enabled because XML is received from a trusted source.
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.
Affected Spring Products and Versions
Spring Batch versions 3.0.9, 4.0.1, 4.1.0 and older
Mitigation
Users of affected versions should apply the following mitigation:
Upgrade spring-batch jars to 3.0.10, 4.0.2, 4.1.1 or later
Spring Batch components that exhibited this vulnerability now disable the features as advised in the reference cheat sheet [1] by default, but allow user configuration of the components if the feature can be enabled because XML is received from a trusted source.
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.
Affected Spring Products and Versions
Spring Web Services versions 2.4.3, 3.0.4 and older
Mitigation
Users of affected versions should apply the following mitigation:
Upgrade spring-ws, spring-xml jars to 2.4.4, 3.0.6 or later
Spring Web Services components that exhibited this vulnerability now disable the features as advised in the reference cheat sheet [1] by default, but allow user configuration of the components if the feature can be enabled because XML is received from a trusted source.
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.
Affected Spring Products and Versions
Spring Framework 5.1 to 5.1.1
Mitigation
Users of affected versions should apply the following mitigation:
5.1.x users should upgrade to 5.1.2
There are no other mitigation steps necessary.
Credit
This issue was identified and responsibly reported by Björn Bilger.
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.
Affected Spring Products and Versions
Spring Framework 5.1
Spring Framework 5.0.0 to 5.0.9
Spring Framework 4.3 to 4.3.19
Older unsupported versions going back to 4.2 are also affected
Mitigation
Users of affected versions should apply the following mitigation:
5.1 users should upgrade to 5.1.1
5.0.x users should upgrade to 5.0.10
4.3.x users should upgrade to 4.3.20
4.2.x users should upgrade to a supported branch.
No further mitigation steps are necessary.
Note the following when evaluating the impact:
Support for Range requests was introduced in version 4.2. Therefore versions prior to 4.2 are not affected by this issue.
Support for returning an org.springfamework.core.io.Resource from an annotated controller was introduced in 5.0. Therefore versions prior to 5.0 can only be impacted through a registration to serve static resources.
Credit
This issue was identified and responsibly reported by Nicholas Starke from Aruba Threat Labs.
