8 月 24 日，Apache Log4j 仓库出现编号 #4255 的新 issue：一份声称 Log4j 2 存在 Java 反序列化绕过、可在特定应用条件下实现远程代码执行（RCE）的报告。任何把"Log4j"和"RCE"放在一起的词组都足以唤起 Log4Shell 的记忆——但这个故事很快变得比正常的漏洞披露离奇得多。

两天之内，issue 的原始描述消失了，标题被改成了莫名其妙的"Something wrong Happen"，issue 被关闭，报告者的账号变成了 GitHub 的幽灵占位符。报告是错的？严重性被夸大？还是研究者在和 Apache 讨论威胁模型后主动撤回？我们无从得知。但底层的技术行为并没有随报告一起消失。

Log4j 反序列化绕过

绕过是真实的，争议在于它意味着什么

#4255 的核心是 Log4j 的 FilteredObjectInputStream 与 java.rmi.MarshalledObject 相关的 Java 反序列化行为。Log4j 设计了白名单机制限制反序列化时可以重建哪些类，而 MarshalledObject 恰好在允许列表中。问题在于：MarshalledObject 内部可以再包含另一个序列化对象，调用 .get() 时，内嵌对象会在另一个没有继承过滤器的新 ObjectInputStream 上反序列化。简单说：外层容器通过了安全检查，藏在里面的对象却可以在检查之外被反序列化。

Elastic 安全实验室在官方 Maven Central 的 log4j 2.26.1 JAR 上复现了这一路径，但要到达命令执行还需要 Log4j 本身不提供的两个条件：一个仍在反序列化 Java 序列化 LogEvent 对象的进程，以及该 JVM 上已存在的 gadget 库。Apache 因此不把 FilteredObjectInputStream 视为安全边界——Log4j 在正常日志记录过程中不反序列化数据，此类绕过被归类为"加固机会"而非产品漏洞。截至目前，#4255 没有 CVE 编号。

AI 先找到了它

最值得注意的细节发生在 #4255 公开前近两个月。7 月 1 日，Apache Log4j 维护者 Piotr Karwasz 发布讨论帖，列出一个 LLM 审计 Log4j 代码库的发现清单——工具是 Claude Code，模型是拥有百万 token 上下文的 Claude Opus 4.8。提示词大意是：审计仓库中每个可序列化类，找出通过 Log4j 过滤机制可达的反序列化 gadget 面。排名第一的高优先级发现正是：Log4jLogEvent.LogEventProxy —— MarshalledObject.get() 在无过滤器状态下反序列化（白名单逃逸）。七周后，人类研究者独立到达同一区域并把它表述为 RCE。

AI 不是在查 CVE——当时没有 CVE 可查。它在阅读源码、追踪跨类的控制流、推理 Java 序列化的行为、识别安全控制失效的位置。这预示着漏洞研究的经济学正在改变：在公开源码中寻找漏洞的成本正在坍缩，攻击者同样享受这一红利。下一个利用可能在公告之前到来，在补丁之前到来，甚至永远不会有 CVE。

防御建议：盘点环境中所有反序列化 LogEvent 的进程（遗留 TcpSocketServer、SerializedLayout、自定义 FOIS 桥接），对仍在使用 Java 序列化日志流的系统考虑迁移到 JSON/Syslog，JDK 9+ 上安装 ObjectInputFilter，并假设 FOIS 本身不是安全边界。

本文编译自 Raven.io 与 Elastic Security Labs，原文地址：https://raven.io/blog/log4shell-2-0 与 https://www.elastic.co/security-labs/threat-command/java-deserialization-vulnerability-log4j-2