Fastjson 1.x Remote Code Execution Vulnerability: What Applications Should Enterprises Audit Immediately?

Vulnerability Overview

Fastjson officially disclosed a critical remote code execution vulnerability affecting versions 1.2.68 through 1.2.83. In specific deployment environments, attackers can craft malicious JSON payloads to execute arbitrary code on the target server without enabling AutoType and without relying on traditional deserialization gadget chains. The official severity rating is Critical. As of July 24, 2026, no public CVE has been assigned, but technical details and PoC results have already been disclosed. Enterprises using Fastjson 1.x should complete asset auditing and risk remediation as soon as possible.

AutoType Is Disabled — Why Is the Risk Still Present?

Historically, Fastjson deserialization vulnerabilities were closely tied to the AutoType feature. Many organizations believed that keeping AutoType disabled was sufficient to prevent attackers from specifying arbitrary Java types. This vulnerability breaks that assumption. According to the official advisory, the flaw resides in the type-checking and resource-loading logic of Fastjson 1.2.68–1.2.83. When Fastjson processes the @type field in JSON data, part of the user-controllable content may enter the resource lookup and class loading flow. Attackers can exploit this logic to make the application reach external malicious resources and, in qualifying Spring Boot environments, complete the full chain from resource loading to remote code execution. This means that even with default Fastjson configuration and AutoType disabled, risk still exists as long as SafeMode is not enabled. Security researchers describe it as an exploit chain evolving from SSRF and external resource loading into RCE.

Which Systems May Be Affected?

This vulnerability does not affect all Fastjson 1.x versions. The officially confirmed affected scope is: Fastjson version between 1.2.68 and 1.2.83; SafeMode is not enabled; the application is deployed as a Spring Boot executable fat jar, typically started via java -jar xxx.jar; the application has JSON inputs that an attacker can control or influence; the application calls JSON.parse, JSON.parseObject(String), or related JSON parsing APIs. The vendor has completed end-to-end validation in Spring Boot 2.x, 3.x, and 4.x as well as on JDK 8, 11, 17, and 21. Even if developers specify a target DTO type during parsing, the risk cannot be simply ruled out, because attackers can still nest malicious data through Object or Map type fields within the DTO.

Which Cases Are Currently Not Affected?

According to the official Fastjson advisory, the following cases are not affected by this vulnerability: all Fastjson 2 versions; Fastjson 1.x with SafeMode enabled; build variants such as 1.2.83_noneautotype that remove the related code paths; non-fat-jar deployments that do not meet the trigger conditions; Fastjson 1.2.60 and earlier, because the relevant vulnerable code path does not exist there. Note that being unaffected by this specific issue does not mean those versions are free of other historical security problems. Especially older Fastjson releases may still contain other deserialization vulnerabilities and bypass risks, so downgrading to an older version is not recommended as a long-term solution.

How Should Enterprises Complete Emergency Remediation?

Enterprises first need to confirm whether applications actually reference Fastjson and identify the exact version. The auditing scope should not only cover business code, but also third-party SDKs, middleware components, legacy systems, and transitive dependencies. For applications confirmed to use Fastjson 1.2.68–1.2.83, further verification is required for the deployment mode, SafeMode status, JSON input sources, and related parsing APIs. If an immediate version migration is not possible, enable SafeMode as the priority: -Dfastjson.parser.safeMode=true, or set ParserConfig.getGlobalInstance().setSafeMode(true) during program initialization. Enterprises can also temporarily switch to the noneautotype build of Fastjson. However, from a long-term security governance perspective, the official recommendation is to migrate to Fastjson 2.x. Fastjson 2 has architecturally removed the resource probing and trust bypass mechanisms involved in this vulnerability, and its default configuration is not affected by this issue. During the upgrade, R&D teams still need to perform full regression testing on serialization results, date formats, polymorphic types, legacy API compatibility, and upstream/downstream data exchange, to avoid impacting existing business by directly replacing the dependency.

CloudSino Capability Updates

In response to this critical Fastjson RCE risk, CloudSino has updated its security identification and risk alerting capabilities to help customers quickly locate potentially affected servers, application environments, and component versions. Leveraging unified asset management, automatic device discovery, configuration collection, and operational data correlation, the CloudSino platform helps operations teams clarify the relationships between servers and business systems, reducing omissions caused by manual registration and cross-system queries. For identified at-risk devices, administrators can combine asset location, device owner, business association, and runtime status to set remediation priorities, prioritizing systems that carry core business, expose external interfaces, or reside in high-risk network zones. The platform also continuously records device configuration and asset changes, providing data basis for review, audit, and traceability after remediation. Through a unified view, enterprises can more clearly answer key questions: which servers are affected, what business they carry, who is responsible for remediation, and whether the issue has been resolved.

• Affected versions: Fastjson 1.2.68–1.2.83, with SafeMode disabled, deployed as a Spring Boot fat jar,Trigger conditions: the @type field in the JSON input is attacker-controllable, and JSON.parse / JSON.parseObject is called,Not affected: all Fastjson 2.x versions, SafeMode enabled, the 1.2.83_noneautotype build, and 1.2.60 or earlier,Short-term containment: enable SafeMode, or switch to the 1.2.83_noneautotype build as a temporary mitigation,Long-term plan: migrate to Fastjson 2.x and complete regression testing for serialization, dates, polymorphism, and upstream/downstream APIs