Metabase, zero-day SQL injection: quando la BI ha le chiavi di ogni database

Il 6 agosto 2026 Metabase ha pubblicato un avviso di sicurezza d'emergenza rilasciando patch su sei linee di rilascio contemporaneamente. Il motivo è emerso il giorno dopo: una SQL injection non autenticata, tracciata come GHSA-vwf4-m7j8-wcjf e valutata CVSS 10.0, era già stata usata come zero-day per violare istanze cliente reali e sottrarre dati. Due delle vittime — il produttore di laptop Framework e il form builder Tally — hanno dichiarato pubblicamente il furto. La parte interessante non è l'injection in sé. È cosa sia Metabase: un server di business intelligence che, per progettazione, custodisce credenziali attive verso ogni database che conta per un'organizzazione. Un bug non autenticato in quella scatola non è una vulnerabilità applicativa. È una chiave per l'intero data warehouse.

Cosa fa davvero lo zero-day di Metabase

Il difetto vive in un unico endpoint non autenticato: POST /api/session/reset_password. L'avviso di Metabase è esplicito sulle conseguenze — un attaccante che raggiunge quell'endpoint può "iniettare SQL arbitrario nel database applicativo di Metabase, ottenendo l'accesso da amministratore all'istanza". Nessun login, nessun token, nessun appoggio preliminare. Una singola richiesta a una rotta di reset password, e l'attaccante scrive SQL contro il metadata store dell'applicazione.

L'accesso amministrativo a un'istanza Metabase non è il soffitto: è il pavimento. Una volta dentro, nota l'avviso, l'attaccante può modificare la configurazione applicativa, leggere le credenziali salvate di ogni database collegato ed esportare qualsiasi dato raggiungibile attraverso quelle connessioni. Metabase cifra i segreti di connessione a riposo, ma una sessione da amministratore li decifra nel normale svolgimento del proprio lavoro — è esattamente ciò per cui esiste lo strumento. Il vettore vale CVSS 10 per la ragione per cui il 10 è raro: AV:N/AC:L/PR:N/UI:N con cambio di scope e impatto totale su riservatezza, integrità e disponibilità. Raggiungibile in rete, banale, senza privilegi, senza interazione utente, e rompe il proprio scope di sicurezza riversandosi su tutto ciò che tocca.

Un dettaglio che vale la pena segnalare a chi imposta il programma di vulnerabilità sui CVE: questo difetto non ha un CVE. È tracciato solo come advisory GHSA. Gli scanner e le pipeline di asset management che si basano esclusivamente sul feed CVE non scatteranno, e manca l'enrichment NVD che di solito assegna il CVSS. Se la regola di triage è "niente CVE, niente ticket", questa settimana un RCE-equivalente non autenticato da CVSS 10 le è passato accanto senza fare rumore.

Perché una piattaforma di BI è l'host peggiore per una SQL injection non autenticata

La maggior parte delle vulnerabilità web critiche è limitata da ciò che l'applicazione compromessa custodisce. Una SQL injection in un forum espone gli utenti del forum. Una SQL injection in uno strumento di BI espone tutto ciò che lo strumento può interrogare — e uno strumento di BI è deliberatamente cablato per interrogare qualsiasi cosa.

Metabase è un punto di aggregazione. Per fare il proprio mestiere custodisce credenziali di servizio stabili e a lunga durata verso Postgres, MySQL, Snowflake, BigQuery, Redshift di produzione e qualunque altra fonte alimenti le dashboard. Quelle credenziali sono di solito ampie — gli analisti non vogliono aprire un ticket ogni volta che serve una colonna nuova, quindi al service account di Metabase viene spesso concessa lettura su interi schema, a volte interi cluster. È un compromesso ragionevole per uno strumento di analisi interno protetto da autenticazione. È un compromesso catastrofico per uno strumento di analisi interno con una SQL injection non autenticata sulla porta d'ingresso.

Il raggio d'azione, quindi, non è la dimensione del database applicativo di Metabase. È l'unione di ogni dataset che ogni connessione di Metabase può leggere. E, cosa cruciale, l'attaccante non deve trovare, forzare o muoversi lateralmente verso quei database. Metabase ha già fatto la parte difficile — si è autenticato, tiene le sessioni aperte ed espone una superficie di query su di essi. L'injection si limita a prendere in prestito le chiavi già inserite nel cruscotto.

"Abbiamo applicato la patch poche ore dopo l'avviso. Siamo al sicuro?"

"Siete al sicuro dal prossimo attaccante. Quello entrato il 3 ha già letto i vostri segreti di connessione ed esportato le tabelle. La patch chiude la porta. Non annulla l'invio dei dati e non ruota le password dei database che l'attaccante ora possiede."

Quello scambio è l'intera lezione dell'incidente. Applicare la patch a uno zero-day sfruttato attivamente è necessario e non fa nulla per la finestra già trascorsa.

Framework, Tally e la forma della violazione

Le vittime pubbliche danno una forma concreta al rischio astratto. Secondo il resoconto di BleepingComputer e la copertura di The Hacker News, gli attacchi hanno colpito Framework e Tally il 3 agosto, tre giorni prima che la patch esistesse. Framework ha riferito il furto di nomi dei clienti, indirizzi email, indirizzi IP di accesso, indirizzi di fatturazione e spedizione, numeri di telefono e nomi aziendali. Tally ha riferito il furto di indirizzi email e hash delle password — hash crittografici a senso unico, non password in chiaro — mentre i dati dei form inviati sono rimasti intatti. LexisNexis è stata indicata come impattata tramite un fornitore terzo, con la portata dell'esposizione ancora incerta al momento della divulgazione.

Due cose colpiscono. La prima: le classi di dati corrispondono esattamente al modello "tutto ciò che la BI può leggere" — non è una tabella trapelata, sono record dei clienti assemblati attraverso ciò che le dashboard mettono insieme. La seconda, più importante: le vittime non hanno rilevato l'intrusione. È stata Metabase ad avvisarle. Framework ha saputo della propria esposizione il 6 agosto, quando il vendor ha divulgato il difetto — non il 3 agosto, quando i suoi dati sono usciti dalla porta. Quel divario di tre giorni tra compromissione e consapevolezza non è una mancanza di Framework. È l'esito di default per un'esfiltrazione che viaggia su connessioni che l'ambiente è costruito per considerare affidabili.

Il punto cieco: esfiltrazione su connessioni che dovrebbero esserci

Ecco perché questa classe di violazioni sfugge con tanta costanza. Ogni controllo sul perimetro sta osservando la cosa sbagliata.

Un agent endpoint sull'host di Metabase vede un processo legittimo — la JVM di Metabase — aprire connessioni al database che apre tutto il giorno, ogni giorno. Una regola di correlazione SIEM che cerca login falliti o nuovi account amministrativi non vede nulla di insolito, perché l'attaccante ha usato un endpoint non autenticato ed ha ereditato l'identità dell'applicazione stessa. Un monitor di rete basato su firme vede TLS verso gli stessi host di database e lo stesso upstream con cui Metabase parla sempre. Nessuna regola è scattata perché, al livello a cui quegli strumenti ragionano, non c'era nulla di anomalo. I byte erano sbagliati; i metadati erano a posto.

Ciò che era anomalo era la forma del traffico. Il profilo normale di un server di BI è ingest pesante dai database ed egress leggero verso i browser che renderizzano le dashboard. Durante questo attacco il profilo si inverte: egress sostenuto ad alto volume da un host che storicamente solo assorbe, spesso verso una destinazione — un endpoint controllato dall'attaccante o un ASN mai visto prima — con cui l'host non ha motivo di parlare. Quell'inversione è visibile sul filo in tempo reale, mentre l'export è in corso, indipendentemente da quale processo abbia aperto il socket o dal fatto che il feed CVE si sia aggiornato. È esattamente il segnale che gli strumenti basati su log e identità strutturalmente non possono vedere e che l'analisi comportamentale del traffico è costruita per intercettare.

Remediation

L'avviso di Metabase e i resoconti dell'incidente danno abbastanza per costruire un runbook completo. Trattare qualsiasi istanza esposta e non aggiornata come compromessa fino a prova contraria — è stata sfruttata come zero-day, quindi "abbiamo aggiornato in fretta" non significa "non siamo mai stati colpiti".

1. Sono interessato? Verifica la versione in esecuzione rispetto agli intervalli affetti. Il difetto colpisce Metabase 1.58 e superiori fino alle correzioni; in concreto, le build vulnerabili sono:

Linea di rilascio	Affetta	Corretta in
58	58.0 – 58.23	0.58.24 / 1.58.24
59	59.0 – 59.20	0.59.21 / 1.59.21
60	60.0 – 60.16	0.60.17 / 1.60.17
61	61.0 – 61.10	0.61.11 / 1.61.11
62	62.0 – 62.8	0.62.9 / 1.62.9
63	63.0 – 63.3	0.63.5 / 1.63.5

Le istanze Metabase Cloud sono state aggiornate dal vendor. Solo i deployment self-hosted richiedono un intervento. Conferma la build da Admin → Troubleshooting oppure da GET /api/session/properties (campo version), non dall'ultimo deploy che ricordi.

2. Applica la patch. Aggiorna alla release corretta della tua linea, esattamente come nella tabella. Non "aggiornare all'ultima" alla cieca attraversando le linee major senza controllare le proprie note di breaking change — scegli la build corretta sulla tua linea attuale, così la correzione è l'unica modifica.

3. Non puoi aggiornare subito? Contieni l'endpoint. Blocca POST /api/session/reset_password sul reverse proxy o WAF finché l'aggiornamento non arriva. In nginx: location = /api/session/reset_password { return 403; }. Questo disabilita il reset self-service della password, un compromesso accettabile per qualche ora. È un tampone, non una correzione — le primitive di SQL injection hanno spesso più di un sink raggiungibile, quindi tratta il blocco come tempo guadagnato per applicare la patch, non come sostituto.

4. Cerca segni di compromissione. Metabase ha pubblicato un indicatore preciso: un POST /api/session/reset_password che restituisce HTTP 400, seguito da un GET /api/user/current che restituisce HTTP 200 dalla stessa sorgente, è la firma dello sfruttamento. Cerca quella coppia nei log di accesso del reverse proxy e dell'applicazione. Oltre alla firma, cerca le conseguenze: modifiche impreviste alle impostazioni delle connessioni al database, utenti amministrativi nuovi o modificati, export di dati insoliti per volume, e connessioni in uscita dall'host Metabase verso destinazioni fuori dal suo insieme normale. Mappa la catena su MITRE ATT&CK per detection e reporting:

• T1190 — Exploit Public-Facing Application (l'injection non autenticata)
• T1078 — Valid Accounts (accesso admin sull'istanza)
• T1552.001 / T1555 — Credenziali dai segreti di connessione salvati
• T1213 — Data from Information Repositories (i database collegati)
• T1041 / T1567.002 — Esfiltrazione sul canale dell'attaccante / servizio web

5. Eradica e verifica. La patch non revoca ciò che la SQL injection ha già letto. Poiché il vero premio dell'attaccante erano le credenziali a valle, l'eradicazione deve andare oltre Metabase:

• Revoca tutte le sessioni Metabase attive e ruota la chiave segreta/di cifratura dell'applicazione.
• Ruota le credenziali di ogni database a cui Metabase si connette. Sono le chiavi che l'attaccante ha esportato; la patch non le cambia. È il passo che la maggior parte dei write-up salta ed è quello che chiude davvero la violazione.
• Verifica gli account admin e le API key create o modificate dalla prima esposizione possibile, e rimuovi ciò di cui non sai rendere conto.
• Ruota anche i segreti contenuti nei database raggiungibili (API key applicative, token di terze parti), perché sono usciti anch'essi.
• Verifica per stato, non per changelog: conferma che la versione in esecuzione sia una build corretta, che l'endpoint di reset password non produca più il pattern 400-poi-200, e che le credenziali di database ruotate siano le uniche ora accettate.

Dove si inserisce Zero Hunt

I tre giorni tra la violazione di Framework e il momento in cui Framework l'ha saputo sono il problema che vale la pena risolvere, ed è un problema di rete prima che di log. Ogni controllo host-based e identity-based in quell'ambiente ragionava sul livello sbagliato — un processo affidabile che usa connessioni affidabili — mentre i dati dei clienti uscivano proprio su quelle connessioni.

È il caso per cui è nato il pilastro AI Traffic Analysis di Zero Hunt. È un modello di deep learning proprietario, addestrato su miliardi di sequenze PCAP, eseguito localmente sulla GPU dell'appliance con un baseline di 2,7+ Gbit/s — niente cloud, niente callback. Le sue quattro teste di inferenza (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo) ragionano sulla forma di una sessione, non sulla firma. Un server di BI il cui profilo storico è ingest-heavy che d'un tratto sostiene egress ad alto volume verso un ASN mai visto è esattamente l'anomalia che la testa "traffico sospetto" è addestrata a far emergere — mentre l'export è in corso, non nel digest SIEM del mattino dopo, e a prescindere dal fatto che il difetto sfruttato ottenga mai un CVE. Quando l'esfiltrazione viaggia su connessioni che i tuoi strumenti endpoint e identity sono costruiti per considerare affidabili, il filo è l'unico posto in cui la verità è ancora visibile.

La metà a monte è la validazione. Un server Metabase con lettura ampia sulla produzione è proprio il tipo di punto di aggregazione sovra-permessivo che un test offensivo continuo dovrebbe segnalare prima che lo trovi un attaccante — una superficie admin raggiungibile da Internet con credenziali verso tutto ciò che sta dietro. Il motore di generative pentest a 10 agenti di Zero Hunt scrive una catena di exploit fresca per ogni target, backtestata nell'AI Gym prima di girare in produzione e firmata ECDSA per ogni finding, così il rischio "la nostra BI può leggere l'intero warehouse ed è a un bug non autenticato da Internet" compare in un report su cui agire — non in una notifica di violazione dal vendor.

Applicare la patch a GHSA-vwf4-m7j8-wcjf è stata la parte facile, e la maggior parte dei team l'ha fatto entro un giorno. La parte difficile — sapere se i tre giorni prima della patch ti sono costati qualcosa — è una domanda a cui solo la rete può rispondere, e solo se qualcosa la stava osservando.