Metabase zero-day CVSS 10.0: attivamente sfruttata per furto di dati aziendali

Metabase ha confermato il 6 agosto 2026 che una vulnerabilità zero-day, ancora senza identificatore CVE, sta venendo attivamente sfruttata contro le sue installazioni cloud e self-hosted. La falla, classificata con il punteggio massimo CVSS 10.0, permette a un attaccante remoto non autenticato di ottenere privilegi di amministratore e da lì di estrarre dati sensibili e credenziali di database connessi. Le prime conferme di impatto arrivano da tre clienti enterprise: Framework, Tally e LexisNexis.

Fatti verificati: la catena di attacco

Il meccanismo parte da un'iniezione SQL non autenticata nell'endpoint /api/session/reset_password. Secondo l'advisory di sicurezza di Metabase citata da BleepingComputer, questa falla consente a un attaccante remoto di "inject arbitrary SQL into the Metabase application database, which can give them administrator access to the instance". La formulazione tecnica è precisa: non si tratta di un'ipotetica escalation complessa, ma di un percorso diretto da utente anonimo a privilegi massimi.

Dalla posizione di amministratore, l'attaccante può modificare la configurazione dell'applicazione, rubare le credenziali crittografate dei database connessi, leggere qualsiasi dato accessibile attraverso tali connessioni ed esportarli. Metabase ha esplicitamente confermato l'exploitation attiva della vulnerabilità.

"This is a CRITICAL vulnerability that allows an unauthenticated remote attacker to inject arbitrary SQL into the Metabase application database, which can give them administrator access to the instance"

— Advisory di sicurezza Metabase, via BleepingComputer

Fatti verificati: il percorso del CEO e gli IoC

Sameer Al-Sakran, CEO di Metabase, ha firmato personalmente la notifica. La sua dichiarazione, riportata da BleepingComputer, è inequivocabile: "We recently identified that Metabase Cloud was attacked by someone utilizing an unknown ('0-day') security vulnerability in versions 1.58 and above". Il riferimento esplicito a "0-day" e la specificazione delle versioni affette rimuovono ambiguità sulla natura dell'incidente.

Al-Sakran ha fornito indicatori di compromissione concreti. La sequenza da cercare nei log è precisa: una richiesta POST a /api/session/reset_password che restituisce stato 400, seguita da una GET a /api/user/current con risposta 200. "If you find that pattern in your application logs or in your Metabase server ingress logs, it is likely that your instance has been compromised", ha dichiarato.

Fatti verificati: chi ha subito impatto

Il 6 agosto 2026, Metabase ha notificato Framework che la sua istanza era stata accessa il 3 agosto. Framework ha poi confermato il furto di nomi completi, indirizzi email, indirizzi IP di login, indirizzi di fatturazione e spedizione, numeri di telefono e nomi aziendali. Per i clienti business, l'esposizione si estende a VAT, EIN e email di fatturazione.

Tally ha confermato compromissione nella stessa data, il 3 agosto, con un profilo di impatto diverso: email e hash crittografici delle password. La notifica specifica esplicitamente che "non hanno raggiunto le vostre form" e che l'hash è "unidirezionale, quindi non può essere riconvertito in password". Tuttavia, il dossier non specifica l'algoritmo di hashing impiegato né la presenza di salt. BleepingComputer ha richiesto chiarimenti a Tally senza ricevere risposta al momento della pubblicazione.

LexisNexis ha confermato impatto sulla propria API Metabase attraverso un vendor di terze parti, con disconnessione immediata dei sistemi coinvolti. Il dossier non stabilisce se LexisNexis abbia subito esfiltrazione effettiva di dati clienti o solo interruzione di servizio. L'indagine è indicata come in corso.

Analisi: il contesto di rischio

La struttura di Metabase come strumento di business intelligence che si connette a molteplici database amplifica l'impatto della compromissione. Un singolo accesso amministrativo espone non solo i dati dell'applicazione, ma le credenziali crittografate dei database connessi e i dati accessibili tramite essi. Questa concentrazione di accesso è intrinseca all'architettura del prodotto, non una configurazione errata specifica.

Il precedente CVE-2023-38646 (CVSS 9.8, RCE), risolto tre anni prima, mostra che il prodotto ha già attraversato una criticalità di severità comparabile. La ricorrenza di vulnerabilità di questa entità in un arco triennale è un dato di fatto documentato, non un'inferenza.

Cosa fare adesso

Metabase ha rilasciato patch per tutti i branch dalla versione 0.58 alla 0.63. Le versioni minime sicure sono: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9, 0.63.5. Per le istanze che non possono essere aggiornate immediatamente, il workaround temporaneo è bloccare l'endpoint /api/session/reset_password.

Metabase raccomanda di revocare sessioni attive, ruotare credenziali database, controllare log e query history. Queste azioni sono specifiche al caso documentato e derivano direttamente dall'advisory del vendor.

Incertezze documentate

Restano zone di incertezza che il brief non chiarisce. L'algoritmo di hashing e la presenza di salt per le password Tally esposte non sono noti. L'entità esatta dell'attaccante non è identificata. Il numero totale di vittime oltre Framework, Tally e LexisNexis non è quantificato. Non è stabilito quando o se verrà assegnato un CVE alla vulnerabilità. Metabase afferma che la falla non interessi versioni precedenti alla 0.58, ma senza pubblicare dettagli tecnici che lo dimostrino. Non è documentata la presenza di PoC pubblico o vendita su mercati underground.

Chiusura editoriale

Questo articolo si basa principalmente sull'indagine di BleepingComputer, con conferme convergenti da The Hacker News e SecurityAffairs che non aggiungono elementi originali di rilievo. Le informazioni sono aggiornate al momento della pubblicazione; i limiti delle fonti disponibili sono esplicitati nelle sezioni precedenti.

Il caso Metabase illustra come la compromissione di un layer di interrogazione dati possa tradursi in esposizione di informazioni di business critiche. La differenza tra cloud gestito e self-hosted, in questo incidente, si è ridotta a una distinzione senza differenza sostanziale: entrambe le modalità sono state attaccate con lo stesso vettore, e entrambe richiedono le stesse azioni immediate.