It's not really a fix, but a way to mitigate the exploitation. Your application can still have other usable classes that can be used.

No, the real risk with Java is that objects could be created arbitrarily with serialization and deserialization. This means if you can inject a crafted serialized object into the program's input, you could create any object and anything in that object's constructor or destructor or whatever would run. It just wasn't safe, it was a bad idea to have or use publicly such a flexible method to serialize and deserialize objects.

With Rust and Serde, you have a much more strict, defined deserialization process. If you have a struct with a few fields and you want to deserialize that from JSON, that's all that's going to be deserialized. Arbitrary objects cannot be created in the same way. It's not vulnerable to the class of vulnerabilities discussed in the article above.

https://medium.com/@cowtowncoder/on-jackson-cves-dont-panic-here-is-what-you-need-to-know-54cd0d6e8062 is really integral here (and the authors do link it!).

Jackson with enableDefaultTyping can never be secure - the attack surface is simply too large. We had this very same problem with normal java serialization. You should never deserialize untrusted data with default typing enabled (and contrary to the name, it is not actually enabled by default).

If you know this, the recent Jackson RCEs are completely irrelevant to you. This actually makes the hundreds of mails I receive from github about the "next best" jackson CVE in my github projects really annoying, because they're never actually exploitable if you don't do dumb shit.