In breve
Il 6 agosto 2026 Metabase ha reso nota una vulnerabilità zero-day critica di SQL injection (CVSS 10.0), dopo aver rilevato uno sfruttamento attivo iniziato tre giorni prima. Un aggressore non autenticato può iniettare SQL arbitrario nel database applicativo di Metabase, ottenere privilegi di amministratore sull’istanza e, tramite essa, accedere a ogni database a cui Metabase è collegato. Sono interessati sia il servizio cloud sia le installazioni self-hosted.
Framework, produttore di laptop modulari, il 7 agosto ha informato tutti i clienti che, attraverso un’istanza Metabase compromessa, gli aggressori hanno sottratto nomi, indirizzi e-mail, numeri di telefono e indirizzi postali. Tally, piattaforma per moduli online, ha confermato l’accesso a indirizzi e-mail e hash delle password. Risulterebbe compromessa anche un’API Metabase di LexisNexis.
Per ogni team che usa Metabase nel proprio stack di data engineering o analytics l’azione è immediata: confrontate la vostra versione con l’elenco delle patch qui sotto e aggiornate oggi stesso.
Che cosa è successo?
Metabase ha rilevato le intrusioni il 3 agosto 2026. Tre giorni dopo, il 6 agosto, l’azienda ha avvisato i clienti colpiti, bloccato gli endpoint API usati negli attacchi e rilasciato versioni corrette. La comunicazione pubblica è arrivata il 7 agosto.
Framework è stata la prima vittima di rilievo a uscire allo scoperto. In un’e-mail a tutti i clienti del 7 agosto, l’azienda ha spiegato che gli aggressori hanno avuto accesso alle anagrafiche clienti tramite un servizio terzo di business intelligence – Metabase. Tra i dati sottratti figurano nomi, indirizzi e-mail, numeri di telefono e indirizzi di fatturazione e spedizione. I dati di pagamento non sono stati coinvolti.
Tally, che realizza moduli digitali usati da migliaia di aziende, ha confermato una compromissione separata che ha esposto indirizzi e-mail e password sottoposte a hash degli account utente, senza raggiungere i dati dei moduli dei clienti. Anche LexisNexis ha comunicato che la propria integrazione API con Metabase è stata colpita; la portata non è ancora confermata.
Come funziona la vulnerabilità?
Si tratta di una SQL injection senza autenticazione nel livello applicativo di Metabase. Metabase conserva stringhe di connessione, credenziali e risultati delle query per ogni sorgente dati che gestisce. Iniettando SQL direttamente nel database di Metabase – senza prima autenticarsi – un aggressore può diventare amministratore, leggere le credenziali salvate e da lì muoversi verso ogni sorgente dati collegata.
Il potenziale raggio d’impatto è ampio. In produzione, un’istanza Metabase custodisce spesso le credenziali di più data warehouse, database transazionali e API esterne. Comprometterla può quindi esporre molto più dei dati analitici visibili nelle dashboard. Se Metabase interroga direttamente i database di produzione, è in gioco l’intero patrimonio di dati. Ecco perché gli audit di sicurezza periodici devono includere anche gli strumenti di BI e analytics, non solo application server e API.
Non è ancora stato assegnato un codice CVE. Il punteggio CVSS è 10.0 – il massimo – e riflette la combinazione di assenza di autenticazione, esposizione totale dei dati e sfruttabilità da remoto.
Come si rileva una compromissione?
Metabase ha indicato una firma precisa dell’attacco nei log: una richiesta POST a /api/session/reset_password con risposta HTTP 400, seguita subito da una richiesta GET riuscita a /api/user/current con risposta HTTP 200. Cercate questo schema nei log del web server e dell’applicazione. Se lo trovate, l’istanza va considerata completamente compromessa.
Come procedere in caso di compromissione confermata: ruotare tutte le credenziali dei database e le chiavi API salvate in Metabase o raggiungibili tramite esso, verificare a quali dataset e sistemi a valle l’istanza aveva accesso ed esaminare i log di accesso di quei sistemi tra il 3 e il 6 agosto alla ricerca di query o esportazioni anomale.
Che cosa significa per i team software negli Stati Uniti e nell’UE?
Il caso Metabase segue uno schema visto più volte nel 2026: l’anello debole di uno stack software spesso non è l’applicazione sviluppata in casa, ma gli strumenti operativi di terze parti che le stanno intorno. Metabase è percepito come strumento di analisi interno e per questo riceve di solito meno controlli dei sistemi esposti ai clienti – pur custodendo le credenziali degli stessi database.
Per i team FinTech, HealthTech ed e-commerce il tema è particolarmente delicato. In questi contesti Metabase è spesso collegato a database con dati finanziari, dati personali, dati sanitari o storici di pagamento. Ai sensi del GDPR, una violazione che coinvolge dati di residenti UE va notificata all’autorità di controllo competente entro 72 ore dalla scoperta. Negli Stati Uniti, per i dati sanitari la normativa HIPAA impone notifiche al Department of Health and Human Services ed eventualmente agli interessati.
La lezione architetturale riguarda il raggio d’impatto. Uno strumento che concentra le credenziali di molte sorgenti dati diventa un bersaglio di grande valore. Trattate il livello di BI e analytics con gli stessi controlli di accesso, la stessa disciplina di patching e la stessa copertura di audit del livello API.
Che cosa significa per il mercato italiano?
In Italia Metabase è diffuso tra PMI digitali, startup ed e-commerce perché si installa in self-hosting in pochi minuti – spesso su un server gestito dal team dati, fuori dal perimetro presidiato dalla sicurezza IT. Sono proprio queste istanze «ombra» il rischio di oggi. Se dati personali possono essere stati consultati, la notifica al Garante per la protezione dei dati personali va effettuata entro 72 ore dalla conoscenza della violazione (art. 33 GDPR) tramite la procedura telematica del Garante, e ogni episodio va annotato nel registro interno delle violazioni.
Il CSIRT Italia dell’Agenzia per la Cybersicurezza Nazionale (ACN) pubblica regolarmente avvisi su vulnerabilità critiche di questo tipo; per i soggetti che rientrano nella NIS2 si aggiunge un obbligo di notifica degli incidenti significativi oltre a quelli GDPR. In pratica: censite subito tutte le istanze Metabase dell’organizzazione, anche quelle non note all’IT, e documentate la data della patch e l’analisi dei log – sono le evidenze che chiederanno DPO e auditor.
Che cosa fare adesso?
- Individuate la vostra versione. In Metabase: Impostazioni → Admin → Troubleshooting → Version. Confrontatela con l’intervallo colpito (qualsiasi release dalla 1.58 alla 0.63).
- Applicate subito la patch. Aggiornate alla release corretta della vostra versione minore: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 o 0.63.5. Su Metabase Cloud la correzione è stata applicata automaticamente; verificate la versione mostrata nella vostra istanza.
- Se non potete aggiornare subito, mettete offline l’istanza o bloccate l’accesso esterno finché non sarà possibile. Un’istanza Metabase non aggiornata e raggiungibile da Internet è un rischio attivo.
- Controllate i log alla ricerca della firma d’attacco descritta sopra. Se la trovate, avviate la gestione dell’incidente: ruotate le credenziali e verificate i sistemi a valle.
- Ruotate le credenziali salvate in via precauzionale, anche senza evidenze nei log. L’attacco è durato almeno tre giorni prima di essere scoperto; la rotazione resta la scelta corretta.
- Verificate l’esposizione di rete di Metabase. Nella maggior parte degli ambienti uno strumento di BI non dovrebbe essere raggiungibile direttamente da Internet. Se il vostro lo è, limitate l’accesso a VPN o rete interna.
- Per i team soggetti al GDPR: se la vostra istanza conteneva dati personali di residenti UE e trovate tracce di accesso, il termine di 72 ore per notificare l’autorità di controllo decorre dalla conoscenza della violazione – documentate quel momento.
Domande frequenti
Che cos’è la zero-day di SQL injection di Metabase?
Una vulnerabilità critica di SQL injection sfruttabile senza autenticazione (CVSS 10.0) nelle versioni di Metabase dalla 1.58 alla 0.63. Un aggressore remoto senza credenziali può iniettare SQL arbitrario nel database applicativo di Metabase, ottenere privilegi di amministratore ed esporre le credenziali dei database salvate. La falla è stata sfruttata dal 3 agosto 2026, prima che fosse disponibile una correzione. Non è ancora stato assegnato un CVE.
Quali versioni di Metabase sono colpite e a quale aggiornare?
Sono colpite tutte le versioni di Metabase dalla 1.58 alla 0.63, sia cloud sia self-hosted. Release corrette: 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 e 0.63.5. Aggiornate subito alla release corretta corrispondente alla vostra versione. Se non è possibile, mettete l’istanza offline nel frattempo.
Quali aziende sono state violate tramite Metabase?
Metabase ha confermato la compromissione di più istanze di clienti. Framework (laptop modulari) il 7 agosto 2026 ha informato tutti i clienti del furto di nomi, indirizzi e-mail, numeri di telefono e indirizzi postali. Tally (piattaforma di moduli) ha confermato l’accesso a indirizzi e-mail e hash delle password. LexisNexis ha segnalato un’API Metabase compromessa; la portata non è chiara.
Come capisco se la mia istanza Metabase è stata compromessa?
Cercate nei log un POST a /api/session/reset_password con risposta 400, seguito subito da un GET a /api/user/current con risposta 200. Se trovate questa sequenza, considerate l’istanza completamente compromessa: ruotate tutte le credenziali dei database e le chiavi API salvate in Metabase e verificate tutti i dati raggiungibili tramite essa.
Fonti:
Domande sulla protezione della vostra piattaforma dati o dello stack di analytics? Parlate con il nostro team.