3 ms·

I agree, it isn't as bad as Log4J if only for the fact that it's JDK 9+ specific. A lot of our deployments are still on Java 8. So even if they are vulnerable w

I agree, it isn't as bad as Log4J if only for the fact that it's JDK 9+ specific. A lot of our deployments are still on Java 8. So even if they are vulnerable we're sort of protected by being slow. Since a typical Spring application has a lot of dependencies I'm sure some 3rd party library somewhere could be susceptible. Embedded Tomcat which is pretty common might have an exploit we can't imagine at this moment.

0x500x79 5y ago
This is true, but seems unlikely from my analysis this far. The class loader behavior is vastly different and attempting to access classes is failing to write fields (getting the default: Field is not accessible when attempting to write bean) on all payloads that I have been trying. I have stopped my research for now because of the limited scope so I am not spending more time debugging the exact differences in the class loaders in use here, because the configuration required for the exploit to work makes 99.9% of my use cases just plain not work as it is default web form marshalling which we do not do. We of course are updating: You should update too, it's good hygiene, but the fact of the matter is this is no where close to the same blast radius for the reason that it requires such a bad configuration to start with and doesn't affect non-public services like log4shell had the possibility to do.