Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
Il rischio nascosto nella supply chain: Framework perde i dati dei clienti attraverso Metabase

Il rischio nascosto nella supply chain: Framework perde i dati dei clienti attraverso Metabase

23 Agosto 2026 08:07
In sintesi

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.

Advertising

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.

Advertising

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:

  • aggiornamento immediato;
  • revoca di tutte le sessioni attive;
  • verifica ed eliminazione di API key sconosciute;
  • revisione degli account amministrativi;
  • rotazione delle credenziali di ogni database collegato;
  • esame di data warehouse log, activity history e query history;
  • blocco temporaneo di /api/session/reset_password qualora l’aggiornamento non fosse subito praticabile.

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:

  • se i suoi dati passano per piattaforme specifiche;
  • quali categorie di dati possono essere analizzate ed a che scopo;
  • se qualche terzo può accedere ai dati o alle sorgenti che li contengono;
  • dove avvengono i trattamenti e con quali garanzie sui trasferimenti;
  • a chi scrivere per accesso, opposizione, limitazione o cancellazione.

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.


📢 Resta aggiornatoTi è piaciuto questo articolo? Rimani sempre informato seguendoci su 🔔 Google News.
Ne stiamo anche discutendo sui nostri social: 💼 LinkedIn, 📘 Facebook e 📸 Instagram.
Hai una notizia o un approfondimento da segnalarci? ✉️ Scrivici


Emanuele Nigro 300x300
Ho maturato la mia esperienza tra sistemi Linux e cybersecurity, occupandomi di hardening, incident response, vulnerability assessment e remediation plan in ambienti IaaS. Mi interesso di attività di analisi e studio, tramite strumenti OSINT, su data breach e DDoS.