不是"核弹"。Log4j issue 4255 的FAQ

结论：技术链真实，但不是新的 Log4Shell，多数生产环境不受影响。

1. 风险只存在于「用 Java 序列化接收远程日志」的少数接收端，不是「装了 log4j 就会被打」。建议按「有无序列化日志接收端」排查，而不是全公司升级 log4j。

2. 是否为Log4j-core的漏洞仍存在争议，根据官方Security文档来看可能属于被拒接的那一类。

3. 微步威胁感知平台TDP对此issue相关的利用链支持检测。

2026 年 8 月 24 日，Apache Log4j2 公开 issue 4255。随后出现公开 PoC 和媒体表述「Log4j 又一次 RCE」。

本质是：Log4j 提供的反序列化白名单工具 FilteredObjectInputStream（FOIS）里放行了 java.rmi.MarshalledObject。Log4j 自己的 LogEvent 序列化格式会在还原时调用 MarshalledObject.get()，用一条没有白名单的流再解一次。于是外层白名单被绕过。

公开 PoC 在「自建接收端 + Commons Collections 等 gadget」条件下可以打成命令执行。链是成立的。

结论：不是「日志里出现恶意字符串就 RCE」，而是「有一个收 Java 序列化日志的服务，且对端不可信」。

1. 存在接收端：对 TCP/HTTP/消息队列做 Java readObject()，对象是 LogEvent（接收日志，而不是往外发日志）。

2. 对端不可信：公网或内网任意主机能连这个口（无来源限制、无 mTLS）。

3. 要打成 RCE：接收端 classpath 上还要有反序列化 gadget（如 Commons Collections 3.2.1）。没有 gadget 最多是拒绝服务或伪造日志。

多数业务不受影响，包括：只写文件/控制台、JSON/HTTP/Syslog 收日志、仅配置了 SocketAppender 往外发、普通 logger.info(用户输入)。

https://logging.apache.org/security/faq.html#deserialization

Log4cxx, Log4j, and Log4net donot deserialize data fromany source as part of their normal operation.
The hardening utilities we ship are partial andnot exhaustive; bypasses are treated as opportunities for further hardening, notas vulnerabilities inthe project.
The application performing the deserialization is responsible for ensuring that thebyte stream originates froma trusted source.

值得一提的是：

Log4j2-core 里曾带 TcpSocketServer.createSerializedSocketServer。

（参考CVE-2017-5645），大约 2.15 起已从生产库移除。当前 log4j-core不再监听端口、不再从网络反序列化。目前受影响场景主要是：

• 仍跑 ≤2.14.x 并显式启动了 TcpSocketServer 的老部署；

• 拷了官方 samples 或自研了「FOIS / ObjectInputStream 收 LogEvent」的网关。

互联网公开的POC（含 HTTP POST /log 打 RCE）都是专门搭的接收端，不是「凡用 log4j 2.x 的系统」都受影响。

要做： 找出有没有「序列化 LogEvent 接收端」。

1. 源代码排查：搜 SerializedLayout、TcpSocketServer、ObjectInputStreamLogEventBridge。注意：FilteredObjectInputStream 几乎每个 log4j-api 都有，单独命中不算。

2. 运行中 JVM：jps / jcmd GC.class_histogram 看是否加载了接收端类；ss 看 Java 是否对外 listen，再对白名单和安全组。

部分决策建议：

• 没有接收端：不受影响

• 只有发送端：去排查接收端是否受影响

• 加载了接收端且对非信任网络开放：能关则关，这属于是误用 Java 序列化传日志的部署风险。