Fastjson 1.x und Apache Axis2/Java: Zwei kritische Java-RCE-Lücken werden bereits ausgenutzt

Kurzfassung

Zwei Java-Schwachstellen sorgen gerade für unnötig viel Bewegung in der Praxis. Bei Fastjson 1.x läuft eine kritische RCE-Lücke unter CVE-2026-16723, die laut Sicherheitsforschern bereits aktiv angegriffen wird. Parallel dazu betrifft CVE-2026-66713 Apache Axis2/Java auf Tomcat, allerdings nur dann, wenn das Tribes-Clustering eingeschaltet ist.

Für Unternehmen im DACH-Raum heißt das: Java-Stacks, Spring-Boot-Anwendungen und Tomcat-Installationen gehören jetzt auf den Prüfstand. Wer betroffene Komponenten produktiv betreibt, sollte nicht auf den nächsten regulären Patch-Tag warten.

Was ist passiert?

Im Fall von Fastjson geht es um eine Schwachstelle in Alibabas JSON-Bibliothek für Java. In bestimmten Spring-Boot-Anwendungen kann eine präparierte JSON-Anfrage dazu führen, dass Code ohne Anmeldung ausgeführt wird. Der Schadcode läuft dann mit den Rechten des Java-Prozesses. ThreatBook und Imperva berichten, dass Angreifer die Lücke bereits gezielt missbrauchen.

Die zweite Meldung betrifft Apache Axis2/Java auf Apache Tomcat. Dort steckt die Schwachstelle in der Tribes-basierten Cluster-Komponente. Ist das Clustering aktiv, kann ein entfernter Angreifer über das Netzwerk einen manipulierten serialisierten Java-Objektstrom einspeisen und damit Code ausführen. Apache liefert mit Version 2.0.1 eine bereinigte Fassung; die Cluster-Funktion wurde dort entfernt.

Technische Details

CVE-2026-16723 trägt laut Alibaba einen CVSS-Wert von 9.0. Die Quelle nennt eine bestätigte Angriffskette, geht aber im Auszug nicht bis ins letzte technische Detail. Klar ist: Betroffen sind Fastjson-1.x-Einsätze in einem Kontext, in dem Spring Boot die JSON-Verarbeitung übernimmt. Das Risiko liegt in der ungeschützten Verarbeitung bösartiger JSON-Daten und dem anschließenden Code-Execution-Pfad.

CVE-2026-66713 ist als kritische Deserialisierungs-Schwachstelle eingeordnet und wird der CWE-502 zugeordnet. Sie tritt nur auf, wenn Tribes-Clustering in Apache Axis2/Java aktiviert ist. Standardmäßig ist diese Funktion aus. Wer sie aber bewusst eingeschaltet hat, öffnet den Cluster-Port für einen unauthentifizierten Angreifer mit Netzwerkzugriff. Der Hersteller empfiehlt den Sprung auf 2.0.1, weil die Cluster-Funktion dort komplett entfernt wurde.

Wer ist betroffen?

Bei Fastjson trifft es vor allem Betreiber von Java-Anwendungen, die die 1.x-Reihe noch einsetzen. Das ist im Enterprise-Umfeld keine exotische Konstellation. Gerade ältere Spring-Boot-Dienste, interne APIs und gewachsene Integrationen hängen oft länger an solchen Bibliotheken, als ihnen guttut.

Für CVE-2026-66713 gilt: Nur Installationen von Apache Axis2/Java auf Tomcat mit aktivem Tribes-Clustering sind angreifbar. Ob auch andere Kombinationen betroffen sind, lässt die Quelle offen. Für die meisten Standard-Setups dürfte die Relevanz deshalb deutlich kleiner sein als bei der Fastjson-Lücke. Wer Clustering nie genutzt hat, hat hier vermutlich kein akutes Problem.

Empfohlene Maßnahmen

Wer Fastjson 1.x im Einsatz hat, sollte zuerst Inventur machen. Welche Anwendungen binden die Bibliothek ein? Welche davon sind aus dem Netz erreichbar? Gibt es Spring-Boot-Dienste, die JSON von außen annehmen? Diese Fragen jetzt sauber zu beantworten, spart später hektische Notfallarbeit.

Dann gilt: Versionen und Abhängigkeiten prüfen, Bibliothek aktualisieren oder Fastjson 1.x konsequent ersetzen. Falls kurzfristig kein Patch verfügbar ist, helfen nur harte Übergangslösungen wie die Einschränkung exponierter Endpunkte, strikte Filter für eingehende JSON-Daten und zusätzliche WAF-Regeln. Das ist keine elegante Lösung, aber oft die einzige belastbare Zwischenstufe.

Bei Apache Axis2/Java sollten Admins prüfen, ob Tribes-Clustering überhaupt aktiv ist. Wenn nicht, bleibt die Lücke praktisch ohne Angriffsfläche. Wenn doch, muss die Installation auf 2.0.1 gehoben oder die Cluster-Funktion sofort abgeschaltet werden. Nebenbei lohnt der Blick auf den Cluster-Port, auf Firewall-Regeln und auf auffällige Verbindungsversuche im Log.

Einschätzung von CyberSecurity-News.de

Die Lage ist für Betreiber von Java-Anwendungen ernst, aber nicht pauschal dramatisch. Fastjson 1.x ist der klare Brennpunkt, weil die Lücke aktiv ausgenutzt wird und keine gepatchte Version im Raum steht. Das ist genau die Sorte Fall, bei der Abwarten teuer wird.

Bei Apache Axis2/Java ist die Lage differenzierter. Die Schwachstelle ist kritisch, ja. Praktisch relevant wird sie aber nur in einem engeren Szenario mit aktiviertem Tribes-Clustering. Wer jetzt pauschal Alarm schlägt, hilft niemandem. Wer die eigene Infrastruktur kennt, hat dagegen einen schnellen Weg zur Risikobewertung.

Die Informationslage ist zudem noch nicht in allen Punkten sauber. Ob es weitere betroffene Konstellationen gibt, bleibt offen. Genau deshalb sollten Teams jetzt nicht auf perfekte Klarheit warten, sondern die eigene Java-Landschaft gezielt durchgehen.

Fazit

Für DACH-Unternehmen mit Java-Stacks ist das eine operative Aufgabe, keine Theorie. Fastjson 1.x gehört sofort geprüft, weil Angreifer die Schwachstelle schon ausnutzen. Apache Axis2/Java ist vor allem dann ein Thema, wenn Tribes-Clustering aktiv ist. Wer diese Komponente gar nicht nutzt, kann das Thema in vielen Umgebungen schnell abhaken.

Die Priorität ist klar: zuerst Internet-exponierte Anwendungen, dann interne Dienste mit externen Schnittstellen, zuletzt alles andere. Wer heute inventarisiert und patcht, reduziert das Risiko deutlich. Wer wartet, macht es Angreifern unnötig leicht.