How to Patch the Spring RCE Vulnerability in Legacy Versions Without Upgrading

After Spring announced a widely reported RCE vulnerability, the official fix is to upgrade, but only Spring 5.2, 5.3 and Spring Boot 2.5, 2.6 provide upgrade paths. Users on older versions such as Spring 5.0, 5.1, 4.x, Spring Boot 1.x, or 2.4 and below need alternative solutions.

First method

The official solution involves extending RequestMappingHandlerAdapter. Below is a Spring Boot example using Spring MVC; for WebFlux minor changes are needed, and non‑Boot projects must adjust bean initialization.

@SpringBootApplication
public class MyApp {
    public static void main(String[] args) {
        SpringApplication.run(MyApp.class, args);
    }

    @Bean
    public WebMvcRegistrations mvcRegistrations() {
        return new WebMvcRegistrations() {
            @Override
            public RequestMappingHandlerAdapter getRequestMappingHandlerAdapter() {
                return new ExtendedRequestMappingHandlerAdapter();
            }
        };
    }

    private static class ExtendedRequestMappingHandlerAdapter extends RequestMappingHandlerAdapter {
        @Override
        protected InitBinderDataBinderFactory createDataBinderFactory(List<InvocableHandlerMethod> methods) {
            return new ServletRequestDataBinderFactory(methods, getWebBindingInitializer()) {
                @Override
                protected ServletRequestDataBinder createBinderInstance(Object target, String name, NativeWebRequest request) throws Exception {
                    ServletRequestDataBinder binder = super.createBinderInstance(target, name, request);
                    String[] fields = binder.getDisallowedFields();
                    List<String> fieldList = new ArrayList<>(fields != null ? Arrays.asList(fields) : Collections.emptyList());
                    fieldList.addAll(Arrays.asList("class.*", "Class.*", "*.class.*", "*.Class.*"));
                    binder.setDisallowedFields(fieldList.toArray(new String[] {}));
                    return binder;
                }
            };
        }
    }
}

This approach requires code changes and a solid understanding of Spring internals, which may be cumbersome for many developers.

Second method

The second approach mitigates the vulnerability by altering one of its exploitation conditions.

JDK 9+

Deploy with Apache Tomcat

Package as WAR

Depend on spring-webmvc or spring-webflux

By changing any of these, the attack can be blocked, for example downgrading to JDK 8, using Undertow instead of Tomcat, or packaging the application as a JAR rather than a WAR. Updating Tomcat to the latest version also mitigates the issue when using WAR deployment.

In summary, upgrading remains the preferred fix, but for legacy projects the above code‑level extension or condition‑based mitigation can provide a temporary solution.