7. August 2026

Auf der Black Hat 2026 haben Sicherheitsforscher von Novee Security zwölf Schwachstellen in verbreiteten Enterprise-Java-Plattformen vorgestellt. Im Mittelpunkt ihres Vortrags mit dem Titel „Pre-auth RCE in Enterprise Java: When Middleware Becomes the Exploit“ stehen zwei vollständige Angriffsketten, mit denen sich ganz ohne Anmeldedaten Code auf fremden Systemen ausführen lässt. Insgesamt hatten die Forscher vier Enterprise-Java-Plattformen untersucht und dabei neben den beiden Hauptketten auch einen Sandbox-Escape sowie weitere Schwachstellen im Vorfeld einer Authentifizierung entdeckt. Im Zentrum der Veröffentlichung stehen jedoch die BPM-Plattform Bonita sowie die ERP-Suite Apache OFBiz. Die Hersteller wurden im Vorfeld informiert, die Lücken wurden im Rahmen einer koordinierten Offenlegung geschlossen, bevor die Ergebnisse öffentlich vorgestellt wurden.

Vergessene Middleware als Einfallstor

Enterprise-Java-Systeme werden seit rund zwei Jahrzehnten weiterentwickelt und mit Updates versorgt. Dennoch bleiben nach Angaben der Forscher immer wieder Lücken bestehen – meist nicht in der Kernanwendung selbst, sondern in Komponenten, die im Hintergrund arbeiten: Router, Servlet-Dispatcher, Single-Sign-On-Handler, Template-Engines oder Serialisierungsbibliotheken. Diese Bauteile wurden ursprünglich nicht dafür entwickelt, mit nicht vertrauenswürdigen Eingaben umzugehen. Sie liegen strukturell zwischen dem öffentlichen Zugang eines Systems und internen Diensten, die eigentlich davon ausgehen, von außen nicht erreichbar zu sein. Genau diese Annahme erweist sich laut den Forschern regelmäßig als Schwachpunkt:

Eine intern gedachte Funktion wird über einen ungeschützten Einstiegspunkt zugänglich, ein Ausführungsziel macht daraus eine vollständige Codeausführung ohne vorherige Anmeldung.

Erste Kette: Bonita BPM

Bonita ist eine quelloffene Plattform für Geschäftsprozessmanagement mit grafischem Workflow-Generator, Aufgabenverwaltung und Anbindungen an Systeme wie SAP, Salesforce oder LDAP-Verzeichnisse. Sie kommt unter anderem im Banken- und Versicherungswesen, in Behörden und in der Telekommunikationsbranche zum Einsatz – etwa bei Kreditfreigaben, der Bearbeitung von Schadensfällen oder der Einarbeitung neuer Mitarbeiter. Die Software läuft typischerweise auf Java 11 aufwärts, mit Tomcat als Anwendungsserver, dem Spring-Framework sowie den Bibliotheken XStream und Groovy. Bonita bietet zwei Programmierschnittstellen: einen öffentlichen Bereich, der eine Anmeldung sowie einen Schutz gegen Cross-Site-Request-Forgery voraussetzt, und eine interne Schnittstelle, die eigentlich nur per Basisauthentifizierung erreichbar sein soll. Über diese interne Schnittstelle werden eingehende Daten roh über die Bibliothek XStream verarbeitet, die für ihren nachlässigen Umgang mit Objekttypen bekannt ist. Für die Forscher stellte sich deshalb von Anfang an weniger die Frage, ob sich XStream missbrauchen lässt, sondern ob sich der Weg dorthin ohne Anmeldung überhaupt erreichen lässt.

Die Forscher fanden einen Weg, drei voneinander unabhängige Schutzmechanismen mit einer einzigen, speziell aufgebauten URL gleichzeitig zu umgehen:

Eine Komponente zur URL-Normalisierung interpretiert die Zeichenfolge „..;“ anders als der Anfrage-Verteiler von Tomcat, wodurch sich der geschützte Pfad verschleiern lässt.
Zwei Sicherheitsfilter prüfen Anfragen mit einer Funktion, die bereits bei einer Teilübereinstimmung „wahr“ zurückgibt, statt die vollständige Zeichenkette abzugleichen.
In der Konfigurationsdatei fehlt für die interne Schnittstelle ein Eintrag, der auch weitergeleitete Anfragen erfassen würde – nur direkte Zugriffe sind abgesichert.

Da keiner dieser drei Mechanismen mit den anderen kommuniziert, reicht eine einzelne, entsprechend präparierte Anfrage aus, um alle drei gleichzeitig zu umgehen und die interne Schnittstelle ohne jede Anmeldung zu erreichen. Die Forscher ordnen die zugrunde liegende Parser-Problematik einer Fehlerklasse zu, die bereits 2018 auf der Black Hat USA öffentlich vorgestellt wurde, hier jedoch in neuen Codepfaden der Anwendung auftaucht. Von der internen Schnittstelle aus führt der weitere Weg über die Deserialisierungsbibliothek XStream: Deren Typprüfung war so freizügig eingestellt, dass beliebige Objekttypen zugelassen wurden. In Kombination mit einer bekannten Kette weiterverwendbarer Programmierbausteine – sogenannter Gadgets – lässt sich daraus eine vollständige Codeausführung auf dem Server konstruieren, noch bevor die eigentliche Anfrage verarbeitet ist. Insgesamt setzt sich diese erste Angriffskette damit aus fünf einzelnen Schwachstellen zusammen: dem Parser-Unterschied, der Filterumgehung durch Teilübereinstimmung, der fehlenden Weiterleitungsprüfung, der zu freizügigen Deserialisierung sowie einer zusätzlichen Umgehung einer bereits bestehenden Absicherung der verwendeten Gadget-Kette.

Grafik Quelle: Novee Security

Zweite Kette: Apache OFBiz

Apache OFBiz ist eine umfassende ERP-Suite für Buchhaltung, Lagerverwaltung, Fertigung und Personalwesen, ergänzt um einen integrierten Online-Shop sowie eine Template-Engine, die Inhalte über FreeMarker und Groovy erzeugt. Die Software wird seit 2006 als Apache-Projekt geführt und ist seit über 18 Jahren unter anderem in Finanzwesen, Behörden, Fertigung und Einzelhandel im produktiven Einsatz. Als technische Grundlage dienen Java ab Version 17, Tomcat, Groovy, FreeMarker sowie eine Datenbankanbindung; die Single-Sign-On-Anmeldung erfolgt über JWT-Token, die mit dem Verfahren HMAC-SHA512 signiert werden. Die zweite von den Forschern untersuchte Angriffskette ist von der ersten vollständig unabhängig und nutzt einen anderen Ausgangspunkt: einen im öffentlichen Quellcode enthaltenen, fest hinterlegten Signaturschlüssel für genau diese JWT-Anmeldetoken. Da derselbe Schlüssel sowohl SSO-Anmeldetoken als auch interne Callback-Token der Template-Engine absichert, genügt sein Bekanntwerden, um an mehreren Stellen gleichzeitig anzusetzen.

Mit diesem öffentlich bekannten Schlüssel lässt sich ein Token erzeugen, das dem System eine gültige Administrator-Anmeldung vorgaukelt, ganz ohne Passwort, bestehende Sitzung oder mehrfache Anmeldeversuche. Sobald das System das SSO-Verfahren aktiviert hat, prüft es zwar die Signatur des Tokens, vertraut den darin enthaltenen Angaben zur Benutzerrolle danach jedoch ohne weitere Kontrolle. In einem zweiten Schritt setzen die Forscher über ihre so erlangte Administrator-Rolle eine Nutzereinstellung namens „javaScriptEnabled“, die ursprünglich der Barrierefreiheit der Benutzeroberfläche dient. Dieses Flag entscheidet serverseitig jedoch mit darüber, ob eine bestimmte Auswertungsfunktion überhaupt erreichbar ist. Ein weiteres Feld im Token, das eigentlich nur den Namen eines anzuzeigenden Seitenbereichs enthalten soll, wird von der Anwendung ungeprüft an die Template-Engine weitergereicht. Diese wertet darin enthaltene Groovy-Ausdrücke direkt aus. Eine Filterliste, die genau solche Ausdrücke abfangen sollte, greift laut den Forschern nicht zuverlässig: Sie berücksichtigt Groß- und Kleinschreibung nicht korrekt und übersieht Klassen, die von Groovy automatisch importiert werden und deshalb ohne vollständigen Namen aufgerufen werden können. Am Ende genügen den Forschern zufolge zwei einfache, nicht authentifizierte Web-Anfragen, um Code auf dem Zielsystem auszuführen: eine zur Vorbereitung, eine zur eigentlichen Ausführung. Die Lücke wurde als CVE-2026-31986 erfasst und als hochstufig eingeordnet.

Ein wiederkehrendes Muster

Trotz unterschiedlicher Produkte und Fehlerarten folgen beide Angriffsketten demselben Ablauf: Ein Routing-Fehler macht eine eigentlich interne Oberfläche erreichbar, ein Ausführungsziel wandelt diesen Zugriff in eine vollständige Codeausführung um. Nach Einschätzung der Forscher zeigt sich dieses Muster in Java-basierten Unternehmenssystemen immer wieder – etwa bei XML-Verarbeitung, die zu Serverseitigen Anfragefälschungen führt, bei Umgehungen von Sandbox-Mechanismen oder bei fehlerhafter Pfad-Normalisierung.

Für die Absicherung eigener Systeme empfehlen die Autoren, bei Prüfungen gezielt auf folgende Punkte zu achten:

Sicherheitsbeschränkungen in der Konfigurationsdatei web.xml sollten auch weitergeleitete und eingebundene Anfragen erfassen, nicht nur direkte Zugriffe.
Filter zum Ausschluss von Pfaden sollten die gesamte Zeichenkette abgleichen, keine Teilübereinstimmungen zulassen.
Signaturschlüssel dürfen nicht im Quellcode hinterlegt sein und sollten nicht mehrere unabhängige Funktionen gleichzeitig absichern.
Filterlisten, die riskante Funktionen wie eval() vor Eingaben schützen sollen, bieten selten verlässlichen Schutz vor einer echten Skript-Engine.
Einstellungen für die Benutzeroberfläche sollten niemals allein darüber entscheiden, ob serverseitig potenziell gefährlicher Code ausgeführt wird.
Deserialisierung sollte auch auf internen Schnittstellen strikt eingeschränkt werden, etwa über Positivlisten erlaubter Typen.

Warum solche Lücken schwer zu finden sind

Die einzelnen Bausteine beider Ketten wirken für sich genommen unauffällig: ein einzelnes Sonderzeichen in einer URL, eine falsch gewählte Prüffunktion, ein fehlendes Konfigurationselement, ein vergessener Standardschlüssel, ein regulärer Ausdruck ohne Beachtung der Groß- und Kleinschreibung. Automatisierte Scanner erkennen solche Muster in der Regel nicht, da keine einzelne Komponente für sich genommen fehlerhaft programmiert ist. Die eigentliche Schwachstelle entsteht erst im Zusammenspiel der Bauteile – und lässt sich nach Einschätzung der Forscher nur aufdecken, wenn man versteht, wie ein System Anfragen intern weiterleitet und wo Grenzen zwischen öffentlichen und internen Bereichen tatsächlich verlaufen.

Redaktion AllAboutSecurity

Bild: KI-generiert