Deserializing untrusted data can cause Java to create an object of an arbitrary attacker-specified class, provided that the class is available on the classpath specified for the JVM. Some classes have triggers that execute additional code when they are created in this manner, ; see SER13-J. Treat data to be deserialized as potentially malicious by default for more information. If such classes are poorly designed, such code could even invoke arbitrary methods, such as Runtime.exec() with an attacker-supplied argument. Therefore, untrusted input to be deserialized should be validated to ensure that the serialized data contains only trusted classes, perhaps specified in a whitelist of trusted classes. This can be done by overloading the resolveClass() method of the java.io.ObjectInputStream class. As an alternative to validation of the serialized data, a java.lang.SecurityManager can be used to perform deserialization in a less-privileged context.
...
This compliant solution is based on http://www.ibm.com/developerworks/library/se-lookahead/ : . It inspects the class of any object being deserialized, before its readObject() method is invoked. The code consequently throws an InvalidClassException unless the object (and all sub-objects) is a GoodClass1 or a GoodClass2.
...
Whether a violation of this rule is exploitable depends on what classes are on the JVM's classpath. (Note that this is a property of the execution environment, not of the code being audited.) In the worst case, it could lead to remote execution of arbitrary code.
...