Dropbox ha confermato che circa 5.000 account sono stati compromessi tra il 4 e il 21 agosto 2026 senza che gli attaccanti conoscessero una sola password. Il punto debole non era in Dropbox: era nel processo di verifica dell'indirizzo email di Lenovo ID, il sistema di identità di Lenovo che Dropbox accettava come metodo di accesso federato.

La dinamica è tanto lineare quanto istruttiva. Un attaccante registrava un Lenovo ID utilizzando l'indirizzo email della vittima, sfruttando una falla nella procedura di verifica che non accertava realmente il possesso della casella. Con quell'identità appena creata accedeva poi a Dropbox tramite il pulsante "accedi con Lenovo", e Dropbox — fidandosi della corrispondenza dell'indirizzo email — apriva l'account associato. Nessuna password rubata, nessun attacco a forza bruta, nessun malware.

I fatti verificati

  • Finestra di esposizione: dal 4 al 21 agosto 2026, quindi circa due settimane e mezzo prima del rilevamento.
  • Account coinvolti: circa 5.000. Su circa un terzo di questi gli attaccanti hanno effettivamente visualizzato o scaricato file.
  • Vettore: abuso della relazione di fiducia nell'autenticazione federata, non violazione di credenziali.
  • Fattore comune a tutte le vittime: nessuna aveva l'autenticazione a più fattori attiva sul proprio account Dropbox.
  • Dettaglio rilevante: alcune vittime non avevano mai posseduto un prodotto Lenovo, né sapevano di poter accedere a Dropbox con quel metodo.
  • Risposta di Dropbox: invalidazione di tutte le sessioni aperte tramite Lenovo ID, interruzione dei collegamenti tra account Lenovo e Dropbox, e introduzione dell'obbligo di inserire anche la password quando si accede con un Lenovo ID. Sono stati informati utenti e autorità.

Il punto che rende questo incidente diverso dal solito data breach è l'ultimo dettaglio dell'elenco: la vittima non doveva aver fatto nulla. Non aver riusato una password, non aver cliccato su un link di phishing, non aver mai sentito nominare Lenovo ID. Bastava avere un account Dropbox associato a un indirizzo email che l'attaccante conosceva.

Cosa significa per le aziende italiane

Il modello di accesso federato — "accedi con Google", "accedi con Microsoft", "accedi con un provider terzo" — è ormai la norma anche nelle PMI italiane, spesso adottato per una ragione pratica e legittima: riduce le password da gestire e semplifica il lavoro dell'IT. L'incidente Dropbox mostra il costo nascosto di quella scelta: la sicurezza del vostro account non dipende solo dal vostro fornitore, ma dal più debole tra tutti i provider di identità che quel fornitore accetta.

Nella pratica quotidiana di un'azienda italiana questo si traduce in tre domande che quasi nessuno si pone.

La prima: quali metodi di accesso alternativi sono abilitati sui nostri SaaS aziendali? Molte organizzazioni configurano con cura il single sign-on aziendale e poi lasciano attivi, per impostazione predefinita, tutti gli altri percorsi di login che il servizio offre. Se il servizio accetta cinque provider di identità e ne usate uno, gli altri quattro restano superficie di attacco a costo zero per l'attaccante.

La seconda: cosa succede quando un dipendente ha creato l'account con la propria email aziendale, ma fuori dal perimetro gestito? È il fenomeno dello shadow IT nella sua forma più comune: il collega che apre un Dropbox personale per condividere un file con un cliente, usando l'indirizzo di lavoro. Quell'account contiene dati aziendali, non compare in nessun inventario, e nessuno ci ha mai attivato la MFA.

La terza: la MFA è imposta o solo disponibile? Tutte le vittime di questo incidente ne erano prive. Non perché il servizio non la offrisse, ma perché nessuno l'aveva accesa. La differenza tra "il servizio supporta la MFA" e "la MFA è obbligatoria e verificata" è esattamente la differenza tra le vittime e tutti gli altri.

Sul piano normativo, per un'organizzazione italiana che avesse avuto dati aziendali dentro uno di quei 5.000 account il ragionamento è il seguente. Se nel Dropbox compromesso c'erano dati personali di clienti, dipendenti o fornitori, si tratta di una violazione di dati personali: l'organizzazione è titolare del trattamento e Dropbox è responsabile ex art. 28 GDPR, il che significa che l'obbligo di notifica al Garante entro 72 ore ricade sul titolare, non sul fornitore. Dropbox vi ha avvisati; la valutazione del rischio e l'eventuale notifica sono compito vostro. E se i dati esfiltrati sono tali da comportare un rischio elevato per i diritti degli interessati, scatta anche la comunicazione agli interessati (art. 34).

C'è poi una lezione di governance più generale, che vale la pena tenere presente in vista degli obblighi NIS2 sulla sicurezza della catena di fornitura: la vostra due diligence sul fornitore SaaS ha probabilmente verificato le sue certificazioni e le sue politiche. Ha verificato di quali terze parti si fida il vostro fornitore per autenticare i vostri utenti? Nella quasi totalità dei casi la risposta è no, e questo incidente suggerisce che dovrebbe diventare una domanda standard nei questionari di valutazione.

Cosa fare subito

  • Censite i metodi di accesso alternativi su tutti i SaaS aziendali principali (archiviazione, posta, CRM, project management) e disattivate ogni provider di identità che non usate.
  • Rendete obbligatoria la MFA, non facoltativa, e verificate con un report chi non l'ha ancora attivata. Una policy non applicata tecnicamente non è una policy.
  • Verificate se esistono account personali su servizi cloud registrati con domini email aziendali: molti provider offrono strumenti di rivendicazione del dominio che permettono di individuarli e portarli sotto gestione.
  • Impostate una revisione periodica delle sessioni attive e delle applicazioni collegate agli account aziendali, con invalidazione di quelle non riconosciute.
  • Controllate i log di accesso dei servizi cloud principali per il periodo 4-21 agosto, cercando accessi da provider di identità inattesi o da geografie anomale.
  • Inserite nei questionari di valutazione fornitori una domanda esplicita sui provider di identità di terze parti accettati e sul controllo esercitato su di essi.
  • Se avevate dati aziendali in un account coinvolto, avviate subito la valutazione ai fini dell'art. 33 GDPR e documentate la decisione, anche nel caso concludiate di non dover notificare.

L'aspetto più scomodo di questo incidente è che nessuna delle contromisure classiche avrebbe funzionato: password complesse, rotazione periodica, formazione antiphishing. Ha funzionato una cosa sola, la MFA — e proprio quella mancava a tutte le vittime.