fastjson-check

Mit einem einzigen Befehl herausfinden, ob in deiner Java-Anwendung fastjson steckt, wo es versteckt ist und ob sie von CVE-2026-16723 betroffen ist.

Keine Abhängigkeiten · vollständig offline · eine einzige 23 KB große jar · unterstützt Java 8+

English | Download

---

Warum man es braucht

Am 21. Juli 2026 veröffentlichte fastjson offiziell CVE-2026-16723 (CVSS 9.0, Remote Code Execution):

• Betrifft fastjson 1.2.68 ~ 1.2.83
• Bereits mit der Standardkonfiguration ausnutzbar – kein AutoType, kein classpath-Gadget, keine Authentifizierung erforderlich
• Innerhalb weniger Tage nach der Ankündigung erschienen Exploits in freier Wildbahn, die sich vor allem gegen Spring Boot fat-JAR-Deployments richten

⚠️ Der offizielle Patch 1.2.84 ist erschienen, aber kaum jemand weiß davon

Zahlreiche Sicherheitshinweise (darunter mehrere englischsprachige Sicherheitsmedien) behaupten bis heute, „1.x ist EOL, es wird niemals einen Patch geben, man kann nur auf fastjson2 migrieren“. Diese Aussage ist seit dem 2026-07-29 nicht mehr zutreffend. Selbst überprüfbar:

Beleg	Link
Im Maven Central Repository gibt es com.alibaba:fastjson:1.2.84, die jar wurde am 2026-07-29 hochgeladen	repo1
GitHub-Release 1.2.84, veröffentlicht am 2026-07-29T08:24:51Z	release
Entscheidender Commit fix: strengthen autoType type name validation and whitelist verification	2026-07-29T07:02:55Z

1.2.83 wurde im Mai 2022 veröffentlicht, danach gab es im 1.x-Zweig vier Jahre lang keine Commits – 1.2.84 wurde eigens als Ausnahme für diese Schwachstelle veröffentlicht.

Der Release-Titel weist nicht auf den Sicherheitsfix hin: Der Titel von 1.2.83 enthielt „(Sicherheitsfix)“, während 1.2.84 nur „1.2.84版本发布“ lautet. Im Text steht es jedoch – es gibt einen vollständigen Abschnitt Security Fixes, der vier AutoType- Härtungen einzeln auflistet, und das war bereits ab dem Veröffentlichungstag (2026-07-29) so (nachprüfbar im Wayback-Archiv 20260729094935).

Was den Grund dafür betrifft, warum Sicherheitshinweise und Scanner nach der Patch-Veröffentlichung größtenteils noch nicht nachgezogen haben, habe ich nicht geklärt; hier stelle ich keine Vermutungen an.

📌 Korrektur vom 2026-08-14: Hier stand ursprünglich „Der gesamte Text erwähnt keine Sicherheit, daher wurde es nicht nachgezogen“. Der erste Halbsatz hat sich durch den Release-Text und das Wayback-Archiv vom selben Tag als falsch erwiesen (nur der Titel war nicht gekennzeichnet), der zweite Halbsatz verliert damit ebenfalls seine Grundlage und wurde mit entfernt.

👉 Praktische Auswirkung für 1.x-Nutzer: Das Upgrade auf 1.2.84 ist die kostengünstigste Maßnahme (eine Minor-Version im selben Zweig, in der Regel ohne Codeänderungen), man muss nicht sofort gezwungenermaßen die große Migration auf fastjson2 durchführen. Dieses Tool gibt entsprechend diese Empfehlung.

⚠️ Voraussetzung ist JDK 8 oder höher (getestet am 2026-10-14): Alle 274 Klassen von 1.2.84 sind Java-8-Bytecode (major 52), 1.2.83 ist Java 5 (major 49). Unter JDK 7 (Zulu 7u352) gibt javac nur eine Warnung aus, Exit-Code 0, zur Laufzeit wird jedoch direkt UnsupportedClassVersionError: com/alibaba/fastjson/JSON : Unsupported major.minor version 52.0 geworfen. Außerdem: Die Konstante JSON.VERSION in 1.2.84 ist weiterhin "1.2.83", wer die Version daran abliest, liegt falsch; dieses Tool liest pom.properties und ist davon nicht betroffen.

Der unangenehmste Punkt ist jedoch:

fastjson ist meist eine transitive Abhängigkeit – niemand installiert es absichtlich, es wird von anderen Bibliotheken mitgeschleppt. Viele Teams wissen gar nicht, dass sie es verwenden.

mvn dependency:tree kann Abhängigkeiten auflisten, ist aber bei zwei Fällen machtlos:

1. Du hast nur eine fertig gepackte fat-JAR vorliegen, ohne Quellcode und Build-Umgebung (der häufigste Szenario bei Notfalluntersuchungen im laufenden Betrieb)
2. fastjson wurde per Shade in die jar eines SDK eingebettet, im Abhängigkeitsbaum ist es überhaupt nicht sichtbar

Dieses Tool wurde für genau diese beiden Fälle geschrieben.

Schnellstart

Lade fastjson-check.jar von Releases herunter und dann:

# 扫一个 jar（Spring Boot fat-JAR 会自动逐层展开）
java -jar fastjson-check.jar ./myapp.jar

# 扫一整个目录（递归查找所有 jar/war）
java -jar fastjson-check.jar /opt/apps

# 输出 JSON，接入流水线
java -jar fastjson-check.jar /opt/apps --json

Keine Installation, kein Konto, kein Internet, keine Datenübertragung.

Als Maven-Plugin ausführen (ab 0.3.0)

Dasselbe Artefakt ist sowohl CLI als auch Maven-Plugin. Bei dieser Verwendung ist kein vorheriger Download der jar erforderlich:

# 在你的项目目录下直接跑，扫的是 Maven 解析后的依赖
mvn io.github.xiaoqimikko:fastjson-check:0.3.1:check

Oder in den Build-Lebenszyklus einbinden (Phase verify):

<plugin>
  <groupId>io.github.xiaoqimikko</groupId>
  <artifactId>fastjson-check</artifactId>
  <version>0.3.1</version>
  <executions>
    <execution>
      <goals><goal>check</goal></goals>
    </execution>
  </executions>
</plugin>

Warum der Plugin-Modus präziser ist als das CLI pom.xml scannen zu lassen

Wenn das CLI pom.xml scannt, liest es Text, aber in echten Projekten steht die fastjson-Version oft nicht in diesem Text:

• Als Property geschrieben: <version>${fastjson.version}</version>
• Von <parent> geerbt, in deiner eigenen pom fehlt diese Zeile
• Der häufigste Fall: Es ist eine transitive Abhängigkeit, die von einer anderen Bibliothek hereingebracht wird; in deiner pom wird fastjson überhaupt nicht erwähnt

Das Plugin erhält die Abhängigkeitsmenge von Maven nach der Auflösung, wobei jede Abhängigkeit den echten jar-Pfad im lokalen Repository mitbringt. Damit wird genau der Weg eingeschlagen, für den dieses Tool am besten geeignet ist: das com/alibaba/fastjson(2)/JSON.class im echten jar scannen, anstatt darauf zu vertrauen, was in der pom steht.

⚠️ Aber die Erkennungsgrenze ändert sich dadurch nicht: Der Entscheidungsschlüssel bleibt dieser class-Pfad, daher können Abhängigkeiten, die relocatet / mit geändertem Paketnamen neu gepackt wurden, weiterhin nicht erkannt werden (siehe unten „Was es nicht ist“). Das Plugin löst „wo die Version geschrieben steht“, nicht „der Paketname wurde geändert“.

Parameter

Parameter	Standard	Beschreibung
-Dfastjson-check.failOnFound	false	Lässt den Build fehlschlagen, wenn CRITICAL / HIGH gefunden wird
-Dfastjson-check.path	nicht gesetzt	Durchsucht nicht den Abhängigkeitsbaum, sondern stattdessen diesen Pfad (Verzeichnis / jar / war / fat-jar)
-Dfastjson-check.skip	false	Überspringt die Ausführung

🔴 Standardmäßig wird der Build bewusst nicht fehlschlagen lassen, das ist Absicht und unterscheidet sich von der Exit-Code-Semantik des CLI: Die Kommandozeile tippst du selbst ein, ein Exit-Code 1 ist genau das, was du willst; das Plugin hängt jedoch an der Pipeline, ein Selbstprüfungstool sollte deinen Build nicht rot machen, wenn du nicht darauf vorbereitet bist. Um es als CI-Gate zu nutzen, füge explizit -Dfastjson-check.failOnFound=true hinzu.

💡 Wenn der Bericht unter Windows Zeichensalat ist, schalte die Konsole zurück auf GBK (chcp 936) – die Ausgabekodierung im Plugin-Modus wird von Maven bestimmt, die CLI-Schalter --utf8 / --gbk erreichen sie hier nicht.