GeoNetwork, due falle permettono l’RCE senza autenticazione nei geoportali pubblici

Una catena d’attacco contro il backend geospaziale

GeoNetwork ha corretto due vulnerabilità che, se combinate, consentono a un attaccante anonimo di eseguire codice sul server che ospita un geoportale. Le patch sono disponibili nelle versioni 4.4.12 e 4.2.17, rilasciate l’8 luglio 2026. I dettagli tecnici sono stati pubblicati il 31 agosto 2026.

La catena unisce un endpoint di caricamento privo di un adeguato controllo delle autorizzazioni e una configurazione insicura del processore XSLT Saxon. Il primo difetto permette di depositare un formatter malevolo sul server; il secondo trasforma quel file in un mezzo per avviare comandi del sistema operativo.

Le vulnerabilità sono indicate come:

• CVE-2026-63219, con punteggio CVSS riportato di 8.6;
• CVE-2026-58400, con punteggio CVSS riportato di 9.1.

Le schede GitHub Security Advisory associate non assegnano punteggi CVSS. I valori provengono dalla ricostruzione giornalistica della vicenda.

GeoNetwork è un catalogo open source per metadati geospaziali, nato presso la Food and Agriculture Organization delle Nazioni Unite e mantenuto sotto l’egida della Open Source Geospatial Foundation (OSGeo). Viene utilizzato come componente backend di infrastrutture di dati spaziali e geoportali pubblici, compreso il sistema europeo INSPIRE.

L’upload anonimo apre la strada al file XSLT malevolo

La prima falla, CVE-2026-63219, riguarda l’endpoint usato per caricare i formatter di GeoNetwork. L’assenza di un controllo di autorizzazione permette a un utente non autenticato di inviare file con estensione .xsl o .zip, che vengono salvati nella directory dedicata.

Il problema è documentato nell’advisory GHSA-mh22-prqr-vf42 e interessa i seguenti pacchetti Maven:

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

Le versioni vulnerabili indicate sono:

• GeoNetwork 4.4.x fino alla 4.4.11 inclusa;
• GeoNetwork 4.2.x fino alla 4.2.16 inclusa.

Anche senza concatenarla con altri difetti, la vulnerabilità consente una scrittura non autorizzata nello storage dell’applicazione. In questo caso, però, il contenuto caricato può essere successivamente interpretato da un componente capace di interagire con Java.

Secondo il vendor di sicurezza Ethiack, la raggiungibilità della catena risalirebbe alla ristrutturazione dell’endpoint dei formatter introdotta con la versione 4.0.6, durante la quale sarebbe stata rimossa la verifica delle autorizzazioni. La scoperta è attribuita al ricercatore Rafael Castilho.

Per le attività di censimento e remediation devono comunque essere usati gli intervalli confermati dalle advisory: i rami 4.4.x e 4.2.x fino alle rispettive versioni vulnerabili indicate.

Saxon trasforma il formatter in esecuzione di comandi

Il secondo problema, CVE-2026-58400, si trova nel modo in cui GeoNetwork configura Saxon, il processore impiegato per le trasformazioni XSLT. Un foglio di stile elaborato sul server può raggiungere funzioni Java utilizzabili per creare processi, tra cui:

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

Un aggressore può quindi inserire nel formatter istruzioni che avviano comandi sul sistema operativo. Il codice viene eseguito con i privilegi dell’account che gestisce il processo GeoNetwork, non necessariamente con privilegi amministrativi sul sistema.

L’advisory GHSA-x898-729x-cc3r segnala come interessato il pacchetto Maven:

org.geonetwork-opensource:gs-web-app

Anche per questa vulnerabilità risultano vulnerabili GeoNetwork fino alla 4.4.11 e fino alla 4.2.16, mentre le correzioni sono incluse nelle versioni 4.4.12 e 4.2.17.

La configurazione descritta prevede il secure processing abilitato e le estensioni Java disattivate. Nonostante queste impostazioni, il formatter riuscirebbe comunque a raggiungere le primitive necessarie all’esecuzione dei comandi.

Presa isolatamente, CVE-2026-58400 richiede che l’aggressore possa già caricare un formatter. CVE-2026-63219 elimina proprio questo prerequisito, rendendo l’intera sequenza accessibile senza credenziali.

L’attacco si sviluppa in sei passaggi:

1. viene inviato un formatter XSLT malevolo all’endpoint non protetto;
2. GeoNetwork salva il file nella directory dei formatter;
3. l’attaccante richiede tramite GET un record pubblico;
4. la visualizzazione del record attiva Saxon;
5. il foglio XSLT richiama Runtime.exec() o ProcessBuilder;
6. il comando viene eseguito dal backend con i privilegi del servizio GeoNetwork.

Una compromissione potrebbe esporre dati, configurazioni e credenziali accessibili all’applicazione. Il server potrebbe inoltre diventare un punto d’appoggio per muoversi nell’infrastruttura che ospita la Spatial Data Infrastructure.

Centinaia di installazioni esposte, ma nessuna vittima confermata

Ethiack ha dichiarato di avere individuato 121 deployment GeoNetwork esposti su Internet e vulnerabili, distribuiti in 39 Paesi. Secondo la stessa rilevazione, l’89% delle istanze riconosciute tramite fingerprinting sarebbe riconducibile a enti governativi, organizzazioni militari o agenzie nazionali.

Questi numeri non corrispondono a 121 compromissioni. Descrivono sistemi che sarebbero raggiungibili e dotati di versioni vulnerabili, sulla base della stima di un singolo vendor.

Non sono state rese note prove pubbliche di sfruttamento della catena in attacchi reali. Al momento della divulgazione, CVE-2026-63219 e CVE-2026-58400 non risultavano inoltre presenti nel catalogo Known Exploited Vulnerabilities (KEV) della CISA.

L’assenza dal KEV significa che non era disponibile una conferma CISA di sfruttamento attivo. Non riduce però la gravità tecnica: l’endpoint è raggiungibile da remoto, il primo passaggio non richiede autenticazione e l’attivazione può avvenire attraverso la richiesta di un record pubblico.

Aggiornamento immediato e blocco temporaneo dell’endpoint

La correzione risolutiva consiste nell’aggiornare GeoNetwork a una delle release protette:

• 4.4.12 per le installazioni sul ramo 4.4.x;
• 4.2.17 per quelle sul ramo 4.2.x.

Chi non può applicare subito la patch dovrebbe impedire tramite reverse proxy le operazioni di scrittura verso:

/geonetwork/srv/api/formatters

Su Apache httpd devono essere negate, per questo percorso, le richieste:

• POST;
• PUT;
• PATCH.

Su Nginx la mitigazione proposta consiste nel consentire esclusivamente:

• GET;
• HEAD;
• OPTIONS.

La restrizione interferisce anche con le attività legittime: gli amministratori non potranno caricare formatter dalla console finché il blocco resterà attivo.

Non sono disponibili indicatori di compromissione specifici. Le verifiche dovrebbero concentrarsi sui log del reverse proxy e dell’applicazione, cercando upload di file .xsl o .zip verso l’endpoint dei formatter.

Meritano attenzione anche le richieste GET a record pubblici immediatamente successive a un caricamento. Sul sistema operativo vanno poi controllati processi, shell o comandi insoliti avviati dall’account di servizio GeoNetwork.

I precedenti di GeoServer già entrati nel catalogo KEV

Il caso si inserisce in una serie di vulnerabilità che ha coinvolto anche GeoServer, altro software centrale nelle infrastrutture geospaziali.

CVE-2024-36401, con CVSS 9.8, permetteva l’RCE non autenticata attraverso parametri OGC manipolati e la valutazione insicura di espressioni XPath. Ha interessato GeoServer precedente alla 2.22.6 e GeoTools precedente alla 29.6; le correzioni GeoServer indicate comprendono anche le versioni 2.23.6, 2.24.4 e 2.25.2.

La vulnerabilità è nel catalogo CISA KEV dal 15 luglio 2024, con scadenza di remediation per le agenzie federali statunitensi fissata al 5 agosto 2024. CISA ha richiesto di applicare le mitigazioni del vendor oppure interrompere l’uso del prodotto in loro assenza. La falla è stata associata ad attacchi condotti da botnet, miner di criptovaluta e dal backdoor SideWalk.

Anche CVE-2025-58360, una vulnerabilità XXE con CVSS 8.2, è entrata nel KEV. Il difetto riguardava input XML inviati all’operazione GetMap di /geoserver/wms ed è stato corretto in GeoServer 2.25.6, 2.26.3 e 2.27.0.

CVE-2025-58360 è presente nel catalogo dal 11 dicembre 2025, con scadenza federale al 1 gennaio 2026. CISA ha richiesto le mitigazioni del vendor, l’applicazione delle indicazioni pertinenti del BOD 22-01 per i servizi cloud oppure l’interruzione dell’uso quando non siano disponibili contromisure.

Per GeoNetwork non esiste al momento della divulgazione un’analoga evidenza pubblica di sfruttamento. La combinazione tra upload anonimo e trasformazioni XSLT lato server impone comunque di trattare l’aggiornamento come prioritario, soprattutto sui geoportali direttamente esposti a Internet.