反序列化本身可能已经不安全了。可序列化的类可以定义一个readObject 方法（另请参见specification），当该类的对象将从流中反序列化时调用该方法。攻击者无法提供此代码，但使用精心设计的输入，她可以调用类路径上的任何此类readObject 方法，以及任何输入。
代码注入
可以创建一个readObject 实现，为任意字节码注入打开大门。只需从流中读取一个字节数组并将其传递给ClassLoader.defineClass 和ClassLoader.resolveClass()（参见the former 和the later 的javadoc）。我不知道这样的实现有什么用，但有可能。
内存耗尽
编写安全的readObject 方法很难。直到somewhat recently readObject 的方法 HashMap 包含以下行。
int numBuckets = s.readInt();
table = new Entry[numBuckets];
这使得攻击者可以很容易地用几十字节的序列化数据分配几千兆字节的内存，这将使您的系统立即崩溃并显示OutOfMemoryError。
Hashtable 的current implementation 似乎仍然容易受到类似攻击；它根据元素的数量和负载因子计算分配数组的大小，但没有针对loadFactor 中不合理的值的防范措施，因此我们可以轻松地请求为表中的每个元素分配十亿个槽.
CPU 负载过大
修复HashMap 中的漏洞是为了解决与基于哈希的映射相关的另一个安全问题的更改的一部分。 CVE-2012-2739 描述了一种基于 CPU 消耗的拒绝服务攻击，方法是创建一个带有很多冲突键（即具有相同哈希值的不同键）的 HashMap。记录的攻击基于 URL 中的查询参数或 HTTP POST 数据中的键，但 HashMap 的反序列化也容易受到这种攻击。
为防止此类攻击而放入HashMap 的safeguards 集中在带有String 键的地图上。这足以防止基于 HTTP 的攻击，但很容易通过反序列化来规避，例如通过用ArrayList 包装每个String（其hashCode 也是predictable）。 Java 8 包含一个提案 (JEP-180) 以进一步改进 HashMap 在面对许多冲突时的行为，它将保护扩展到实现 Comparable 的所有密钥类型，但仍然允许基于 @987654351 的攻击@键。
这样做的结果是，攻击者可以设计一个字节流，以便从该流中反序列化对象所需的 CPU 工作量随流的大小呈二次方增长。
总结
通过控制反序列化过程的输入，攻击者可以触发任何readObject反序列化方法的调用。这种方法理论上可以允许字节码注入。在实践中，这种方式当然很容易耗尽内存或 CPU 资源，从而导致拒绝服务攻击。针对此类漏洞审计您的系统非常困难：您必须检查readObject 的每个实现，包括第三方库和运行时库中的实现。