一个补丁打了三年，却仍被绕过；一个JSON请求，就能让服务器沦陷。Jackson-databind的CVE-2017-17485漏洞，堪称Java生态中最顽固的反序列化漏洞之一。今天咱们就来扒一扒这个漏洞的前世今生，以及为什么你绝不能只依赖升级补丁，而要用百度云防护WAF筑起最后一道防线。
一、 漏洞时间线：一个补丁都补不上的“洞中洞”
Jackson-databind是Java生态中最常用的JSON处理库，几乎无处不在——Spring Boot默认集成、各类微服务框架、大数据组件都在用它。
然而，这个明星库从2017年起就陷入了一场与黑名单的“猫鼠游戏”：
| 时间 | 事件 |
|---|---|
| 2017年9月 | CVE-2017-7525曝光：Jackson反序列化漏洞，允许攻击者通过构造恶意JSON执行任意代码。官方发布补丁，通过黑名单封禁了一批危险类。 |
| 2017年12月 | CVE-2017-17485被披露：研究人员发现，上一个补丁（CVE-2017-7525）的修复是不完整的。攻击者找到了绕过黑名单的新方法——利用Spring库中的类，再次实现远程代码执行。 |
| 2018年起 | 后续又曝出CVE-2018-7489、CVE-2019-12384等一系列绕过漏洞，黑名单机制被反复证明“治标不治本”。 |
一句话总结：CVE-2017-17485不是新漏洞，而是老漏洞（CVE-2017-7525）的“二次爆发” 。
二、 漏洞原理：为什么补丁没用？
2.1 Jackson的反序列化机制
Jackson允许开发者通过enableDefaultTyping()开启多态类型处理。这个功能本意是好的——当接口或抽象类需要反序列化为具体实现类时，Jackson会在JSON中嵌入类型信息（如@class字段）。
但问题来了：攻击者可以伪造这个类型字段，让Jackson实例化任意类。如果这个类的构造方法、setter方法或getter方法中存在危险操作（如执行命令、JNDI注入），攻击者就能实现远程代码执行 。
2.2 官方补丁为什么失败？
官方的修复方式是“黑名单”——维护一个列表，禁止反序列化那些已知的危险类。
但CVE-2017-17485的绕过方式如下：
- 利用Spring库中的类：Spring框架在Java项目中几乎标配。攻击者发现，如果
spring-beans库在类路径中，就可以利用其中的特定类绕过黑名单 。 - 触发JNDI注入：攻击者构造恶意JSON，指定
org.springframework.context.support.ClassPathXmlApplicationContext等类，远程加载恶意XML配置文件，触发JNDI注入，最终执行任意代码。
关键点：这个漏洞影响2.8.10及之前版本、2.9.x至2.9.3版本 。只要你用的Jackson-databind在这个范围内，且项目依赖了Spring库（绝大多数Java项目都是），无需任何认证，攻击者只需向你的API发送一个恶意JSON，就能拿下服务器权限。
2.3 CVSS评分：9.8（严重）
- 攻击向量：网络 —— 远程即可利用
- 攻击复杂度：低 —— 不需要特殊条件
- 所需权限：无 —— 完全未授权
- 影响范围：高 —— 机密性、完整性、可用性全失
三、 漏洞危害：从JSON到服务器沦陷，只需一个请求
| 危害类型 | 具体后果 |
|---|---|
| 服务器失陷 | 攻击者直接在服务器上执行任意系统命令，上传Webshell |
| 数据泄露 | 数据库被拖走，用户密码、业务数据、企业机密全部暴露 |
| 内网渗透 | 失陷服务器成为跳板，进一步攻击同内网的其他系统 |
| 挖矿木马 | 植入挖矿程序，服务器CPU飙升，业务卡顿 |
| 供应链攻击 | 如果你的服务被控，下游调用方也可能被连带攻击 |
真实场景：某金融科技公司的API网关因使用老版本Jackson，被攻击者扫描到漏洞后，通过一个POST请求植入了挖矿程序，导致核心交易系统连续三天响应缓慢，直接损失超百万元。
四、 如何自查：你的Jackson版本安全吗？
4.1 受影响版本
- 2.8.10 及之前版本（包括2.8全系列）
- 2.9.0 – 2.9.3
4.2 安全版本
- 2.8.11 及以上
- 2.9.4 及以上
4.3 自查命令
Maven项目（检查pom.xml）：
mvn dependency:tree | grep jackson-databindGradle项目：
gradle dependencies | grep jackson-databindLinux服务器（搜索jar包）：
find / -name "jackson-databind*.jar" 2>/dev/null | xargs ls -l五、 防御方案：别再只靠“升级+黑名单”了
5.1 方案一：升级到安全版本（必须做）
这是基础，但远远不够：
- 升级到 2.8.11 或 2.9.4 及以上
- Maven依赖配置示例：
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-databind</artifactId>
<version>2.9.4</version>
</dependency>5.2 方案二：禁用enableDefaultTyping（如果能接受）
如果业务允许，尽量不要开启多态类型处理。必须在代码层面严格限制可反序列化的类。
5.3 方案三：部署WAF，用虚拟补丁兜底（强烈推荐）
为什么不只靠升级？
因为Jackson的黑名单机制已经被证明“猫鼠游戏”永远玩不完——2017年至今，类似的绕过漏洞已出现十几个。今天你升了2.9.4，明天可能又曝出新的绕过方式。
最稳妥的做法：在应用前端部署Web应用防火墙（WAF），让WAF拦截恶意JSON请求，即使你来不及升级，攻击也进不了你的业务层。
六、 百度云防护WAF：内置CVE-2017-17485防护规则，开箱即用
从百度云防护的控制台截图可以看到，其内置规则库中有一条专门针对Jackson反序列化漏洞的规则：
| 规则名称 | 规则ID | 风险等级 | 防护类型 | 规则描述 | 更新时间 |
|---|---|---|---|---|---|
| CVE-2017-17485 | 3349 | 高风险 | 代码执行 | 由于 CVE-2017-7525 反序列化缺陷修复不完整，导致Jackson-databind远程代码执行漏洞 | 2019-02-21 |
6.1 规则如何工作？
百度安全团队基于对漏洞原理的深度分析，提取了攻击流量的核心特征：
- 检测JSON请求中恶意构造的
@class类型字段 - 识别企图加载Spring危险类（如
ClassPathXmlApplicationContext）的载荷 - 拦截JNDI注入攻击的特征字符串
当攻击者试图发送恶意JSON时，WAF会在请求到达服务器之前直接拦截，返回403状态码。攻击流量根本进不了你的业务层。
6.2 为什么站长首选百度云防护？
1. 958条内置规则，覆盖全量已知漏洞
除了Jackson漏洞，还涵盖OWASP TOP 10、各类CMS漏洞、框架漏洞等。
2. 虚拟补丁，无需重启
即使你暂时无法升级Jackson版本，WAF的规则也能提供即时防护，业务零中断。
3. 低误报，不影响正常业务
经过海量样本训练，正常JSON请求不受影响。
4. 套餐计费，用完即停，不怕欠费
被攻击时最怕什么？账单爆炸。百度云防护采用套餐制，用完即停，绝不产生天价后付费。
七、 快速接入指南：三步开启防护
- 登录百度云防护控制台，添加需要保护的域名。
- 确认内置规则已开启：进入【防护配置】→【Web防护】→【内置规则】，搜索“CVE-2017-17485”或规则ID 3349，确保状态为“开启”且动作为“拦截”。
- 验证效果：尝试用测试POC模拟攻击，查看是否被拦截。
八、 主机吧建议：别让一个JSON毁掉你的服务器
Jackson漏洞的“补丁-绕过”循环已经持续多年，事实证明单纯依赖代码修复是防不住的。攻击者每天都在用自动化工具全网扫描，发现漏洞就自动植入后门。
对于站长来说，最省心、最有效的做法，就是部署专业的WAF产品。百度云防护WAF内置的CVE-2017-17485漏洞规则，让你无需修改代码、无需担忧黑名单绕过，就能获得即时防护。
如果你还不确定自己的项目是否存在Jackson漏洞，或者想为服务器加上一道可靠的防线，欢迎联系主机吧。我们提供免费安全评估和配置指导，帮你把这个“猫鼠游戏”终结在WAF层面。
最后问一句：你的API接口，能扛住一个精心构造的JSON吗？
主机吧 | 百度云防护官方合作伙伴
提供WAF接入、高防CDN、高防IP、高防服务器、SSL证书一站式服务
让每一次攻击都无功而返，让每一台服务器都固若金汤。
