Fastjson 1.2.83 can still trigger remote code execution without traditional gadgets under the default AutoType=false setting, and has been reproduced in JDK 8/17/21/25 with Spring Boot Loader isolation.

Author and source: GCSA

Summary

In the traditional Java deserialization vulnerability defense system, the industry commonly holds the following misconceptions: “AutoType is safe when disabled by default,” “It’s safe if the second parameter of parseObject (the top-level target type) is fixed,” and “It’s safe if local Classpath deserialization gadget dependencies are removed.” However, the latest advancements in attack and defense techniques have completely shattered these false assumptions.

The Global Cybersecurity Alliance (GCSA) today exclusively releases this technical insights report. The report thoroughly analyzes the root cause of a remote code execution (RCE) vulnerability in Fastjson 1.2.83, which remains exploitable even when default AutoType=false, without relying on traditional Gadgets. This exploitation technique has been successfully end-to-end reproduced in JDK 8 / 17 / 21 / 25 and Spring Boot Loader isolated environments. This vulnerability is not a conventional "bypass of blacklists to locate local Gadgets," but rather directly repurposes Fastjson’s own Class metadata discovery logic into a channel for fetching and authorizing remote malicious Classes. Below is the full text.

Issuing organization: GCSA Global Cybersecurity Alliance

Report Type: Exclusive Technical Insights / Vulnerability Deep Dive Report

Report Date: 2026-07-21

Report status: Source code audit and isolated environment reproduction completed

Vulnerability ID: Internal research number FJ-GETRESOURCE-RCE (not associated with any publicly disclosed CVE)

Fastjson 1.2.83 can still trigger remote code execution without traditional gadgets even when AutoType is disabled by default, and this has been reproduced in JDK 8/17/21/25 with Spring Boot Loader isolation. It is recommended to immediately enable SafeMode and migrate to Fastjson 2.x.

1. Executive Summary

In Fastjson 1.2.83, ParserConfig.checkAutoType converts user-controllable @type values into class resource names and passes them to the current ClassLoader's getResourceAsStream:

In a fat-jar ClassLoader environment capable of resolving absolute URL resource names, an attacker can construct malicious URLs such as http:, jar:http:, and jar:file: by replacing dots, enabling the download of a malicious class annotated with @JSONType from the attacker’s side. Upon detecting this annotation, Fastjson calls loadClass and immediately returns the class without performing dangerous base class checks or target type compatibility checks. Arbitrary code can then be executed when the class is instantiated and initialized.

This exploit does not rely on existing traditional deserialization gadgets in the target classpath and can still be triggered under Fastjson's default AutoType=false setting. Fixing the target type of JSON.parseObject cannot prevent execution; enabling SafeMode can block the normal exploitation path before resource access.

This report has reproduced the following using the same JSON payload in an isolated Linux container:

2. Vulnerability Rating

It is not recommended to assign a uniform CVSS 9.8 based solely on component versions: the standard AppClassLoader serves as a negative control, and a complete modern JDK chain also depends on a loader capable of parsing two types of absolute JAR URLs and /proc/self/fd. In applications meeting the positive environment described in this report, the vulnerability results in unauthenticated remote code execution (RCE).

3. Scope of Impact and Prerequisites

• Runtime confirmation: Fastjson 1.2.83
• JDK confirmed: 8, 17, 21, 25
• Operating system confirmed: Linux; macOS also reproduced JDK 17/21/25 using /dev/fd
• Loader confirmation: Spring Boot 2.7.18 classic loader + JDK 8; Spring Boot 3.2.0 loader + JDK 17/21/25
• API confirmation: JSON.parse, and JSON.parseObject with fixed top-level types

The range 1.2.68–1.2.83 in the external description is more appropriately considered the known test scope rather than the version range where the vulnerability was introduced. Source code review confirms that the decisive class resource detection code was already present in both 1.2.67 and 1.2.68. This report has completed full cross-JDK runtime validation only for version 1.2.83.

1. The attacker can control the JSON input to Fastjson, and the @type in the input will be parsed.

2. SafeMode is not enabled.

3. The ClassLoader loaded by Fastjson can resolve the constructed absolute resource name into a URL.

4. The compromised process can connect to the attacker’s HTTP service.

5. Modern Linux chains require /proc/self/fd to be readable and parseable by the loader.

jar:file:/proc/self/fd/N!...

1. JDK must be able to create normal remote JAR temporary caches; this typically means the JVM temporary directory is writable.

Attackers do not need:

• Write file to target classpath
• The target classpath is preloaded with gadgets such as TemplatesImpl, JNDI, C3P0, and Commons Collections.
• Enable Fastjson AutoType
• Control the second parameter of JSON.parseObject

4. Root Cause Analysis

Source code location:

Core code:

This logic assumes that resource is merely a regular classpath path, but does not restrict its protocol, absolute path semantics, or source. For a specific fat-jar loader, the following inputs will become absolute URLs after replacement:

Therefore, getResourceAsStream loads network resources controllable by attackers due to out-of-bounds queries against local metadata.

Fastjson uses its own ASM ClassReader to parse resource content:

The attacker only needs to make the remote class carry the Fastjson @JSONType annotation to set jsonType to true. This check examines the bytes provided by the attacker, not a class already loaded from a trusted classpath.

Source code location:

TypeUtils.loadClass attempts the explicit loader, thread context loader, and Class.forName in sequence. In a forward environment, the thread context loader will again resolve the same absolute resource name, download the class, and execute defineClass.

Source code location:

• The dangerous base class check is not performed.
• expectClass.isAssignableFrom(clazz) will not be executed
• Fixed data binding types cannot prevent execution before class initialization.

Source code location:

SafeMode checks occur before resource access:

5. Detailed Explanation of Chain Usage

Shortest form:

JDK 17+ will also complete network requests but reject empty path segments in internal names,

The first array element of a single payload:

JDK 17+ subsequently rejects the first-stage jar:http://... internal name, but Fastjson continues parsing the array due to the Exception suffix.

Subsequent candidate elements:

The first hit in the JDK 17 class-load log is:

• JDK 8 directly accepts the first-stage jar:http://... class and executes it.
• After executing the command in stage one, the class deliberately throws RuntimeException("stage-one-stop") to prevent JDK 8 from continuing to attempt unrelated socket/pipe FDs.
• JDK 17+ fails during the first phase due to an invalid name before class initialization, then softly returns via an Exception to enter the FD enumeration phase.

6. Reproduction Environment and Evidence

Expected output:The script will:

• Compile the victim fat jar;
• Generate an attack JAR with FD-specific class;
• Generate a JSON array payload;
• Start the attack endpoint HTTP service on an isolated Docker network;
• Start the JDK 8/17/21/25 affected containers;
• Check each container's mapped /tmp/fastjson-getresource-rce.

Burp only sends JSON to vulnerable endpoints with Fastjson parsing points; the malicious JAR must still be provided by the attacker's HTTP service.

Request template:

If the application uses a fixed top-level type, you can wrap the array according to the field structure, for example:

This experiment used JSON.parseObject(json, BoundEnvelope.class) to parse the above envelope, and the result was still RCE-OK, with BoundEnvelope returned normally.

7. Remediation Recommendations 7.1 Preferred: Migrate away from Fastjson 1.x

Prioritize migrating to the maintained Fastjson 2.x and revalidate all polymorphic types, AutoType, and compatibility mode configurations. Do not simply replace the JAR without performing regression testing.

Code configuration:

JVM parameters:

Note: If the application has registered AutoTypeCheckHandler, it should be audited or removed synchronously, as the handler executes before SafeMode checks.

• Do not directly pass untrusted requests to JSON.parse or JSON.parseObject.
• Reject any form of special-type metadata at the gateway or application entry point.
• Fixing only the top-level Java type is not sufficient, as nested objects can still process @type, and the jsonType in this vulnerability returns early to bypass compatibility checks.

Temporarily intercept requests where the decoded JSON key equals @type, and override URL parameters, request bodies, and nested objects. Do not search only for the literal "@type", as the Fastjson lexer decodes field names first, for example:

WAF rules can only serve as a mitigation and cannot replace component upgrades and SafeMode.

1. Prohibit the business JVM from initiating HTTP/HTTPS connections to non-essential external addresses.
2. Apply minimal network policies to application containers.
3. Restrict exposure or use of /proc/self/fd when compatibility allows, or employ a more restrictive container sandbox.
4. Audit the ClassLoader's handling of absolute URL resource names, rejecting protocols such as http:, https:, jar:, file:.
5. Monitor for unusual jar_cache* activity in the JVM temporary directory.

8. Detection Recommendations and IOCs

Pay special attention to the decoded @type values containing:

Exception alone is not sufficient for alerting; it should be analyzed in conjunction with protocol format, @type, and consecutive FD candidates within the array.

• JVM requests a JAR or .class file without an extension from an abnormal host
• 1–3 duplicate GET/HEAD requests occurred during the same parsing request.
• The request path may contain /x, /a.class, or attacker-defined equivalent paths.

• JVM creates temporary directory with jar_cache*
• The Java process reopens its own file via /proc/self/fd/N
• The class-load log shows similar entries:

9. Conclusion

This vulnerability is not a traditional “bypass blacklist and locate local gadget” attack; instead, it repurposes Fastjson’s own class metadata discovery logic into a remote class retrieval and authorization channel. The early return from @JSONType allows attacker-provided classes to be accepted before dangerous base class and type binding checks; the soft fail channel for exceptions and the JDK jar:http temporary cache extend JDK 8’s direct loading primitives to JDK 17/21/25.

Therefore, the following common assumptions are invalid:

• "AutoType is disabled by default, so it's secure" — is incorrect
• Fixing the second parameter of parseObject does not make it secure.
• "The classpath has no known gadgets, so it is secure" — is incorrect
• JKD 17+ rejects internal names starting with http://, so it's at most SSRF” — incorrect



In deployments that meet the conditions of verified loaders, networks, and file descriptors, this issue can escalate from a single unauthenticated JSON request to actual remote code execution. Prioritize migrating to Fastjson 2.x and immediately enable SafeMode while tightening outbound and ClassLoader resource resolution boundaries.

10. Attachments and Evidence Path

Reprint and copyright notice: This report and related technical analysis are exclusively published by GCSA, the Global Cybersecurity Alliance. Any reprint must fully retain the official GCSA source and original link, and must not maliciously alter the core viewpoints of the report.

Source: GCSA Global Cybersecurity Alliance

Official website: www.gcsa.org