2026-07-22 05:35:59 网络安全文章来源：ZONE.CI 全球网 0 阅读模式

文章总结： 本文详细分析了fastjson1.2.83RCE漏洞，指出该漏洞需要特定环境条件（safemode未开启、JDK8、SpringBootfatjar等）才能实现远程代码执行，并非所有应用都面临直接风险。作者建议认真处置但不必恐慌，优先启用safemode和限制出站作为缓解措施，并给出了威胁检索和产品检测的具体建议。 综合评分： 95 文章分类： 漏洞分析,威胁情报,安全建设,应急响应,安全工具

cover_image

关于 Fastjson 1.2.83 RCE 漏洞，看这一篇就够了，包含漏洞细节与影响面分析！

信安之路

2026年7月21日 09:42 山西

在小说阅读器读本章

去阅读

编者荐语：

这篇总结了多个漏洞情报源，关于这个漏洞，看着一篇就够了，信安之路官网 www.xazlsec.com，服务包含自主学习平台、安全知识库、SRC资产库以及POC漏洞库

以下文章来源于MessFreeSecurity ，作者messfree

MessFreeSecurity .

提供社区优质咨询服务

核心判断：公开样本具有可检索的结构特征，但单条命中只适合作为调查线索。请求侧检索要把入站特征、出站连接和 Java 主机行为串起来，SafeMode 与出站控制继续作为 P0。

信息截点：2026 年 7 月 21 日 07:20（北京时间）这次把作者回复、腾讯云通告、长亭与微步复现、GitHub 公开仓以及本地对照放在一起看。信息比前一天多了，但完整利用的环境限制也更清楚了。

先说结论：这件事值得尽快排查，但目前公开的完整 RCE 并不是“只要用了 Fastjson 1.2.83，就能在任意 Java 环境下一次请求直接拿下”。

现阶段证据最充分的远程利用组合，集中在 Fastjson 1.x、SafeMode 未开启、JDK 8、经典 Spring Boot 可执行 FatJar Loader、不可信 JSON 解析入口，以及目标能够访问攻击者可控 HTTP 资源。少一个条件，结果就可能从完整代码执行退化为出站请求、解析异常，或者完全走不到远程加载。

长亭最新截图进一步说明，厂商已经在受控容器中跑出了命令执行；但截图对关键技术细节做了打码，没有展示资源协议、ClassLoader、SafeMode 状态和网络请求。它能确认“特定 JDK 8 容器环境中复现成功”，还不足以直接确认长亭采用的就是 GitHub 上流传的 jar:http链。

因此，当前比较合适的态度是：认真处置，不必把所有 Fastjson 应用都按已失陷看待。先筛选真正踩中利用条件的服务，再把 SafeMode 和限制出站作为 P0 缓解同步落地。

作者究竟确认了哪些内容

Kirill Firsov 最初公开的信息并不复杂：Fastjson 1.2.83 存在其所称的 gadget-free RCE，不依赖传统 classpath gadget，一次 payload 可以进入代码执行。

他随后在原帖讨论串中补充了三点：

影响范围确认到 1.2.68—1.2.83；
Fastjson 1.x 仓库已经归档，不会再出现 1.x 修复版本，建议启用 SafeMode 或迁移 Fastjson2；
完整技术文章会在受影响方获得修复时间后发布。

图：原帖及作者本人在讨论串中的三条补充。版本范围、无传统 gadget、1.x 无补丁和披露节奏均可直接核对。来源：X。

之后，Firsov 又确认了一个更贴近业务的场景：JSON.parseObject(body, Dto.class)中，攻击者只控制请求 body，也在其风险描述范围内。仅靠绑定 DTO 不足以完成缓解。

图：顶部为作者关于 typed parseObject 的补充，底部为评论者追问。DTO 是否必须为业务自定义类，公开讨论中仍没有进一步答案。来源：X。

到目前为止，作者仍未公开完整根因、Payload 结构、JDK 与 ClassLoader 矩阵，也没有给这次事件绑定正式 CVE。社区公开链与作者私有链是否完全相同，仍要等 write-up。

厂商已经开始复现，但公开口径并不完全相同

腾讯云已经发布正式风险通告，影响范围写为 1.2.68—1.2.83，并将“未启用 SafeMode”列为受影响前提。修复方向仍是迁移 Fastjson2，或在 1.x 中启用 SafeMode。

图：腾讯云通告中的影响版本、SafeMode 前提与处置建议。来源：腾讯云公告。

这份通告说明厂商已经按高风险事件推动处置，但没有公开 JDK、ClassLoader、资源协议和网络前提。它属于风险通告，不是完整技术报告。

长亭截图确认了什么

长亭新增的复现截图比单纯通告多了一层证据。画面中可以直接看到：

通过 reproduce.sh组织整个复现流程；
使用 JDK 8，画面显示的版本为 1.8.0_451；
先构建“受害 jar”，再构建并启动受害容器；
随后编译攻击端 Exp，发送 payload；
最终在受害容器内执行了命令，输出 uid=0(root)和 RCE-OK。

图：长亭复现流程截图。关键 Payload、构建内容和执行细节已经打码。截图由读者提供。

这里有一个容易被误读的地方：截图中的 uid=0(root)表示受害容器里的 Java 进程本来以 root 身份运行，命令继承了该进程权限。它证明容器内代码执行成立，但不代表利用过程额外完成了一次从普通用户到 root 的提权。

从流程上看，长亭大概率搭建了一个隔离的“受害应用 + 攻击端”环境：脚本先生成带 Fastjson 的受害 JAR，放入 JDK 8 容器启动；再编译攻击端程序或恶意类，向受害解析入口发送构造数据；最后进入容器核对命令输出。这个推测与截图中的五步流程吻合。

不过，截图没有露出以下关键信息：

受害 JAR 是否为 Spring Boot 经典 FatJar；
实际 ClassLoader 是否为 LaunchedURLClassLoader；
使用的是本地 jar:file，还是远程 jar:http；
是否存在攻击端 HTTP 服务及受害端出站请求；
AutoType 和 SafeMode 的实际状态；
利用链是否与 Firsov 私下披露的版本一致。

所以，这张图最稳妥的解读是：长亭在 JDK 8 受控容器中完成了 Fastjson 相关 RCE 复现；具体走的是哪条资源加载路径，公开截图尚未给出证据。

长亭对 SafeMode 的表述怎么理解

长亭的缓解建议写的是：在 1.2.68 及之后版本中开启 SafeMode，“完全禁用 AutoType 功能，从根本上杜绝此类风险”。

图：长亭材料中的 SafeMode 建议。截图由读者提供。

“SafeMode 打开后完全禁用 autoType”与 Fastjson 官方 Wiki 的字面表述一致，但它和普通的 autoTypeSupport=false不是一回事。社区公开链和本地对照都显示，AutoType 默认关闭时，JsonType 资源探测路径仍可能被触达；SafeMode 则会在当前公开解析链上更早抛出异常。

同时，Fastjson 1.2.83 源码中，已注册的 AutoTypeCheckHandler位于 SafeMode 判断之前；官方 Wiki 也保留了 SafeMode 场景下通过 Handler 接管 AutoType 的扩展方式。更严谨的落地方式是：启用 SafeMode，并检查项目是否注册过自定义 AutoTypeCheckHandler，再用生产实际 ParserConfig 做验证。

微步复现的是另一种资源条件

微步公开截图写得比较谨慎：当时使用 jar:filePoC 完成复现；网传 jar:http远程加载暂未复现成功，仍在继续研究。

图：微步区分了本地 jar:file和远程 jar:http的复现状态。截图由读者提供。

这与长亭截图并不冲突。长亭证明特定环境存在代码执行，微步公开了自己当时打通的 jar:file路径；两家公开材料都没有把远程 jar:http的完整环境矩阵展开。

GitHub 公开仓补上了远程加载路径

GitHub 上目前传播较多的几份仓，主线基本一致：Fastjson 在 ParserConfig.checkAutoType中进行 @JSONType资源探测，特定 ClassLoader 会把构造后的资源名按 JAR URL 解析。在 JDK 8 和经典 Spring Boot Loader 等条件下，远程内容可能进一步进入类定义与初始化。

截至本次截点，可检索仓库的关注度大致如下：

| 仓库 | Stars | Forks | 公开内容 | | — | — | — | — | | ThanatosXingYu/2026FastjsonPoC | 16 | 8 | 本地 harness，对比普通 AppClassLoader 与经典 Boot Loader | | dinosn/fastjson-jsontype-rce-lab | 5 | 3 | Docker 靶场、机制说明和扫描工具 | | 0x7eTeam/fastjson-1.2.83-rce | 1 | 0 | 测试环境、脚本和利用条件说明 | | wouijvziqy/Fastjson-JsonType-RCE-PoC | 当前公开内容未取得 | — | 被多份后续仓作为上游思路引用 |

这些仓之间有明显的引用关系。仓库数量增加，更像同一条上游思路被整理成不同的 harness、Docker 环境和工具，而不是多条互相独立的新链。Star 与 Fork 也只代表关注度，不代表独立验证数量。

用户提供的本机日志则补了一组对照：普通 AppClassLoader 下没有发起 HTTP 请求；JDK 8 + Spring Boot 2.7 LaunchedURLClassLoader下出现远程资源请求、类初始化和标记文件；SafeMode 开启后，Fastjson 解析抛出异常，标记文件没有生成。

这组日志与 GitHub 公开仓描述相符。SafeMode 对照中出现的部分请求来自 harness 自己执行的 warmup getResource，发生在 Fastjson 解析之前，不应计入 SafeMode 下的解析行为。

为什么说限制很多，但仍值得处理

当前公开的远程 jar:http完整链，需要多个条件同时成立：

这些条件说明，现阶段更接近“高危但有明确环境边界”，而不是所有 Fastjson 1.2.83 应用普遍处于随时被一条请求拿下的状态。

Spring Boot Loader 也需要说清楚：对 Spring Boot 1.x / 2.x 可执行 FatJar，以 java -jar启动时，经典 Boot Loader 属于默认启动机制；对 IDE 运行、普通 java -cp、外置 Tomcat WAR 或新版 Spring Boot Loader，公开链的结论需要分别验证。

Spring Boot 3.2 已经重写嵌套 JAR Loader，类名和 URL 处理都发生了变化。把 Boot 1.x / 2.x 的复现结果直接套到所有现代 Spring Boot 应用上，会放大实际影响面。

常规安全产品能覆盖到什么程度

公开样本留下了一些可被识别的组合特征，WAF、API 网关、网络检测和主机防护都有机会发现。腾讯云通告已经写明其 WAF 支持防护；长亭材料也建议在 URL 参数和请求体中检查 @type。不过，样例字符串可以调整，产品部署位置、规则版本和请求体解析能力也有差异，因此更合适的说法是“具备检测条件”，而不是默认现有设备已经覆盖全部变体。

不同产品看到的是利用过程中的不同位置：

对当前公开样本来说，只有当解析出的 JSON 键确实是 @type，而且它对应的值里同时出现 jar:与 JAR 资源分隔符 !，才适合作为优先核查线索。即使命中，也先表述为“疑似构造请求”；是否发生远程获取和代码执行，还要继续看出站与主机行为。整数形式主机、异常点号和非常用端口更适合作为辅助加权条件。单独出现 @type的范围较大，部分历史业务可能使用 SerializerFeature.WriteClassName，直接据此判定攻击容易带来误报。

影响检出率的主要是规范化过程。攻击字符串可能位于多层 JSON、字符串字段、URL 参数或经过编码的请求体中；如果设备只检查 URI，或者只对原始字节做关键词匹配，覆盖面会打折。更可靠的规则应先完成解压、JSON 解析和常见转义还原，再对键名和值做组合判断。

所以，安全团队需要向产品侧确认的不是一句“有没有 Fastjson 规则”，而是下面这些具体问题：

规则编号、更新时间和适用版本是什么；
检查位置是否同时覆盖 URL 参数与请求体；
是否支持 JSON 嵌套、Unicode 转义、URL 编码和压缩 Body；
命中后是告警、阻断还是仅记录；
TLS 解密、反向代理和容器东西向流量是否处于规则覆盖路径；
命中日志是否保留原始请求、规范化结果、源 IP、URI、响应码和规则 ID。

请求侧威胁检索怎么做

威胁检索可以从 7 月 19 日作者首次披露的时间点开始；日志条件允许时，再向前回溯 30 天。先覆盖公网入口和高风险服务，避免一开始对全部业务请求体做大范围长期留存。

先把网文样例当作结构线索

网文给出的示例，把 @type的值写成了由 jar:、http、整数形式主机、端口、点号和 !组合起来的字符串。这条样例有参考价值，但整串字面量不适合作为固定 IOC：IP、端口、资源名、大小写、空白、编码方式和 JSON 嵌套位置都可以变化，而且目前也没有证据证明它与 Firsov 尚未公开的完整链完全一致。

因此，检索时不必盯住示例中的某个十进制数字、端口或文件名，也不宜把所有 @type请求直接算作攻击。更稳妥的办法是先识别结构，再逐步关联上下文：

JSON 中存在名为 @type的键 → 检查该键对应的值是否具有 JAR URL / 资源引用结构 → 再关联同一服务的出站请求与 Java 进程行为。

先确认有没有请求体数据

很多 Nginx 和普通访问日志默认只记录方法、URI、状态码，不保存 POST Body。可优先检查：

WAF 或 API 网关安全事件；
网关请求采样、审计日志和攻击日志；
应用异常日志中的原始输入或 Fastjson 异常信息；
APM、RASP、服务网格和反向代理记录；
出口代理、DNS、NDR 与 EDR 数据。

如果历史日志没有请求体，仍可从出站连接和主机行为反向寻找线索。后续临时增加 Body 审计时，建议只覆盖涉及 Fastjson 的高风险接口，并对口令、Token、个人信息等字段做脱敏和短周期留存。

请求特征分级检索

优先使用设备已经解压、解码并完成 JSON 解析的规范化字段，同时保留原始请求用于复核。嵌套 JSON、字符串内嵌 JSON、Unicode 转义和 URL 编码应分别处理，避免仅在原始字节上匹配一个固定字符串。

各类日志平台的查询语法不同，核心方法一致。具备 JSON 字段提取能力时，优先按键值关系查询：

TYPE_VALUE = 规范化请求体中，键名正好等于 "@type" 的字段值REQUEST_SIGNAL = &nbsp; &nbsp;TYPE_VALUE 包含（忽略大小写）"jar:" &nbsp; &nbsp;AND TYPE_VALUE 包含 "!"

平台暂时只支持全文检索时，可退一步查同一条请求中的组合特征，但结果需要回看原文，确认这些字符串确实位于同一个 @type字段值中：

规范化请求体包含 "@type"AND 规范化请求体包含 "jar:"AND 规范化请求体包含 "!"

全文组合检索的精度低于键值查询，因为三个片段可能分散在不同字段。对于只有原始日志的环境，可补充检索 \\u0040type等转义形态；同时记录使用了哪一层解码结果，避免重复解码造成误判。建议保留时间、源地址、目标服务、URI、方法、内容类型、请求标识、响应码、处置动作、原始请求和规范化请求等字段，方便后续关联。

把入站、出站和主机行为串起来

单条请求命中只能说明有人尝试。更有价值的是按服务实例和时间窗口做三段关联：

实际检索时，可将入站命中与前后两分钟的 DNS、出口代理、网络连接和 EDR 事件关联。重点关注：

Java 服务直连陌生 IP 或非常用端口；
没有 DNS 查询却直接访问整数或裸 IP；
HTTP 请求路径像普通资源名，未必带 .jar后缀；
java

进程派生 sh、bash、cmd.exe、powershell等子进程；
容器临时目录、应用目录出现来源不明的 JAR、class 或标记文件；
Fastjson 日志出现 autoType is not support、safeMode not support autoType、ClassFormatError等异常，并与外部请求时间接近。

检索结果最好按“请求尝试、发生出站、疑似执行”分级，不要把单个关键词命中直接写成服务器已经被执行代码。这样既保留敏感度，也能控制告警焦虑。

限制出站能卡住远程链

对目前公开的 jar:http链，限制出站是非常直接的缓解。它的过程可以简化为：

不可信 JSON → 资源探测 → 目标发起 HTTP 请求 → 获取远程 JAR → 类定义与初始化。

远程内容取不到，后续类定义就失去输入。因此，严格限制 Java 进程、容器或 Pod 的任意 HTTP 出站，会把当前公开远程链卡在资源获取阶段。

这里需要区分三种情况：

GitHub 公开的 jar:http路径依赖 HTTP 可达，出站控制直接有效；
微步复现的 jar:file使用本地资源，不走外部 HTTP，但还需要本地文件条件；
Firsov 尚未披露的完整链是否有同样网络前提，等 write-up 后再判断。

出站控制要落到真实数据路径，而不只是写在制度里：

应用默认拒绝任意外连，只开放明确业务目的地址；
外部 HTTP / HTTPS 统一经过出口代理或网关，限制应用直连公网 IP；
允许列表同时约束域名、解析后的 IP、端口和协议；
检查服务网格、透明代理、NAT、宿主机路由和云安全组是否真正覆盖；
内网、测试网和合作方地址也要纳入核对，只要存在攻击者可控且目标可达的 HTTP 资源，远程获取条件仍然成立；
记录被拒绝的 DNS 与 HTTP 连接，关注 Java 服务访问整数形式 IP、非常用端口和陌生资源地址。

对当前公开链来说，SafeMode 和限制出站正好卡在两个不同位置：SafeMode 卡解析路径，出站策略卡远程资源获取。两项并行落地，比单独依赖 WAF 特征或 JDK 版本更稳。

排查顺序可以更务实

不需要把所有 Java 系统同时拉到最高级别。先找同时满足多个条件的服务：

Fastjson 1.2.68—1.2.83；社区观察范围可额外覆盖 1.2.66—1.2.67；
存在 HTTP body、Webhook、MQ、文件导入或第三方回调等外部 JSON 入口；
使用 JDK 8；
生产制品是经典 Spring Boot 可执行 FatJar，并通过 java -jar启动；
SafeMode 尚未在实际 ParserConfig 中生效；
应用可直接或经代理访问任意外部 HTTP 地址。

同时满足以上条件的服务优先级最高。处置可以按下面的顺序推进：

| 优先级 | 动作 | 目的 | | — | — | — | | P0 | 验证 SafeMode 实际生效，并检查自定义 AutoTypeCheckHandler | 阻断当前公开解析路径 | | P0 | 将应用出站改为默认拒绝，只保留明确业务允许列表 | 截断远程 JAR 获取与 SSRF 路径 | | P0 | 在 WAF、网关和 SIEM 中上线组合检测，并回溯历史请求 | 发现已发生的探测、攻击尝试和可能的远程获取 | | P1 | 收敛外部 JSON 入口，增加网关与日志监控 | 减少可触达面并补充发现能力 | | P1 | 升级 JDK 并验证部署方式 | 降低当前公开链进入完整 RCE 的概率 | | 中长期 | 迁移 Fastjson2 | 结束 Fastjson 1.x 的持续处置成本 |

WAF 对 @type、jar:、整数 IP 等特征的识别可以作为临时补强，但它更适合争取处置时间。真正有确定性的两项控制，仍是 SafeMode 和限制出站。

处置成本要提前说清楚

限制多，不等于处置没有成本。真正耗时的通常是回归和跨团队协调：

| 工作项 | 单体或低复杂度服务 | 中高复杂度服务 | 主要成本来源 | | — | — | — | — | | 依赖、入口、打包方式和 JDK 盘点 | 0.5—1 人日 | 2—5 人日 | 传递依赖、公共组件、离线制品、多套环境 | | SafeMode 启用与回归 | 0.5—2 人日 | 3—10 人日 | 历史 @type数据、多态模型、MQ 与回调兼容 | | 出站网络收敛 | 0.5—2 人日 | 3—10 人日 | 代理、域名允许列表、合作方接口、发布窗口 | | Fastjson2 迁移 | 2—5 人日 | 1—8 人周或更长 | API 差异、序列化行为、全链路回归和灰度发布 |

比较现实的节奏是：先在 24 小时内完成高风险组合筛选、SafeMode 核验和高风险服务出站收敛；随后完善允许列表和监控，再按业务域推进 Fastjson2 迁移。

最后怎么看这件事

目前可以确认的是：作者维持高风险声明，腾讯云已发正式通告，长亭在 JDK 8 受控容器中展示了 RCE 成功，微步公开确认了 jar:file复现，GitHub 与本机对照则给出了特定环境下的 jar:http远程加载路径。常规安全产品对明显请求和后续行为有较好的发现机会，但覆盖效果要以规则版本、流量位置和实际命中验证为准。

这些证据足以支持企业尽快排查和缓解，但也说明公开完整利用受到较多环境条件约束。把它描述成“所有 Fastjson 1.2.83 默认环境都能直接 RCE”并不准确；把它当成普通传言继续观望，同样不合适。

更平衡的判断是：高危、需要行动，但当前公开远程链的暴露面可通过条件筛选快速收窄。SafeMode 与限制出站先落地，迁移 Fastjson2 作为长期收口。

接下来真正影响风险判断的，是 Firsov 完整 write-up、正式 CVE 或项目方通告，以及是否出现摆脱 JDK 8、经典 Boot Loader 或 HTTP 出站条件的新链。

参考来源

Kirill Firsov 原始预警及同串补充
Kirill Firsov 关于 DTO 绑定的补充
腾讯云 Fastjson 远程代码执行漏洞风险通告
ThanatosXingYu/2026FastjsonPoC
dinosn/fastjson-jsontype-rce-lab
0x7eTeam/fastjson-1.2.83-rce
后续仓引用的 wouijvziqy/Fastjson-JsonType-RCE-PoC
Spring Boot 官方：Launching Executable Jars
Spring Boot 2.7.18：LaunchedURLClassLoader 源码
Spring Boot 3.2 Release Notes：Nested Jar 实现重写
Fastjson SafeMode 官方 Wiki
Fastjson 1.2.83 ParserConfig 源码
Fastjson2 GitHub 仓库

免责声明：

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

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

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

本文转载自：信安之路《关于 Fastjson 1.2.83 RCE 漏洞，看这一篇就够了，包含漏洞细节与影响面分析！》