Un grave zero-day in Metabase ha permesso a un attaccante senza credenziali di ottenere privilegi amministrativi e accedere ai dati disponibili sull’istanza. Framework ha confermato l’esposizione di nomi, email, telefoni e indirizzi dei clienti. Il caso mostra i rischi della supply chain e dell’accesso eccessivo ai dati.
Uno zero day critico ha esposto i dati dei clienti di Framework attraverso Metabase, dimostrando che conoscere la filiera che tratta i dati, e limitarne gli accessi, sia diventato essenziale
Molti di voi conosceranno Framework Computer Inc., società statunitense divenuta nota per la produzione di laptop e desktop modulari, riparabili e aggiornabili, e per la diffusione del diritto alla riparazione garantito dal produttore, grazie alla fornitura di schemi, componenti e documentazione tecnica pubblicati in forma aperta, motivo per cui una buona parte del mondo IT si è ovviamente avvicinata all’idea, diventandone cliente sia privato che business.
Per un’azienda vendere i propri prodotti significa anche custodire un patrimonio informativo dei propri clienti, fatto di contatti, indirizzi, dati di fatturazione, account, log, nonché estremi aziendali e fiscali in caso di clienti business; dati utili per l’azienda venditrice, per comprendere l’andamento del proprio business, effetti ed efficacia delle proprie politiche; dati che un’azienda dovrebbe custodire gelosamente, e con la diligenza prevista dalle differenti normative sulla protezione dei dati.
Sui dati dei clienti e sulla loro protezione, appunto, verte la comunicazione di Framework ai propri clienti, che hanno ricevuto una missiva inviata dal venditore a partire dal 7 agosto 2026 nella quale viene spiegato che una compromissione dei servizi Metabase, suo fornitore di Business Intelligence, aveva coinvolto tutti i loro dati, ad eccezione di quelli di pagamento:
Dear Valued Framework Customer, We are writing to inform you of a data breach at our business intelligence database provider Metabase that resulted in an attacker accessing customer names, email addresses, phone numbers, and addresses. Your information was in the database that was accessed in this breach. This breach did not include order or payment information. We have full details on the incident below. We are deeply sorry for this breach of information, and are reviewing and improving our methodology for data storage in external database vendors[…]
Ma cosa vuol dire tutto questo per i clienti di Framework? Analizziamo più a fondo la questione.
Metabase, piattaforma open source di Business Intelligence e analytics, con la capacità di collegarsi a database e altre sorgenti, fornisce utili dashboard e report operativi, e può essere utilizzata in formato self hosted, installata e gestita dal cliente nella propria infrastruttura, oppure attraverso il servizio SaaS amministrato dal vendor, Metabase Cloud, che non implica necessariamente la copia integrale del database operativo nei server del fornitore, favorendo un approccio in cui i dati restano il più possibile sui server del cliente.
Tale puntualizzazione è importante sotto il profilo dei dati, non essendo necessaria una replica puntuale del database, facendo emergere che chi utilizza il servizio può decidere cosa condividere con il proprio fornitore, senza permettere un completo accesso, e permettendo la detenzione di credenziali relative alle sole base dati limitate.
Il 6 agosto 2026 Metabase ha pubblicato un advisory di sicurezza relativo ad una vulnerabilità critica, già sfruttata, che permetteva ad un attaccante remoto e senza credenziali, di iniettare SQL nel database applicativo di Metabase, ottenendo privilegi amministrativi e operando sull’istanza compromessa. L’advisory assegna alla vulnerabilità una severità CVSS 3.1 di 10.0, impatto massimo su confidenzialità, integrità e disponibilità, con il seguente vettore:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H
Rappresentando il massimo livello di gravità possibile in cybersecurity.
Le versioni esposte comprendevano le release dalla linea 0.58 alla 0.63, prima delle rispettive patch release.
I bersagli principali erano una coppia di richieste per effettuare il reset della password:
POST /api/session/reset_password → HTTP 400
GET/api/user/current → HTTP 200
Per ottenere l’accesso amministrativo non è stata necessaria alcuna credenziale, e, una volta ottenuto l’accesso, l’attaccante aveva il pieno controllo dei dati raggiungibili.
Metabase ha comunicato ai propri clienti, prima della pubblicazione dell’advisory, che un attacco zero day è stato individuato il 3 agosto, intervenendo con il blocco degli endpoint sfruttati, e patchando le istanze Metabase Cloud; ai clienti self hosted è stato richiesto di aggiornare con urgenza alle release corrette, con le seguenti raccomandazioni:
Metabase riferisce inoltre di avere coinvolto le forze dell’ordine ed una terza parte forense, e di avere condiviso con i clienti report e log delle attività osservate, chiarendo che le analisi preliminari si basavano sui propri application log, ma non escludendo che chi ha operato l’attacco abbia invece voluto attingere proprio ai dati disponibili.
Tornando a Framework, comprendiamo che abbia avvisato i propri clienti dopo avere ricevuto l’allerta di Metabase ed analizzato i log forniti, oltre ad annunciare alcune contromisure che prevede di applicare, come la rotazione delle credenziali di tutti i database associati all’istanza Metabase e la verifica dell’assenza di modifiche sugli accessi amministrativi; ma ciò che è saltato all’occhio è stato l’annuncio della revisione dei dati condivisi con le piattaforme di BI, e la limitazione futura degli accessi alle sole colonne necessarie alle analisi, che si traduce nella evidente mancata applicazione dei principi di minimizzazione del dato e privilegio minimo, finora disapplicati dall’azienda, ma fondamentali per la protezione delle informazioni. Dati come indirizzi email in chiaro, indirizzi completi, numeri di telefono, IP ed identificativi fiscali dei propri clienti dovrebbero essere rimossi o quantomeno offuscati, per permettere alle piattaforme BI di analizzare commercialmente dataset aggregati e pseudonimizzati per informazioni più generali, quali area geografica, stato e data dell’ordine, categorie di prodotti.
Molti clienti hanno quindi avviato discussioni, anche sui forum della community Framework, in merito alla problematica emersa, nelle quali è possibile leggere alcuni di loro porsi dubbi in merito all’assenza, nella privacy policy pubblicata da Framework, del fornitore Metabase, e non presenti nemmeno una descrizione generica di una finalità di Business Intelligence applicata ai loro dati personali; chi scrive ha effettivamente verificato la sussistenza di questa mancanza; agli interessati, però, bisognerebbe chiarire che dalla sola omissione non viene rilevata una violazione del GDPR, ma è evidente che ci siano problemi concreti di trasparenza, poiché un utente dovrebbe poter ricostruire dall’informativa alcuni passaggi essenziali:
Per GDPR il titolare deve informare in modo trasparente su finalità, categorie di dati e destinatari o categorie di destinatari; deve scegliere responsabili che diano garanzie sufficienti, regolarne il rapporto e adottare misure proporzionate al rischio, cosa che evidentemente Framework non ha fatto, avendo intenzione di porre in essere alcune linee guida necessarie, e previste dallo stesso fornitore.
Ma proviamo ora ad immaginare uno scenario peggiore nel quale Framework avesse scelto di non comunicare nulla al cliente finale, che non avrebbe avuto alcun modo di sapere che Metabase faceva parte della supply chain, che una piattaforma di BI poteva leggere dati, e che questi erano diventati potenzialmente accessibili durante un incidente del quale nessuno dei clienti potevano correlarne il coinvolgimento. Di conseguenza il cliente non poteva porre nessuna contromisura personale, nessuna prudenza aggiuntiva verso fenomeni di phishing o social engineering.
Tutto ciò avrebbe avvantaggiato l’attaccante, che avrebbe potuto ottenere un archivio con nome, email, telefono, indirizzo e contesto d’acquisto, sufficiente a creare messaggi credibili per campagne mirate.
Spostando il caso dentro i nostri confini, per una realtà italiana, specie se soggetta al D.Lgs. 138/2024 di recepimento della NIS2, la stessa sequenza si sarebbe trasformata nell’immediato in un incidente di supply chain, con perdita di riservatezza su dati digitali e possibile data breach GDPR; ne conseguirebbe un eventuale obbligo di notifica a CSIRT Italia, con responsabilità diretta per vertici e governance. I soggetti NIS hanno l’obbligo di censire e valutare fornitori e servizi cloud, identificando il livello di accesso a sistemi e dati, inserendo requisiti di sicurezza nei contratti e verificandone periodicamente la conformità.
Per questo un soggetto essenziale o importante non potrebbe accontentarsi di chiedere al fornitore il solo possesso delle certificazioni necessarie, ma dovrebbe accertarsi, in casi come questo, a quali dati il servizio può davvero accedere, quali credenziali conserva, e dove, e prevedere la condivisione con fornitori e subfornitori di soli dataset analitici separati dai database operativi, con pseudonimizzazione o tokenizzazione degli identificativi cliente.
In sintesi, nella vicenda, Framework ha certamente avuto il merito di informare i propri clienti in tempi rapidi, permettendo loro di comprendere il rischio e aumentare l’attenzione verso campagne mirate, ma ciò non elimina le criticità emerse. L’azienda avrebbe dovuto corredare la propria privacy policy almeno con l’indicazione di una finalità generica di Business Intelligence, e delle categorie di fornitori coinvolti, rendendo comprensibile che determinati dati potessero essere trattati attraverso piattaforme esterne. Soprattutto avrebbe dovuto limitare fin dall’inizio l’accesso, fornendo a Metabase dataset separati, pseudonimizzati, anonimizzati o ridotti alle sole tabelle e colonne realmente necessarie.
Se i servizi che utilizziamo restano opachi il cliente finale non può sapere chi tratta davvero i suoi dati, né valutare i rischi o adottare precauzioni tempestive, con il rischio di scoprire l’accaduto solo quando i dati compaiono in un leak, o vengono usati per colpirlo. È proprio questa asimmetria informativa che trasforma una vulnerabilità in un problema di fiducia, trasparenza e sicurezza del fornitore e della sua supply chain.
Betti RHC, la prima graphic novel al mondo dedicata alla cybersecurity awareness, ha finalmente il suo sito ufficiale. Uno spazio tutto suo dove scoprire il progetto, sfogliare le copertine degli episodi e immergersi nel mondo di Betti: la giovane laureanda in informatica che, dopo la morte misteriosa del padre, si trasforma nell'hacker più potente del mondo. Una storia avvincente che, episodio dopo episodio, affronta una minaccia digitale diversa — dal phishing al ransomware, fino al cyberbullismo — e insegna a riconoscerla e a difendersi, senza che sembri mai una lezione.
Sul sito trovate tutto ciò che rende Betti un progetto diverso dal solito: la sua filosofia, le anteprime delle tavole e il racconto di come nasce ogni volume. Perché dietro Betti RHC c'è solo lavoro umano: ogni tavola è disegnata interamente a mano dagli artisti del Gruppo Arte di Red Hot Cyber, senza alcun uso di intelligenza artificiale. E a garantire che ogni storia sia realistica e tecnicamente corretta c'è la supervisione degli hacker etici del gruppo HackerHood, che mantengono il racconto fedele al mondo reale della sicurezza informatica.
C'è spazio anche per le aziende, che possono usare Betti come strumento di awareness diverso dai soliti corsi: acquistare i volumi, personalizzarli con il proprio brand o sponsorizzare nuovi episodi. E come primo regalo, l'episodio "Byte the Silence", dedicato al cyberbullismo, è scaricabile gratuitamente per uso personale.
Perché la miglior difesa, in fondo, è una bella storia. 👉 Scopri tutto su https://betti.redhotcyber.com/