Table of Contents
While investigating the Spring Framework RCE vulnerability CVE-2022-22965 and the suggested workaround, we realized that the
disallowedFields configuration setting on
WebDataBinder is not intuitive and is not clearly documented. We have fixed that but also decided to be on the safe side and announce a follow-up CVE, in order to ensure application developers are alerted and have a chance to review their configuration.
We have launched Spring Framework 5.3.19 and 5.2.21 which contain the fix. Spring Boot 2.6.7 and 2.5.13 are scheduled to be launched on April 21, 2022.
Until Spring Boot 2.6.7 and 2.5.13 have been launched, you should manually upgrade the Spring Framework dependency in your Spring Boot application. To override the Spring Framework version in your Maven or Gradle construct, you should use the
Please see the documentation for the Spring Boot Maven plugin and Gradle plugin for details.
Prior to the fix in today’s releases, the patterns for
disallowedFields in a
DataBinder were case sensitive which means a field was not effectively protected until patterns were registered with both higher and lower case for the first character of the field, including all mixtures of higher and lower case for the first character of all nested fields inside the property path.
For example, if you’ve seen the Disallowed Fields workaround for the RCE vulnerability, you might have questioned why the disallowed field patterns included apparently duplicate entries. Each pattern had to be registered twice, once with the first character in lowercase, and again with the first character in uppercase. The fix we’ve launched today addresses this by ignoring case when matching against disallowed field patterns. This has the added advantage of disallowing binding to a
firstName property when the registered pattern is
firstname. In other words, the changes we’ve made not only fix the vulnerability reported in the CVE, but they also make disallowed field patterns more robust in general.
Does This Affect My Application?
These are the necessary conditions for the specific vulnerability:
- Registration of disallowed field patterns in a
- Spring Framework versions 5.3.0 to 5.3.18, 5.2.0 to 5.2.20, and older versions
- The issue relates to data binding used to populate an object from request parameters (either query parameters or form data). Data binding is used for controller method parameters that are annotated with
@ModelAttributeor optionally without it, and without any other Spring Web annotation.
- The issue does not relate to
@RequestBodycontroller method parameters (e.g. JSON deserialization). However, such methods may nonetheless be vulnerable if they have another method parameter populated via data binding from query parameters.
- Your Spring MVC or Spring WebFlux application may be susceptible to data binding issues even if you do not register disallowed field patterns. We highly encourage you to review your
DataBinderconfiguration and more broadly your approach to data binding. For more details, please see the new Data Binding Model Design section in the Spring Framework reference guide.
Reassessing Your Data Binding Approach
If you’re using disallowed field patterns and plan to proceed using them, you should definitely update to Spring Framework 5.3.19 and 5.2.21 or greater as soon as possible.
However, there are alternatives to relying on disallowed field patterns. As mentioned in the new Model Design section in the reference guide, our counseled approach is to use a dedicated model object that exposes only properties that are relevant for the supported use case. Another alternative is to switch to allowed field patterns: instead of supplying a “deny list” via
setDisallowedFields(), you can supply an explicit “allow list” via
setAllowedFields() in a
Keep in mind that it is strongly counseled that you do not use types from your domain model such as JPA or Hibernate entities as the model object in data binding situations.