Kritische Fastjson 1.x-Sicherheitslücke ermöglicht Codeausführung in Spring Boot-Anwendungen – kein Patch verfügbar

Eine kritische Sicherheitslücke zur Remote-Code-Ausführung in Fastjson 1.x, Alibabas weit verbreiteter JSON-Serialisierungsbibliothek für Java, wird derzeit aktiv im Feld ausgenutzt, wie The Hacker News berichtet. Der Fehler, verfolgt als CVE-2026-16723 und mit einem CVSS-Score von 9,0 bewertet, betrifft Fastjson-Versionen 1.2.68 bis 1.2.83 und ermöglicht es einem Angreifer, beliebigen Code mit den Berechtigungen des Java-Prozesses auszuführen – ohne Authentifizierung, ohne dass Fastjcons AutoType-Funktion aktiviert sein muss und ohne auf Gadget-Klassen von Drittanbietern angewiesen zu sein, die frühere Fastjson-Exploits typischerweise benötigten.

Wie die Exploit-Kette funktioniert

Die Schwachstelle zielt auf Spring Boot-Anwendungen ab, die als ausführbare „fat-JARs“ bereitgestellt werden – das eigenständige All-in-One-JAR-Format, das Spring Boot üblicherweise für die Auslieferung erzeugt. Die Ausnutzung wurde für Spring Boot 2.x, 3.x und 4.x unter JDK-Versionen 8, 11, 17 und 21 bestätigt, was die überwältigende Mehrheit der Java-Umgebungen abdeckt, die Fastjson 1.x noch in Produktion einsetzen.

Der Angriff funktioniert durch das Senden einer präparierten JSON-Anfrage mit einem manipulierten @type-Wert, der Fastjcons Typauflösungslogik dazu bringt, eine Klassen-Ressourcensuche durchzuführen. In einem kompatiblen Spring Boot-fat-JAR kann ein speziell konstruierter verschachtelter JAR-Pfad dann vom Angreifer kontrollierten Bytecode abrufen. Eine begleitende @JSONType-Annotation auf dieser Ressource wird von Fastjson als Vertrauenssignal behandelt, sodass die schädliche Klasse Fastjcons Typprüfungsmechanismen vollständig umgehen und in die laufende Anwendung geladen werden kann. Da der Exploit unter Fastjcons Standardkonfiguration funktioniert – SafeMode ist standardmäßig deaktiviert – ist jeder ungepatchte, internetfähige Spring Boot-Dienst, der eine betroffene Fastjson-Version verwendet, potenziell angreifbar, ohne dass der Angreifer eine spezielle Konfiguration vornehmen muss.

Kein Patch, aber Abhilfemaßnahmen vorhanden

Stand 25. Juli 2026 hat Alibaba noch keinen offiziellen Patch speziell für den Fastjson 1.x-Zweig veröffentlicht. Sicherheitsteams haben vorerst drei praktische Optionen. Die erste ist die Aktivierung des SafeMode direkt über die Systemeigenschaft -Dfastjson.parser.safeMode=true, die das für den Exploit benötigte Typauflösungsverhalten blockiert. Die zweite ist der Wechsel zur spezifischen Paketvariante com.alibaba:fastjson:1.2.83_noneautotype, die die AutoType-Funktionalität vollständig entfernt. Die dritte und von Alibaba als langfristige Lösung empfohlene Option ist die Migration von Fastjson 1.x auf Fastjson2, die aktiv gepflegte Nachfolgebibliothek.

Was nicht betroffen ist

Die spezifische Exploit-Kette erfordert das von Spring Boot standardmäßig verwendete fat-JAR-Bereitstellungsformat – einfache nicht-fat-JARs, generische uber-JARs, die mit Tools wie Maven Shade erstellt wurden, und als WAR-Dateien in Tomcat oder Jetty bereitgestellte Anwendungen sind für diesen speziellen Angriffspfad nicht anfällig, da sie die verschachtelte JAR-Klassenressourcensuche nicht bereitstellen, auf die der Exploit angewiesen ist. Das schränkt die betroffene Population ein, beseitigt das Risiko jedoch nicht: fat-JAR-Bereitstellung ist die Standard- und häufigste Paketierungswahl für Spring Boot-Anwendungen, gerade weil sie die Bereitstellung auf eine einzelne ausführbare Datei vereinfacht.

Warum dies über eine einzelne Bibliothek hinaus relevant ist

Fastjson hat eine lange Geschichte schwerwiegender Deserialisierungsschwachstellen, die fast ein Jahrzehnt zurückreicht, und Fastjson 1.x bleibt trotz Alibabas eigener Empfehlung zur Migration auf Fastjson2 weit verbreitet in produktiven Java-Systemen im Einsatz. Organisationen, die Spring Boot-fat-JAR-Bereitstellungen mit Fastjson 1.x im Bereich 1.2.68–1.2.83 betreiben, sollten dies als dringende Patch-Priorität behandeln: SafeMode sofort als Übergangslösung aktivieren und die Migration auf Fastjson2 als dringend und nicht optional betrachten, da Alibabas Entscheidung, den 1.x-Zweig nicht zu patchen, darauf hindeutet, dass auch zukünftige Schwachstellen in dieser Linie wahrscheinlich nicht behoben werden.