Spring Framework Data Binding Rules Vulnerability (CVE-2022-22968)

Table of Contents

• Overview
• Does This Affect My Application?
• Reassessing Your Data Binding Approach

Overview

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.

• CVE-2022-22968: Spring Framework Data Binding Rules Vulnerability

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 spring-framework.version property.
>
> 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.

Does This Affect My Application?

These are the necessary conditions for the specific vulnerability:

• Registration of disallowed field patterns in a DataBinder
• spring-webmvc or spring-webflux dependency
• Spring Framework versions 5.3.0 to 5.3.18, 5.2.0 to 5.2.20, and older versions

Additional notes:

• 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 @ModelAttribute or optionally without it, and without any other Spring Web annotation.
• The issue does not relate to @RequestBody controller 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.
• 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 DataBinder configuration 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.

Reassessing Your Data Binding Approach

If you're using disallowed field patterns and plan to continue using them, you should definitely update to Spring Framework 5.3.19 and5.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 WebDataBinder.

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.