Metabase sotto attacco zero-day: una SQL injection da CVSS 10.0 espone interi

Il 2 agosto 2026 una vulnerabilità zero-day ha colpito Metabase Cloud, la piattaforma di business intelligence open source, compromettendo l'accesso amministrativo senza autenticazione attraverso l'endpoint /api/session/reset_password. Metabase ha confermato l'exploitation attivo il 6 agosto con l'advisory di sicurezza GHSA-vwf4-m7j8-wcjf, assegnando il codice CVE-2026-72898 con punteggio CVSS 10.0 sia nella versione 4.0 che nella 3.1. La criticità massima non deriva solo dalla facilità d'attacco — remoto, senza credenziali, complessità bassa — ma dalla funzione architetturale di Metabase come hub centralizzato di accesso ai dati: compromettere un'istanza significa ereditare le credenziali memorizzate per tutti i database connessi.

Il meccanismo: da SQL injection a controllo totale del data layer

La falla risiede nell'assenza di prepared statements nell'endpoint di reset password, che elabora input utente inserendoli direttamente in query SQL sul database applicativo di Metabase. Un attaccante remoto e non autenticato — come documenta il record CVE.org — può iniettare SQL arbitrario tramite l'endpoint /reset_password e ottenere accesso amministrativo all'istanza connessa.

Dal pannello di amministrazione, l'attaccante può modificare la configurazione, rubare le credenziali memorizzate per i database connessi, leggere i dati accessibili ed esportarli. Questo è il fulcro del rischio: Metabase non è un'applicazione isolata, ma un layer di accesso unificato che si connette a warehouse, database transazionali e data lake. Il CEO di Metabase, Sameer Al-Sakran, ha fornito un indicatore di compromissione preciso: una sequenza di log con POST /api/session/reset_password che restituisce HTTP 400, seguita da GET /api/user/current con HTTP 200, indica probabile compromissione dell'istanza.

La moltiplicazione del blast radius: quando il BI diventa supply chain dei dati

L'angolo più pericoloso di questo incidente è l'effetto moltiplicatore architetturale. Compromettere Metabase non significa perdere solo i dati presenti sulla piattaforma: significa ottenere le chiavi per accedere a tutti i sistemi a monte che essa interroga. Le organizzazioni usano Metabase per centralizzare l'analisi su database eterogenei — PostgreSQL, MySQL, Snowflake, BigQuery, Redshift — mantenendo le credenziali di connessione nella configurazione dell'applicazione.

Le vittime confermate illustrano questo pattern. n8n, piattaforma di workflow automation, ha rivelato che l'attaccante ha ottenuto 136 record cliente, di cui 5 con password hashate in bcrypt e 25 account cloud con password memorizzate in chiaro per un bug storico corretto nell'aprile 2023 — questi ultimi contattati a titolo precauzionale, senza evidenza di accesso effettivo. Kilo Code ha confermato esposizione di record cliente e token Slackbot per un sottoinsieme di utenti, con l'incidente Metabase Cloud avvenuto in un intervallo di circa 4 ore il 2 agosto. Framework, produttore di laptop modulari, ha dichiarato furto di PII cliente: nomi, indirizzi IP, indirizzi postali, numeri di telefono ed email.

"Because the queries used returned a variable, non-deterministic set of rows each time they are run, we cannot determine which specific records were accessed" — n8n

L'esposizione cloud: migliaia di istanze self-hosted ancora vulnerabili

Mentre Metabase Cloud è stata patchata automaticamente, il rischio si concentra sulle istanze self-hosted. Secondo la ricerca di Wiz citata da The Hacker News, circa il 13% degli ambienti cloud ospita istanze Metabase self-hosted; di queste, circa il 25% è completamente esposta a Internet. Il calcolo produce una stima di circa 2.500 istanze Metabase accessibili pubblicamente, ciascuna potenziale vettore di compromissione non autenticata.

Le versioni corrette, secondo SecurityWeek e l'advisory Metabase, sono: 63.5, 62.9, 61.11, 60.17, 59.21 e 58.24. L'advisory indica che le versioni dalla 1.58 in su sono affette; non emergono conferme su versioni precedenti. Per le istanze che non possono aggiornarsi immediatamente, Metabase suggerisce il blocco dell'endpoint /api/session/reset_password a livello di firewall o reverse proxy.

Cosa fare adesso

• Verificare i log: cercare la sequenza IoC documentata — POST /api/session/reset_password con HTTP 400 seguito da GET /api/user/current con HTTP 200 — nei log applicativi e di ingresso del server Metabase
• Applicare le patch indicate: aggiornare a 63.5, 62.9, 61.11, 60.17, 59.21 o 58.24 a seconda del branch in uso; per Metabase Cloud, l'aggiornamento è automatico
• Bloccare l'endpoint: se l'aggiornamento non è immediatamente fattibile, interdire l'accesso a /api/session/reset_password a livello di perimetro di rete
• Audire le connessioni database: per le istanze compromesse o sospette, verificare l'integrità delle credenziali memorizzate e l'accesso ai sistemi connessi, secondo le indicazioni di post-incident response dell'advisory Metabase

Perché CISA ha accelerato la timeline federale

L'inserimento nel Known Exploited Vulnerabilities catalog di CISA con scadenza BOD 26-04 fissata al 14 agosto 2026 riflette la convergenza di tre fattori: severità massima, exploitation confermato, esposizione Internet misurata. La binding operation directive impone alle agenzie federali statunitensi di patchare o mitigare entro il termine; il breve intervallo — appena otto giorni dalla divulgazione — segnala la percezione di rischio immediato da parte dell'autorità.

Il dossier non specifica se l'attacco abbia coinvolto direttamente istanze self-hosted open source oltre a Metabase Cloud, né l'attribuzione a un attore minaccioso specifico. Non emergono evidenze di exploitation dei database connessi oltre al database applicativo di Metabase nelle disclosure pubbliche, anche se l'architettura della piattaforma rende tale scenario tecnicamente plausibile.

La lezione: la centralizzazione dei dati ha un costo di sicurezza

Questo incidente non è una SQL injection banale su un'applicazione marginale. Metabase è un infrastruttura di accesso ai dati per organizzazioni che delegano a essa la connessione a sistemi eterogenei. La sicurezza del BI layer diventa così critica quanto quella dei database stessi — forse più, perché un unico punto di compromissione espone molteplici silos. Le vittime n8n, Kilo Code e Framework non erano utenti negligenti: erano clienti di un servizio cloud che ha fallito sul controllo di un endpoint non autenticato. La distinzione tra responsabilità del vendor e dell'utente si assottiglia quando la piattaforma è progettata come ponte universale.

Per le organizzazioni con istanze self-hosted, il conto alla rovescia è misurato in giorni. Per quelle già compromesse, la domanda non è più se Metabase sia sicuro, ma quanti database erano collegati e con quali privilegi.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://github.com/metabase/metabase/security/advisories/GHSA-vwf4-m7j8-wcjf
• https://www.darkreading.com/vulnerabilities-threats/metabase-sql-zero-day-attacks-wide-blast-radius
• https://thehackernews.com/2026/08/metabase-zero-day-exploited-in-wild.html
• https://www.securityweek.com/metabase-patches-vulnerability-exploited-as-zero-day/
• https://socradar.io/blog/critical-metabase-zero-day/
• https://www.cve.org/CVERecord?id=CVE-2026-72898
• https://www.cisa.gov/news-events/alerts/2026/08/11/cisa-adds-three-known-exploited-vulnerabilities-catalog
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog
• https://github.com/n8n-io/n8n/pull/5842