📌 核心观点

本文要点： Log4j2 Issue #4255是一个技术上真实存在的安全问题，但与2021年的Log4Shell有本质区别，实际影响范围极其有限，不应引发过度恐慌。

一、问题概述

1.1 事件背景

2026年8月24日，Apache Log4j2项目公开了Issue #4255，涉及FilteredObjectInputStream反序列化白名单绕过问题。随后多个安全研究团队发布了概念验证代码（PoC），部分媒体将其解读为"Log4j再次出现严重远程代码执行漏洞"。

然而，经过技术分析和影响范围评估，该问题与2021年震惊业界的Log4Shell漏洞（CVE-2021-44228）存在本质差异。

1.2 问题定性

技术层面： 该问题确实存在，攻击链路在特定条件下可被成功利用。

影响范围： 仅影响极少数特殊配置场景的Log4j2应用。

官方态度： Apache官方未分配CVE编号，未发布安全公告，根据其Security FAQ定义，该问题可能被归类为"应用层配置问题"而非"产品漏洞"。

三、技术原理解析

3.1 问题成因

Log4j2提供了FilteredObjectInputStream（FOIS）作为反序列化安全工具，通过白名单机制限制可反序列化的类。问题的根源在于：

1. 1. 白名单配置缺陷：FOIS的白名单中包含了java.rmi.MarshalledObject类

2. 2. 二次反序列化问题：MarshalledObject.get()方法会创建新的、不带过滤器的ObjectInputStream

3. 3. 白名单绕过：恶意payload隐藏在MarshalledObject内部，成功绕过外层白名单检查

3.2 攻击链路

1. 攻击者构造恶意的LogEvent对象
2. 将Message包装在MarshalledObject中
3. 通过网络发送到目标的日志接收端
4. FilteredObjectInputStream检查：MarshalledObject在白名单 → 放行
5. LogEventProxy调用MarshalledObject.get()
6. 内部创建无过滤的ObjectInputStream
7. 反序列化恶意gadget（如Commons Collections）
8. 触发代码执行

3.3 与Log4Shell的本质差异

关键区别： Log4Shell是"被动触发型"漏洞，Issue #4255是"主动暴露型"风险。

四、影响范围分析

4.1 利用条件

该问题的成功利用需要同时满足以下所有条件：

条件一：存在序列化日志接收端

应用必须主动监听网络端口，通过Java ObjectInputStream接收并反序列化LogEvent对象。

受影响场景：

• • 运行TcpSocketServer（Log4j 2.14.x及更早版本）

• • 自研的Java序列化日志收集网关

• • 使用SerializedLayout配置的网络日志接收端

条件二：接收端对不可信网络开放

日志接收端口必须能被潜在攻击者访问。

高风险配置：

• • 监听公网IP地址

• • 内网无访问控制策略

• • 缺少身份认证机制

条件三：存在可利用的gadget库（RCE必要）

要实现远程代码执行，Classpath上必须存在可被利用的反序列化gadget库。

可导致RCE：

• • Commons Collections 3.2.1及更早版本

• • 其他存在已知gadget的库

五、排查方法指南

5.1 代码与配置检查

关键配置项：

# 搜索可疑配置
find . -type f \( -name "*.xml" -o -name "*.properties" -o -name "*.yaml" \) \
  -exec grep -l "SerializedLayout\|TcpSocketServer" {} \;
# 搜索Java代码find . -name "*.java" -exec grep -l "ObjectInputStreamLogEventBridge" {} \;

判断标准：

• • 未发现上述配置 → 不受影响

• • 发现相关配置 → 需进一步确认

5.2 运行时检查

检查加载的类：

# 列出Java进程
jps -l
# 检查特定进程加载的类jcmd <pid> GC.class_histogram | grep -E "TcpSocketServer|SerializedLayout"

检查监听端口：

# 查看Java进程监听的端口
ss -tlnp | grep java
netstat -tlnp | grep java
# 重点关注非标准端口（非8080、9090等常见端口）

5.3 依赖库检查

# Maven项目
mvn dependency:tree | grep commons-collections
# Gradle项目gradle dependencies | grep commons-collections
# 直接查找jar包find . -name "commons-collections-3.2.1.jar"

5.4 快速判断流程

步骤1：是否使用Log4j2？
       ├─ 否 → 不受影响 ✓
       └─ 是 → 继续
步骤2：是否存在序列化日志接收端？
       ├─ 否 → 不受影响 ✓
       ├─ 不确定 → 执行技术检查
       └─ 是 → 继续
步骤3：接收端是否对外开放？
       ├─ 仅localhost → 风险较低
       ├─ 内网+白名单 → 风险中等
       └─ 公网/无限制 → 继续
步骤4：是否为必要功能？
       ├─ 否 → 建议关闭
       └─ 是 → 立即加固

六、防护加固方案

6.1 方案一：关闭序列化日志接收端

适用场景： 该功能非业务必需

操作方法：

• • 删除相关配置

• • 停止相关服务进程

• • 从部署架构中移除该组件

效果评估： 完全消除风险

6.2 方案二：JVM序列化过滤器

适用场景： 必须保留序列化日志功能

配置方法：

# 添加JVM启动参数
-Djdk.serialFilter='!java.rmi.MarshalledObject'
# 更严格的策略（推荐）-Djdk.serialFilter='!org.apache.commons.collections.*;!java.rmi.MarshalledObject'

实施位置：

• • 应用启动脚本

• • 系统服务配置文件

• • 容器环境变量

效果评估： 大幅降低风险，可能影响合法MarshalledObject使用

6.3 方案三：网络层隔离

适用场景： 所有保留接收端的情况

加固措施：

• • 修改监听地址为127.0.0.1或内网IP

• • 配置防火墙规则，限制访问来源

• • 部署网络隔离方案（VPN、专网）

• • 启用mTLS双向认证

效果评估： 显著降低攻击面

七、总结与建议

7.1 核心结论

1. 1. 技术真实性：Issue #4255是一个真实存在的技术问题

2. 2. 影响范围：实际影响范围极其有限

3. 3. 严重程度：不应与Log4Shell相提并论

4. 4. 应对策略：针对性排查，避免过度反应

7.2 关键要点

• • 不是所有Log4j2应用都受影响

• • 默认配置不存在风险

• • 排查可以快速完成

• • 加固措施简单有效

• • 不需要全面应急响应