I have done quite a bit of research on this vulnerability in the last day and it is no where near the level of log4shell even though it keeps getting compared to it.<p>The problem in spring is the WebDataBinder able to manipulate objects through the class loader. This affects Java 9+ because the previous mitigation of the class loader access is insufficient with the introduction of Java modules. The exploit utilizes a path from the current class to the module to the classloader, where previous mitigations removed access to the classloader from the class directly AFAICT.<p>The reasoning that this isn't THAT bad: this only affects the WebDataBinder marshalling which happens for default web form POST content types. Utilizing the commonly used @RequestBody annotation (for proper marshalling from JSON/XML) is not impacted. Utilizing the @RequestBody annotation causes marshalling to use the HTTPMessageConverter which is not affected.<p>On top of this the deployment matters. Different servlet containers use different class loaders/expose different class loaders. Currently, I have not seen an exploit for this in embedded tomcat (my debugging of this code path will not inject in code, presumably because the URLClassLoader is different than the class loader provided in the standalone tomcat deployment). I have not investigated whether this is because of security checks or some other functionality.<p>So very specifically:
1. You have to be using the WebDataBinder (not default for JSON serialized endpoints)
2. The servlet container matters (embedded Tomcat)
3. The endpoints have to be known or spidered<p>Overall, I believe this vulnerability has been quite overhyped right now.