FWIW, from our perspective (and not just ours), the only proper fix is to not expose such endpoints to untrusted clients to begin with. Any other data representation - XML, JSON, custom data formats - is a way better choice for untrusted clients. Blacklisting of classes for serialization endpoints is never going to be a complete solution, and whitelisting is going to be a lot of pain to maintain. Other data formats provide a way better tradeoff overall and are very worth a refactoring. If you have to keep using serialization on your system boundary, make sure that those endpoints are only accessible to trusted clients and that interaction with them is properly logged (and therefore traceable after misuse).
As for this particular issue here, it's solely about tightening our MethodInvokeTypeProvider implementation so that it cannot be misused in such a serialization exploit anymore. So it's one class tightened up now that's commonly found on application classpaths, and that's a step forward. It's just also pretty certain that other such classes remain that nobody is aware of, or rather that nobody disclosed yet. Once again, do not accept serialized Java classes from untrusted classes to begin with; it's the only safe way out.