GeoNetwork: Zwei Schwachstellen ermöglichen unauthentifizierte RCE in öffentlichen Geoportalen

Eine Angriffskette gegen das Geodaten-Backend

GeoNetwork hat zwei Schwachstellen behoben, die in Kombination einem anonymen Angreifer die Ausführung von Code auf dem Server eines Geoportals ermöglichen. Die Patches sind in den am 8. Juli 2026 veröffentlichten Versionen 4.4.12 und 4.2.17 enthalten. Technische Details wurden am 31. August 2026 veröffentlicht.

Die Angriffskette kombiniert einen Upload-Endpunkt ohne ausreichende Berechtigungsprüfung mit einer unsicheren Konfiguration des XSLT-Prozessors Saxon. Der erste Fehler ermöglicht es, einen manipulierten Formatter auf dem Server abzulegen; der zweite macht diese Datei zu einem Mittel, um Betriebssystembefehle auszuführen.

Die Schwachstellen werden wie folgt geführt:

• CVE-2026-63219 mit einem angegebenen CVSS-Score von 8.6;
• CVE-2026-58400 mit einem angegebenen CVSS-Score von 9.1.

Die zugehörigen GitHub Security Advisories weisen keine CVSS-Scores aus. Die genannten Werte stammen aus der journalistischen Rekonstruktion des Falls.

GeoNetwork ist ein Open-Source-Katalog für Geodaten-Metadaten. Das Projekt entstand bei der Ernährungs- und Landwirtschaftsorganisation der Vereinten Nationen (FAO) und wird unter dem Dach der Open Source Geospatial Foundation (OSGeo) gepflegt. GeoNetwork dient als Backend-Komponente von Geodateninfrastrukturen und öffentlichen Geoportalen, darunter auch dem europäischen System INSPIRE.

Anonymer Upload ebnet den Weg für eine manipulierte XSLT-Datei

Die erste Schwachstelle, CVE-2026-63219, betrifft den Endpunkt zum Hochladen von GeoNetwork-Formattern. Da eine Berechtigungsprüfung fehlt, kann ein nicht authentifizierter Benutzer Dateien mit der Endung .xsl oder .zip übermitteln. Diese werden im dafür vorgesehenen Verzeichnis gespeichert.

Das Problem ist im Advisory GHSA-mh22-prqr-vf42 dokumentiert und betrifft die folgenden Maven-Pakete:

• org.geonetwork-opensource:gn-services
• org.geonetwork-opensource:gn-web-app

Als verwundbar gelten:

• GeoNetwork 4.4.x bis einschließlich 4.4.11;
• GeoNetwork 4.2.x bis einschließlich 4.2.16.

Auch ohne Verkettung mit weiteren Fehlern ermöglicht die Schwachstelle ein unautorisiertes Schreiben in den Anwendungsspeicher. In diesem Fall kann der hochgeladene Inhalt jedoch anschließend von einer Komponente verarbeitet werden, die mit Java interagieren kann.

Nach Angaben des Sicherheitsanbieters Ethiack geht die Erreichbarkeit der Angriffskette auf die mit Version 4.0.6 eingeführte Überarbeitung des Formatter-Endpunkts zurück. Dabei soll die Berechtigungsprüfung entfernt worden sein. Die Entdeckung wird dem Forscher Rafael Castilho zugeschrieben.

Für Bestandsaufnahme und Behebung sollten dennoch die in den Advisories bestätigten Versionsbereiche herangezogen werden: die Zweige 4.4.x und 4.2.x bis zu den jeweils genannten verwundbaren Versionen.

Saxon macht den Formatter zur Grundlage für die Befehlsausführung

Die zweite Schwachstelle, CVE-2026-58400, betrifft die Konfiguration von Saxon, dem von GeoNetwork eingesetzten Prozessor für XSLT-Transformationen. Ein auf dem Server verarbeitetes Stylesheet kann Java-Funktionen erreichen, die sich zum Erzeugen von Prozessen verwenden lassen, darunter:

• java.lang.Runtime.exec();
• java.lang.ProcessBuilder.

Ein Angreifer kann daher Anweisungen in den Formatter einfügen, die Befehle auf dem Betriebssystem starten. Der Code wird mit den Berechtigungen des Kontos ausgeführt, unter dem der GeoNetwork-Prozess läuft, nicht zwangsläufig mit administrativen Systemrechten.

Das Advisory GHSA-x898-729x-cc3r nennt das folgende Maven-Paket als betroffen:

org.geonetwork-opensource:gs-web-app

Auch bei dieser Schwachstelle gelten GeoNetwork-Versionen bis 4.4.11 und bis 4.2.16 als verwundbar. Die Fehlerbehebungen sind in den Versionen 4.4.12 und 4.2.17 enthalten.

Die beschriebene Konfiguration sieht aktivierte Secure Processing-Funktionen und deaktivierte Java-Erweiterungen vor. Trotz dieser Einstellungen soll der Formatter weiterhin auf die für die Befehlsausführung erforderlichen Primitive zugreifen können.

Für sich allein setzt CVE-2026-58400 voraus, dass der Angreifer bereits einen Formatter hochladen kann. CVE-2026-63219 beseitigt genau diese Voraussetzung und macht die gesamte Angriffskette ohne Zugangsdaten nutzbar.

Der Angriff läuft in sechs Schritten ab:

1. Ein manipulierter XSLT-Formatter wird an den ungeschützten Endpunkt gesendet.
2. GeoNetwork speichert die Datei im Formatter-Verzeichnis.
3. Der Angreifer ruft per GET einen öffentlichen Datensatz ab.
4. Die Anzeige des Datensatzes aktiviert Saxon.
5. Das XSLT-Stylesheet ruft Runtime.exec() oder ProcessBuilder auf.
6. Das Kommando wird vom Backend mit den Berechtigungen des GeoNetwork-Dienstkontos ausgeführt.

Eine Kompromittierung könnte Daten, Konfigurationen und für die Anwendung zugängliche Zugangsdaten offenlegen. Der Server könnte außerdem als Ausgangspunkt für die weitere Bewegung innerhalb der Infrastruktur dienen, in der die Geodateninfrastruktur betrieben wird.

Hunderte exponierte Installationen, aber kein bestätigtes Opfer

Ethiack gab an, 121 über das Internet erreichbare und verwundbare GeoNetwork-Deployments identifiziert zu haben, verteilt auf 39 Länder. Nach derselben Erhebung sollen 89 % der per Fingerprinting erkannten Instanzen Regierungsbehörden, militärischen Organisationen oder nationalen Agenturen zuzuordnen sein.

Diese Zahlen entsprechen nicht 121 Kompromittierungen. Sie beschreiben Systeme, die auf Grundlage der Einschätzung eines einzelnen Anbieters erreichbar sein und verwundbare Versionen ausführen sollen.

Öffentlich zugängliche Belege für die Ausnutzung der Angriffskette in realen Angriffen wurden nicht veröffentlicht. Zum Zeitpunkt der Offenlegung waren CVE-2026-63219 und CVE-2026-58400 außerdem nicht im Known Exploited Vulnerabilities (KEV)-Katalog der CISA enthalten.

Das Fehlen im KEV-Katalog bedeutet, dass keine Bestätigung der CISA für eine aktive Ausnutzung vorlag. Die technische Schwere wird dadurch jedoch nicht gemindert: Der Endpunkt ist aus der Ferne erreichbar, der erste Schritt erfordert keine Authentifizierung und die Ausführung kann durch den Abruf eines öffentlichen Datensatzes ausgelöst werden.

Sofort aktualisieren und Endpunkt vorübergehend sperren

Die nachhaltige Abhilfe besteht darin, GeoNetwork auf eine der abgesicherten Versionen zu aktualisieren:

• 4.4.12 für Installationen im 4.4.x-Zweig;
• 4.2.17 für Installationen im 4.2.x-Zweig.

Wer den Patch nicht sofort einspielen kann, sollte über den Reverse Proxy Schreiboperationen für den folgenden Pfad blockieren:

/geonetwork/srv/api/formatters

Unter Apache httpd sollten für diesen Pfad folgende Anfragemethoden verweigert werden:

• POST;
• PUT;
• PATCH.

Unter Nginx besteht die vorgeschlagene Gegenmaßnahme darin, ausschließlich folgende Methoden zuzulassen:

• GET;
• HEAD;
• OPTIONS.

Die Einschränkung beeinträchtigt auch legitime Vorgänge: Administratoren können über die Konsole keine Formatter hochladen, solange die Sperre aktiv ist.

Spezifische Indicators of Compromise liegen nicht vor. Die Überprüfung sollte sich auf die Logs des Reverse Proxys und der Anwendung konzentrieren. Gesucht werden sollten Uploads von .xsl- oder .zip-Dateien an den Formatter-Endpunkt.

Besondere Aufmerksamkeit verdienen außerdem GET-Anfragen auf öffentliche Datensätze, die unmittelbar auf einen Upload folgen. Auf Betriebssystemebene sollten zudem ungewöhnliche Prozesse, Shells oder Befehle überprüft werden, die vom GeoNetwork-Dienstkonto gestartet wurden.

Frühere GeoServer-Schwachstellen bereits im KEV-Katalog

Der Fall reiht sich in eine Serie von Schwachstellen ein, von denen auch GeoServer, eine weitere zentrale Softwarekomponente in Geodateninfrastrukturen, betroffen war.

CVE-2024-36401 mit einem CVSS-Score von 9.8 ermöglichte eine unauthentifizierte RCE über manipulierte OGC-Parameter und die unsichere Auswertung von XPath-Ausdrücken. Betroffen waren GeoServer-Versionen vor 2.22.6 und GeoTools-Versionen vor 29.6. Zu den genannten korrigierten GeoServer-Versionen gehören außerdem 2.23.6, 2.24.4 und 2.25.2.

Die Schwachstelle steht seit dem 15. Juli 2024 im CISA-KEV-Katalog. Als Frist für die Behebung durch US-Bundesbehörden wurde der 5. August 2024 festgelegt. Die CISA forderte dazu auf, die Gegenmaßnahmen des Herstellers umzusetzen oder das Produkt andernfalls nicht weiter zu verwenden. Die Schwachstelle wurde mit Angriffen durch Botnetze, Kryptominer und die Backdoor SideWalk in Verbindung gebracht.

Auch CVE-2025-58360, eine XXE-Schwachstelle mit einem CVSS-Score von 8.2, wurde in den KEV-Katalog aufgenommen. Der Fehler betraf XML-Eingaben, die an die Operation GetMap unter /geoserver/wms gesendet wurden, und wurde in GeoServer 2.25.6, 2.26.3 und 2.27.0 behoben.

CVE-2025-58360 ist seit dem 11. Dezember 2025 im Katalog enthalten; die Frist für US-Bundesbehörden lief am 1. Januar 2026 ab. Die CISA forderte die Umsetzung der Herstellermaßnahmen, die Anwendung der einschlägigen Vorgaben aus BOD 22-01 für Cloud-Dienste oder die Einstellung der Nutzung, falls keine Gegenmaßnahmen verfügbar sind.

Für GeoNetwork lagen zum Zeitpunkt der Offenlegung keine vergleichbaren öffentlichen Belege für eine Ausnutzung vor. Die Kombination aus anonymem Upload und serverseitigen XSLT-Transformationen erfordert dennoch eine priorisierte Aktualisierung, insbesondere bei direkt aus dem Internet erreichbaren Geoportalen.