GeoNetwork : deux failles permettent une RCE sans authentification sur les géoportails publics

Une chaîne d’attaque visant le backend géospatial

GeoNetwork a corrigé deux vulnérabilités qui, combinées, permettent à un attaquant anonyme d’exécuter du code sur le serveur hébergeant un géoportail. Les correctifs sont disponibles dans les versions 4.4.12 et 4.2.17, publiées le 8 juillet 2026. Les détails techniques ont été rendus publics le 31 août 2026.

La chaîne d’attaque combine un endpoint d’upload dépourvu d’un contrôle d’autorisation adéquat et une configuration non sécurisée du processeur XSLT Saxon. La première faille permet de déposer un formatter malveillant sur le serveur ; la seconde transforme ce fichier en moyen d’exécuter des commandes du système d’exploitation.

Les vulnérabilités sont référencées comme suit :

• CVE-2026-63219, avec un score CVSS annoncé de 8.6 ;
• CVE-2026-58400, avec un score CVSS annoncé de 9.1.

Les fiches GitHub Security Advisory associées n’attribuent aucun score CVSS. Ces valeurs proviennent de la reconstitution journalistique de l’affaire.

GeoNetwork est un catalogue open source de métadonnées géospatiales, créé au sein de la Food and Agriculture Organization des Nations unies et maintenu sous l’égide de l’Open Source Geospatial Foundation (OSGeo). Il est utilisé comme composant backend d’infrastructures de données spatiales et de géoportails publics, notamment dans le système européen INSPIRE.

L’upload anonyme ouvre la voie au fichier XSLT malveillant

La première faille, CVE-2026-63219, concerne l’endpoint utilisé pour charger les formatters de GeoNetwork. En l’absence de contrôle d’autorisation, un utilisateur non authentifié peut envoyer des fichiers portant l’extension .xsl ou .zip, qui sont enregistrés dans le répertoire dédié.

Le problème est documenté dans l’advisory GHSA-mh22-prqr-vf42 et concerne les paquets Maven suivants :

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

Les versions vulnérables indiquées sont les suivantes :

• GeoNetwork 4.4.x jusqu’à la 4.4.11 incluse ;
• GeoNetwork 4.2.x jusqu’à la 4.2.16 incluse.

Même sans être combinée à d’autres failles, cette vulnérabilité permet une écriture non autorisée dans le stockage de l’application. Dans ce cas, le contenu chargé peut toutefois être ensuite interprété par un composant capable d’interagir avec Java.

Selon le fournisseur de sécurité Ethiack, l’origine de cette chaîne remonterait à la refonte de l’endpoint des formatters introduite avec la version 4.0.6, au cours de laquelle la vérification des autorisations aurait été supprimée. La découverte est attribuée au chercheur Rafael Castilho.

Pour les opérations d’inventaire et de remédiation, il convient néanmoins d’utiliser les plages de versions confirmées par les advisories : les branches 4.4.x et 4.2.x jusqu’aux versions vulnérables respectives qui y sont indiquées.

Saxon transforme le formatter en exécution de commandes

Le deuxième problème, CVE-2026-58400, réside dans la manière dont GeoNetwork configure Saxon, le processeur utilisé pour les transformations XSLT. Une feuille de style traitée sur le serveur peut accéder à des fonctions Java permettant de créer des processus, notamment :

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

Un attaquant peut donc intégrer dans le formatter des instructions lançant des commandes sur le système d’exploitation. Le code est exécuté avec les privilèges du compte qui gère le processus GeoNetwork, sans disposer nécessairement de privilèges administratifs sur le système.

L’advisory GHSA-x898-729x-cc3r signale comme concerné le paquet Maven suivant :

org.geonetwork-opensource:gs-web-app

Cette vulnérabilité concerne également les versions de GeoNetwork jusqu’à la 4.4.11 et jusqu’à la 4.2.16, tandis que les correctifs sont inclus dans les versions 4.4.12 et 4.2.17.

La configuration décrite prévoit l’activation du secure processing et la désactivation des extensions Java. Malgré ces paramètres, le formatter pourrait toujours accéder aux primitives nécessaires à l’exécution de commandes.

Prise isolément, la CVE-2026-58400 exige que l’attaquant puisse déjà charger un formatter. La CVE-2026-63219 supprime précisément ce prérequis, rendant toute la séquence accessible sans identifiants.

L’attaque se déroule en six étapes :

1. un formatter XSLT malveillant est envoyé à l’endpoint non protégé ;
2. GeoNetwork enregistre le fichier dans le répertoire des formatters ;
3. l’attaquant demande, via GET, un enregistrement public ;
4. l’affichage de l’enregistrement déclenche Saxon ;
5. la feuille XSLT appelle Runtime.exec() ou ProcessBuilder ;
6. la commande est exécutée par le backend avec les privilèges du service GeoNetwork.

Une compromission pourrait exposer les données, les configurations et les identifiants accessibles par l’application. Le serveur pourrait également devenir un point d’appui pour se déplacer latéralement dans l’infrastructure hébergeant la Spatial Data Infrastructure.

Des centaines d’installations exposées, mais aucune victime confirmée

Ethiack a déclaré avoir identifié 121 déploiements GeoNetwork exposés sur Internet et vulnérables, répartis dans 39 pays. Selon cette même analyse, 89 % des instances identifiées par fingerprinting seraient rattachées à des entités gouvernementales, des organisations militaires ou des agences nationales.

Ces chiffres ne correspondent pas à 121 compromissions. Ils désignent des systèmes qui seraient accessibles et exécuteraient des versions vulnérables, selon l’estimation d’un seul fournisseur.

Aucune preuve publique d’exploitation de cette chaîne dans le cadre d’attaques réelles n’a été communiquée. Au moment de la divulgation, CVE-2026-63219 et CVE-2026-58400 ne figuraient pas non plus dans le catalogue Known Exploited Vulnerabilities (KEV) de la CISA.

L’absence du catalogue KEV signifie qu’aucune confirmation de la CISA concernant une exploitation active n’était disponible. Elle ne réduit toutefois pas la gravité technique : l’endpoint est accessible à distance, la première étape ne requiert aucune authentification et le déclenchement peut s’effectuer via la demande d’un enregistrement public.

Mise à jour immédiate et blocage temporaire de l’endpoint

Le correctif consiste à mettre GeoNetwork à niveau vers l’une des versions sécurisées suivantes :

• 4.4.12 pour les installations de la branche 4.4.x ;
• 4.2.17 pour celles de la branche 4.2.x.

Les organisations qui ne peuvent pas appliquer immédiatement le correctif devraient bloquer, via le reverse proxy, les opérations d’écriture vers :

/geonetwork/srv/api/formatters

Avec Apache httpd, les requêtes suivantes doivent être refusées pour ce chemin :

• POST ;
• PUT ;
• PATCH.

Avec Nginx, la mesure de protection proposée consiste à n’autoriser que :

• GET ;
• HEAD ;
• OPTIONS.

Cette restriction perturbera également les opérations légitimes : les administrateurs ne pourront plus charger de formatters depuis la console tant que le blocage sera actif.

Aucun indicateur de compromission spécifique n’est disponible. Les vérifications doivent se concentrer sur les journaux du reverse proxy et de l’application, en recherchant les uploads de fichiers .xsl ou .zip vers l’endpoint des formatters.

Les requêtes GET vers des enregistrements publics effectuées immédiatement après un chargement méritent également une attention particulière. Au niveau du système d’exploitation, il convient ensuite de rechercher les processus, shells ou commandes inhabituels lancés par le compte de service GeoNetwork.

Les précédents de GeoServer déjà inscrits au catalogue KEV

Cette affaire s’inscrit dans une série de vulnérabilités ayant également touché GeoServer, un autre logiciel central des infrastructures géospatiales.

CVE-2024-36401, avec un score CVSS de 9.8, permettait une RCE sans authentification via des paramètres OGC manipulés et l’évaluation non sécurisée d’expressions XPath. Elle concernait les versions de GeoServer antérieures à la 2.22.6 et celles de GeoTools antérieures à la 29.6 ; les correctifs GeoServer incluaient également les versions 2.23.6, 2.24.4 et 2.25.2.

Cette vulnérabilité figure dans le catalogue KEV de la CISA depuis le 15 juillet 2024, avec une échéance de remédiation fixée au 5 août 2024 pour les agences fédérales américaines. La CISA a demandé d’appliquer les mesures d’atténuation du fournisseur ou, à défaut, de cesser d’utiliser le produit. La faille a été associée à des attaques menées par des botnets, des mineurs de cryptomonnaie et la backdoor SideWalk.

La CVE-2025-58360, une vulnérabilité XXE affichant un score CVSS de 8.2, a également été ajoutée au catalogue KEV. Le problème concernait les entrées XML envoyées à l’opération GetMap de /geoserver/wms et a été corrigé dans GeoServer 2.25.6, 2.26.3 et 2.27.0.

La CVE-2025-58360 figure dans le catalogue depuis le 11 décembre 2025, avec une échéance fédérale fixée au 1er janvier 2026. La CISA a demandé d’appliquer les mesures d’atténuation du fournisseur, de mettre en œuvre les recommandations pertinentes du BOD 22-01 pour les services cloud ou de cesser d’utiliser le produit lorsqu’aucune contre-mesure n’est disponible.

Pour GeoNetwork, aucune preuve publique comparable d’exploitation n’existait au moment de la divulgation. La combinaison d’un upload anonyme et de transformations XSLT côté serveur impose néanmoins de traiter la mise à jour comme prioritaire, en particulier pour les géoportails directement exposés à Internet.