2026年了,核弹还是fastjson,fastjson1.2.83 RCE是怎么回事?

2026年了,核弹还是fastjson,fastjson1.2.83 RCE是怎么回事?

💡 原文中文,约7200字,阅读约需17分钟。
📝

内容提要

该文讨论fastjson 1.2.83版本被曝出的RCE漏洞。漏洞利用Spring Boot FatJar的LaunchedURLClassLoader,通过构造特殊类名远程加载带@JSONType注解的恶意类,绕过autoType限制。但利用条件苛刻,需特定环境如Spring Boot FatJar,且高版本JDK有额外限制。漏洞影响有限,但凸显AI在安全研究中的整合作用。

🔎

延伸解读

利用条件苛刻,影响面有限

该漏洞并非普遍适用,需要特定环境:应用以Spring Boot FatJar方式运行,使用LaunchedURLClassLoader,且当前URLClassPath包含可走通用Loader的根。默认Tomcat环境因WebappClassLoader不走URLClassPath而无法利用。因此,实际影响范围远小于fastjson的广泛使用面,多数场景下无需过度恐慌。

高版本JDK的限制与绕过

JDK 8下可直接远程加载类,但JDK 9及以上因defineClass校验禁止连续双斜杠,无法直接利用。研究者提出通过SSRF下载JAR到临时文件,再以jar:file:/proc/self/fd/N形式加载,绕过限制。这提醒用户,高版本JDK虽增加利用难度,但并非绝对安全,仍需关注补丁更新。

AI在漏洞挖掘中的角色

文章指出,最初的PoC由AI工具Codex生成,且作者手动设置了ClassLoader,使得利用条件看似宽泛,实则依赖特定配置。这反映了AI在安全研究中的双刃剑效应:既能加速漏洞发现,也可能因生成不切实际的PoC而误导分析。安全社区需谨慎验证AI产出的漏洞报告。

Q&A

fastjson 1.2.83 的 RCE 漏洞是如何被发现的?

该漏洞最初由一名安全研究员在推特上公开声称发现,随后在 GitHub 上有人分享了 PoC,引发了安全社区的广泛讨论和分析。

fastjson 1.2.83 RCE 漏洞的利用原理是什么?

漏洞利用 Spring Boot FatJar 的 LaunchedURLClassLoader,通过构造特殊的类名(如 jar:http://...)使 fastjson 在检测 @JSONType 注解时远程加载恶意类,从而绕过 autoType 限制实现远程代码执行。

fastjson 1.2.83 RCE 漏洞的利用条件有哪些?

利用条件包括:应用使用 Spring Boot FatJar 方式运行(使用 LaunchedURLClassLoader),JDK 版本为 8(高版本 JDK 有额外限制),且当前 URLClasspath 包含可走通用 Loader 的根。默认 Tomcat 环境无法利用。

fastjson 1.2.83 RCE 漏洞与 autoType 有什么关系?

该漏洞与 autoType 无关,即使未开启 autoType 也可能被利用,因此启用 SafeMode 或升级到 Fastjson 2.x 才能解决。

为什么高版本 JDK 下该漏洞难以利用?

高版本 JDK(9+)在 defineClass 时会校验类名,禁止连续双斜杠(//),导致远程加载的类名(如 jar:http://...)无法通过校验,只能触发 SSRF,无法直接 RCE。

该漏洞在哪些环境中无法利用?

在默认 Tomcat 环境中无法利用,因为 Tomcat 的 WebappClassLoader 不会走 URLClassPath,而是直接在本地查找资源。此外,如果 URLClassPath 不包含可走通用 Loader 的根,也无法触发利用链。

该漏洞的影响范围有多大?

该漏洞影响 fastjson 1.2.68 至 1.2.83 版本,但利用条件苛刻,需要特定环境(如 Spring Boot FatJar),因此实际影响有限。

🏷️

标签

➡️

继续阅读