Kritische Fastjson-Lücke ermöglicht Angriffe ohne Anmeldung

Fastjson 2.x steht wegen einer kritischen Remote-Code-Execution-Warnung unter Druck. Laut NSFOCUS CERT kann ein nicht angemeldeter Angreifer unter bestimmten Bedingungen manipulierte JSON-Daten an eine verwundbare Anwendung senden und darüber Schadcode ausführen. Besonders brisant ist die Einordnung, weil der Angriff laut Warnung keine zusätzlichen gefährlichen Drittanbieterklassen auf dem Zielsystem benötigt. Betroffen sein sollen Fastjson-2.x-Versionen bis einschließlich 2.0.62. Für Software-Sicherheit ist der Fall heikel, weil Fastjson als Java-Bibliothek tief in Backend-Diensten, APIs, internen Anwendungen und Legacy-Systemen stecken kann.

Die neue Warnung betrifft Fastjson 2.x, aber die Quellenlage bleibt angespannt

Der Auslöser ist eine NSFOCUS-Warnung zu Fastjson 2.x. Die Sicherheitsfirma beschreibt eine Schwachstelle in der Typverarbeitung von Fastjson2. Auch ohne aktivierte Standard-Option für SupportAutoType könne die Bibliothek über eine eingebaute Whitelist weiterhin bestimmte Typangaben in JSON verarbeiten. Ein Angreifer könne daraus unter passenden Bedingungen eine Codeausführung ableiten.

Das klingt ähnlich wie frühere Fastjson-Probleme, ist aber nicht identisch. Fastjson hatte schon mehrfach Sicherheitsprobleme durch unsichere Deserialisierung und AutoType-Mechanismen. Viele Abwehrregeln konzentrieren sich deshalb auf bekannte gefährliche Klassen, typische Gadget-Ketten oder aktivierte AutoType-Funktionen. Die neue Warnung legt nahe, dass genau diese einfache Prüfung nicht genügt.

Wichtig ist die Trennung zur älteren Fastjson-1.x-Lücke. Für CVE-2026-16723 nennt Alibaba offiziell Fastjson 1.2.68 bis 1.2.83 als betroffen und erklärt Fastjson2 als nicht betroffen. Die jetzige Fastjson-2.x-Warnung läuft jedoch über eine neue öffentliche Diskussion, einen Hardening-Pull-Request und die NSFOCUS-Einschätzung. Es handelt sich damit nicht nur um eine Wiederholung der 1.x-Meldung.

Die Quellenlage hat einen zweiten Haken. NSFOCUS spricht von einem offiziellen Patch und nennt Versionen größer als 2.0.62 als nicht betroffen. Gleichzeitig listet Maven Repository zum Prüfzeitpunkt 2.0.62 als aktuelle veröffentlichte Version. Im GitHub-Issue fragen Nutzer genau nach einer stabilen Release-Version für den Fix. Admins sollten deshalb nicht nur auf Versionsnummern schauen, sondern die tatsächlichen Artefakte, Builds und Herstellerhinweise prüfen.

Die wichtigsten Fakten aus den öffentlichen Quellen lauten:

• NSFOCUS-Warnung: Fastjson 2.x bis 2.0.62 soll verwundbar sein.
• Schweregrad: NSFOCUS nennt CVSS 9.8 und damit eine kritische Einstufung.
• Angriff: Manipulierte JSON-Daten können ohne Anmeldung gefährlich werden.
• Gadget-Frage: Laut Warnung braucht der Angriff keine zusätzlichen gefährlichen Drittanbieterklassen.
• Release-Frage: Ein öffentlich klarer, stabiler Fixstand muss in den eigenen Paketquellen verifiziert werden.

Diese Unsicherheit macht den Fall für Sicherheitsverantwortliche nicht kleiner, sondern größer. Bei Ubuntu und der snap-confine-Root-Lücke war die Lage klarer: Canonical veröffentlichte korrigierte Pakete und konkrete Versionen. Bei Fastjson 2.x müssen Teams zusätzlich den Status zwischen Advisory, GitHub, Maven und eigenen Builds abgleichen.

Warum eine JSON-Bibliothek so gefährlich werden kann

Fastjson ist keine sichtbare Anwendung. Die Bibliothek sitzt in Java-Projekten und verarbeitet Datenstrukturen. Genau das macht sie gefährlich. JSON-Daten erreichen viele Dienste direkt von außen: REST-APIs, Login-Endpunkte, Webhooks, interne Microservices, Gateway-Dienste, mobile App-Backends, Partner-Schnittstellen und Message-Verarbeitung.

Ein Parser wirkt harmlos, weil er nur Text in Objekte umwandelt. Bei Deserialisierung entsteht jedoch ein Sicherheitsproblem, sobald JSON-Daten bestimmen können, welche Java-Typen geladen oder erzeugt werden. Dann verarbeitet die Anwendung nicht nur Nutzdaten, sondern Teile einer Objektstruktur. Fehler in dieser Logik können dazu führen, dass Angreifer unerwartete Klassenpfade, Initialisierungen oder Nebenwirkungen erreichen.

Fastjson war in der Java-Welt besonders auffällig, weil AutoType-Funktionen früher wiederholt missbraucht wurden. AutoType erlaubt die Angabe eines Zieltyps innerhalb von JSON-Daten. Solche Funktionen sind praktisch für Entwickler, schaffen aber ein hohes Risiko bei untrusted input. Die neue Warnung zeigt, dass selbst deaktivierte oder eingeschränkte AutoType-Pfade sehr genau geprüft werden müssen.

Aus Entwicklersicht ist der gefährliche Normalfall leicht zu übersehen. Ein Endpunkt nimmt JSON entgegen, ruft die Bibliothek auf und übergibt das Ergebnis an Business-Logik. Wenn dieser Endpunkt ohne Anmeldung erreichbar ist, wird aus einer Parser-Lücke ein Pre-Auth-Risiko. Wenn der Java-Prozess weitreichende Rechte besitzt, kann aus Codeausführung schnell Datenabfluss, Persistenz oder Seitwärtsbewegung entstehen.

Besonders betroffen sind Systeme mit diesen Eigenschaften:

• Öffentliche APIs: Externe JSON-Requests erreichen den Parser direkt oder fast direkt.
• Spring-Backends: Java-Dienste mit breiter JSON-Verarbeitung müssen ihre Abhängigkeiten prüfen.
• Legacy-Code: Alte Fastjson-Nutzung kann in Hilfsmodulen, SDKs oder internen Bibliotheken stecken.
• Partner-Endpunkte: Webhooks und B2B-Schnittstellen bekommen oft komplexe JSON-Strukturen.
• Gateway-Dienste: Zentrale API-Schichten verarbeiten besonders viel untrusted input.

Der Fall passt in eine größere Welle von Sicherheitsproblemen in Software-Lieferketten und Bibliotheken. Bei kompromittierten npm-Paketen bei Red Hat stand die Paketkette im Mittelpunkt. Fastjson zeigt eine andere Seite: Selbst eine legitime, weit verbreitete Bibliothek kann durch eine Parser- oder Deserialisierungslogik zum Eintrittspunkt werden.

Admins sollten nicht nur nach fastjson2 suchen

Der erste Reflex lautet: Version prüfen und aktualisieren. Das reicht hier nicht. Viele Java-Anwendungen bündeln Bibliotheken in Fat-JARs, Container-Images oder internen Artefakten. Ein einfacher Blick auf das Betriebssystempaket erkennt solche Kopien nicht. Fastjson kann außerdem indirekt über andere Bibliotheken kommen. Teams müssen deshalb Build-Dateien, Dependency-Locks, Container-Images und laufende Prozesse prüfen.

NSFOCUS nennt einfache Suchwege wie JAR-Dateien im Projektverzeichnis, Maven-Konfigurationen und laufende Prozesse. In Unternehmen braucht es meist mehr. Software Composition Analysis, SBOMs, Maven-Dependency-Trees, Container-Scans und CI/CD-Artefaktprüfungen sollten zusammenlaufen. Wichtig ist auch der Unterschied zwischen der Bibliothek im Repository und der Bibliothek im produktiven Artefakt.

Für eine erste Priorisierung hilft diese Reihenfolge:

• Internetnahe Dienste zuerst: APIs, Gateways, Webhooks und Login-nahe Endpunkte haben Vorrang.
• Fastjson2 bis 2.0.62 markieren: Diese Versionen nennt NSFOCUS als betroffen.
• Fastjson 1.x nicht vergessen: CVE-2026-16723 betrifft weiterhin 1.2.68 bis 1.2.83.
• SafeMode prüfen: SafeMode reduziert AutoType-Risiken und sollte für nicht vertrauenswürdige Daten aktiv sein.
• Parser-Nutzung prüfen: Entscheidend ist, ob untrusted JSON in riskante Deserialisierungspfade gelangt.

SafeMode ist kein Ersatz für ein sauberes Update, aber ein wichtiger Schutzmechanismus. Alibaba hatte SafeMode bereits für Fastjson 1.x eingeführt, um AutoType unabhängig von Listenlogik zu deaktivieren. NSFOCUS empfiehlt SafeMode auch als temporäre Schutzmaßnahme. In der Praxis müssen Entwickler prüfen, ob eine Anwendung überhaupt auf AutoType-Funktionen angewiesen ist. Viele Dienste sollten ohne diese Funktion auskommen.

Zusätzliche Schutzschichten können helfen. Eine Web Application Firewall kann JSON-Requests mit verdächtigen Typfeldern blockieren. API-Gateways können ungewöhnlich große oder verschachtelte JSON-Strukturen begrenzen. Logging kann verdächtige Parserfehler sichtbar machen. Diese Maßnahmen verhindern aber keinen Fehler in der Anwendung selbst. Sie kaufen Zeit, ersetzen aber kein Dependency-Update und keine sichere Parser-Konfiguration.

Auch der Betriebskontext zählt. Ein Java-Prozess sollte nicht mit unnötigen Systemrechten laufen. Container sollten keine sensiblen Host-Pfade mounten. Secrets sollten nicht dauerhaft in Umgebungsvariablen oder Klartextdateien liegen. Netzwerkzugriffe aus dem Dienst heraus sollten beschränkt werden. Wenn eine RCE gelingt, entscheidet diese Härtung über den Schaden.

Der Vergleich mit Adobes Acrobat-Erweiterung und WhatsApp-Web-Daten zeigt den gleichen Grundsatz auf einer anderen Ebene: Sicherheitsrisiken entstehen oft in Komponenten, die Nutzer oder Betreiber nicht als Hauptanwendung wahrnehmen. Browser-Erweiterung, JSON-Parser, Snap-Komponente oder npm-Paket sitzen unter der Oberfläche, haben aber direkten Einfluss auf vertrauliche Daten und Systemgrenzen.

Der Patchstatus muss aktiv nachverfolgt werden

Die kritischste offene Frage lautet: Welche Version ist wirklich der saubere Fix? NSFOCUS nennt Versionen größer als 2.0.62 als nicht betroffen und verweist auf einen Pull Request zur Härtung. Öffentlich sichtbare Paketlisten zeigen 2.0.62 jedoch noch als aktuelle Maven-Version vom 5. Mai 2026. Der GitHub-Pull-Request beschreibt Sicherheits-Hardening, wurde aber nicht als normale Release-Notiz mit finaler Paketversion sichtbar.

Für Redaktionen und Admins bedeutet das: Die Meldung sollte nicht so formuliert werden, als gäbe es bereits überall ein eindeutig verfügbares Maven-Release. Unternehmen sollten die Fastjson-Projektseite, Maven Central, interne Mirrors, Security Advisories des Herstellers und Hinweise der eigenen Scanner eng prüfen. Sobald eine Version oberhalb von 2.0.62 verfügbar ist, sollte sie kontrolliert getestet und ausgerollt werden.

Bis dahin stehen kompensierende Maßnahmen im Vordergrund:

• Fastjson2-Nutzung inventarisieren: Direkte und transitive Abhängigkeiten erfassen.
• Exponierte Endpunkte priorisieren: JSON-Eingänge aus dem Internet zuerst prüfen.
• SafeMode aktivieren: AutoType-Funktionalität für untrusted input konsequent deaktivieren.
• Typfelder blockieren: API-Gateway oder WAF auf verdächtige Typangaben in JSON vorbereiten.
• Rechte reduzieren: Java-Dienste mit minimalen Betriebssystem- und Netzwerkrechten ausführen.
• Logs prüfen: Ungewöhnliche Parserfehler und verdächtige JSON-Strukturen auswerten.

Die Lage kann sich schnell ändern. Sobald Exploit-Details öffentlich kursieren, sinkt die Hürde für automatisierte Scans. Das war bereits bei früheren Fastjson-Lücken zu beobachten. Eine Bibliothek mit breiter Verbreitung und JSON-Eingang eignet sich für Massensuche, weil Angreifer viele APIs mit ähnlichen Mustern testen können. Teams sollten daher nicht bis zum nächsten normalen Sprint warten.

Gleichzeitig ist Panik nicht hilfreich. Nicht jede Anwendung mit Fastjson2 ist automatisch ausnutzbar. Die riskante Kette hängt von Version, Konfiguration, Parserpfad, erreichbarem Endpunkt, Runtime-Rechten und Schutzschichten ab. Die Kombination aus „ohne Anmeldung“ und „ohne zusätzliche gefährliche Klassen“ rechtfertigt aber eine Notfallprüfung.

Fastjson 2.x braucht jetzt dieselbe Behandlung wie jede kritische Parser-Lücke in produktiven Java-Systemen: Inventar, Priorisierung, SafeMode, WAF-Regeln, Patch-Nachverfolgung und sichere Laufzeitumgebung. Die größte Gefahr liegt nicht nur im einzelnen CVSS-Wert, sondern in unsichtbaren Abhängigkeiten. Wer Fastjson nur im Quellcode sucht und gebündelte JARs, Container und transitive Bibliotheken ignoriert, kann verwundbare Parser weiter produktiv betreiben.