VMware offers training and certification to turbo-charge your progress.Learn more
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 released 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 released on April 21, 2022.
Until Spring Boot 2.6.7 and 2.5.13 have been released, you should manually upgrade the Spring Framework dependency in your Spring Boot application. To override the Spring Framework version in your Maven or Gradle build, 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 unless patterns were registered with both upper and lower case for the first character of the field, including all combinations of upper and lower case for the first character of all nested fields within the property path.
For example, if you've seen the Disallowed Fields workaround for the RCE vulnerability, you might have wondered why the disallowed field patterns included seemingly 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 released today addresses this by ignoring case when matching against disallowed field patterns. This has the added benefit 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.
These are the necessary conditions for the specific vulnerability:
@ModelAttributeor optionally without it, and without any other Spring Web annotation.
@RequestBodycontroller method parameters (e.g. JSON deserialization). However, such methods may still be vulnerable if they have another method parameter populated via data binding from query parameters.
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 manual.
If you're using disallowed field patterns and plan to continue 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 discussed in the new Model Design section in the reference manual, our recommended 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 recommended that you do not use types from your domain model such as JPA or Hibernate entities as the model object in data binding scenarios.