Dropbox violato tramite Lenovo ID, GeoNetwork espone una RCE senza autenticazione

🛡️ Executive Summary

• Circa 5.000 account Dropbox sono stati compromessi sfruttando una falla nella verifica email della vecchia integrazione Lenovo ID.
• Gli attaccanti potevano creare un Lenovo ID con l’email della vittima e accedere a Dropbox senza conoscere la password dell’account.
• GeoNetwork corregge CVE-2026-63219 e CVE-2026-58400, concatenabili per ottenere esecuzione di codice remoto senza autenticazione.

Due incidenti differenti mostrano quanto la fiducia delegata tra sistemi possa diventare un vettore di compromissione più pericoloso della singola password. Dropbox ha confermato accessi non autorizzati a circa 5.000 account attraverso una vecchia integrazione con Lenovo ID: un errore nella verifica dell’indirizzo email consentiva di creare un’identità Lenovo usando l’email di un’altra persona e sfruttarla per autenticarsi sul relativo account Dropbox. Contemporaneamente GeoNetwork, piattaforma open source utilizzata dietro numerosi geoportali governativi, ha corretto due vulnerabilità concatenabili che trasformano un upload anonimo di file XSLT in una RCE pre-authentication. In entrambi i casi il sistema vulnerabile finisce per fidarsi di un’informazione o di un componente che non avrebbe dovuto considerare sufficientemente attendibile.

Un Lenovo ID falso bastava per entrare nell’account Dropbox

La prima segnalazione pubblica nasce direttamente da Yoni Levy, sviluppatore e utente coinvolto che il 31 agosto ha pubblicato su X la comunicazione ricevuta da Dropbox dopo avere rilevato un accesso anomalo proveniente dall’area di Canary Wharf, nel Regno Unito. Levy non aveva mai creato un account Lenovo e proprio questo particolare ha permesso di ricostruire il meccanismo. Dropbox utilizzava Lenovo Identity Provider Services all’interno di una vecchia integrazione che permetteva l’accesso tramite Lenovo ID. Una falla nel processo Lenovo consentiva però a un soggetto non autorizzato di registrare un nuovo Lenovo ID utilizzando l’indirizzo email appartenente alla vittima. Dropbox riceveva quindi dal provider esterno l’informazione secondo cui quell’identità controllava realmente l’indirizzo e associava la sessione al Dropbox corrispondente, senza richiedere la password originale del servizio. Gli accessi non autorizzati sono avvenuti tra il 4 e il 21 agosto 2026 e hanno interessato circa 5.000 account privi della protezione a due fattori di Dropbox; in meno di un terzo dei casi gli aggressori avrebbero anche visualizzato o scaricato file. Il punto tecnico più grave non consiste quindi in una password debole o rubata, ma nel fatto che una verifica errata a monte presso un Identity Provider è diventata sufficiente per assumere il controllo dell’identità a valle.

Il caso ricorda per logica la recente vulnerabilità Keycloak che permetteva di prendere il controllo degli account saltando la verifica email nel reset delle credenziali. In entrambi gli scenari la crittografia e la password non vengono necessariamente compromesse: viene violata la state machine della fiducia, cioè la sequenza che dovrebbe dimostrare che chi presenta un’identità possieda realmente il fattore richiesto per utilizzarla. Quando un servizio federato accetta il possesso dichiarato di un indirizzo email come prova sufficiente, una falla nel provider esterno può propagarsi automaticamente all’applicazione che lo considera autorevole.

Leggi anche: ShinyHunters colpisce ReliaQuest ma il device trust blocca il furto dei dati

Dropbox chiude la vecchia integrazione e rende obbligatoria anche la password

Dropbox e Lenovo hanno modificato il flusso dopo avere individuato l’incidente. Dropbox ha fatto scadere tutte le sessioni autenticate attraverso Lenovo ID, eliminato i collegamenti esistenti e imposto l’inserimento della password Dropbox anche quando viene utilizzata l’identità Lenovo. Lenovo ha descritto il problema come legato a una legacy integration che poteva essere sfruttata per autenticare impropriamente determinati account Dropbox, precisando che i propri clienti non risultavano direttamente compromessi dalla vicenda. La correzione è significativa perché elimina proprio l’assunzione che aveva reso possibile il takeover: la corrispondenza dell’indirizzo email fornita dal provider federato non costituisce più da sola una prova sufficiente per aprire una sessione Dropbox. L’incidente mostra anche perché MFA e identity linking debbano essere trattati come livelli separati. La doppia autenticazione avrebbe protetto gli account interessati, ma la progettazione corretta non dovrebbe dipendere esclusivamente dal fatto che l’utente abbia attivato volontariamente un secondo fattore per compensare una verifica insufficiente tra due servizi.

Dal punto di vista della risposta, gli utenti che hanno ricevuto una notifica devono controllare le sessioni recenti, verificare file visualizzati o modificati, revocare dispositivi sconosciuti e considerare la rotazione delle credenziali utilizzate in documenti eventualmente esposti. Particolare attenzione va riservata agli account Dropbox aziendali, nei quali un singolo archivio può contenere contratti, password salvate impropriamente, documentazione interna o token utilizzabili per muoversi verso altre infrastrutture.

GeoNetwork concatena un upload anonimo con il motore XSLT e arriva alla RCE

Il secondo problema è completamente diverso ma nasce dalla stessa categoria generale di errore: un componente riceve più fiducia di quanto dovrebbe. GeoNetwork è un catalogo open source per metadata geospaziali nato nell’ambito della FAO e oggi mantenuto nell’ecosistema OSGeo. Viene utilizzato per Spatial Data Infrastructure, portali pubblici, agenzie ambientali e infrastrutture cartografiche. Il ricercatore Rafael Castilho di Ethiack ha documentato direttamente la catena pre-authentication composta da CVE-2026-63219, valutata CVSS 8.6, e CVE-2026-58400, CVSS 9.1. La prima vulnerabilità nasce dalla mancanza del controllo di autorizzazione nell’endpoint utilizzato per creare nuovi formatter: una funzione amministrativa che dovrebbe richiedere privilegi permette invece a un utente anonimo di caricare file .xsl o .zip nella directory dei formatter. Il problema sarebbe stato introdotto con il refactoring avvenuto nella versione 4.0.6, quando una protezione @PreAuthorize presente sul vecchio percorso non è stata riportata sul nuovo metodo.

La seconda falla riguarda Saxon, motore XSLT utilizzato da GeoNetwork per trasformare i metadata. Il security advisory originale di GeoNetwork spiega che il processor consentiva alle stylesheet di richiamare funzioni Java esterne come java.lang.Runtime.exec() o java.lang.ProcessBuilder. Normalmente questo difetto richiederebbe privilegi elevati perché soltanto un amministratore dovrebbe poter caricare un formatter. CVE-2026-63219 elimina però quel requisito: l’attaccante anonimo carica l’XSLT malevolo e successivamente richiama un record pubblico utilizzando il formatter appena installato, costringendo GeoNetwork a processarlo e ottenendo esecuzione di comandi con i privilegi del processo applicativo.

Il bersaglio sono soprattutto geoportali governativi e infrastrutture pubbliche

L’esposizione rende la catena particolarmente delicata. Ethiack ha identificato 121 deployment GeoNetwork vulnerabili raggiungibili da Internet in 39 Paesi o regioni, con l’89% riconducibile a governi, strutture militari o agenzie nazionali; il 77,7% delle istanze analizzate apparteneva inoltre a infrastrutture europee o rivolte a organizzazioni internazionali. Questi numeri rappresentano sistemi esposti e identificati dal ricercatore, non compromissioni confermate. Non risultano al momento evidenze pubbliche di sfruttamento attivo né l’inserimento delle due CVE nel catalogo CISA KEV. La situazione merita comunque attenzione perché il settore geospaziale ha già mostrato una superficie d’attacco concreta: GeoServer è stato recentemente bersaglio di probing ed exploit contro vulnerabilità che consentivano RCE, dimostrando come componenti poco visibili dietro portali cartografici possano trasformarsi in punti d’ingresso verso infrastrutture pubbliche. Sono vulnerabili le release 4.4.x fino alla 4.4.11 e 4.2.x fino alla 4.2.16. Le versioni corrette sono GeoNetwork 4.4.12 e 4.2.17, pubblicate l’8 luglio, mentre i dettagli tecnici sono stati divulgati il 31 agosto dopo avere lasciato agli operatori una finestra per aggiornare. Il primo advisory ufficiale suggerisce, quando l’upgrade non sia immediatamente possibile, di bloccare al reverse proxy i metodi POST, PUT e PATCH sull’endpoint /geonetwork/srv/api/formatters. La mitigazione impedisce anche agli amministratori legittimi di caricare formatter attraverso la stessa API, ma interrompe il primo passaggio necessario alla catena pre-auth.

Continua con:

• CISA segnala Oracle mentre miniOrange e Calix aprono falle senza autenticazione
• GitLab sfruttato in pochi giorni ed Entra ID colpito da una RCE CVSS 10

La fiducia delegata è diventata una superficie d’attacco autonoma

Dropbox e GeoNetwork sembrano incidenti senza relazione: uno riguarda un servizio cloud e un Identity Provider, l’altro un software geospaziale open source. Il punto comune emerge però osservando dove viene spezzata la catena di sicurezza. Dropbox si fidava dell’affermazione Lenovo secondo cui un determinato utente controllava un indirizzo email; GeoNetwork si fidava del fatto che soltanto un soggetto autorizzato potesse caricare un formatter e quindi lasciava al motore XSLT una capacità estremamente potente. In entrambi i casi una premessa considerata implicitamente valida diventa il punto dal quale l’attaccante aggira il controllo successivo. Per questo i sistemi moderni non possono essere valutati soltanto chiedendo se una password sia robusta o se un endpoint richieda HTTPS. Occorre ricostruire quali affermazioni di sicurezza vengono importate da servizi esterni, quali privilegi vengono ereditati e quali componenti diventano raggiungibili quando uno dei passaggi precedenti fallisce. Il breach Dropbox dimostra che una vulnerabilità nella verifica email di un provider può rendere irrilevante la password di un altro servizio. GeoNetwork dimostra invece che una sola riga di autorizzazione dimenticata può trasformare una funzionalità amministrativa per XSLT in una shell remota anonima. La superficie d’attacco più critica non è quindi sempre il componente più esposto: spesso è il confine di fiducia tra due componenti che ciascuno considera già verificato dall’altro.