Keio, Times Car e Supabase: tre incidenti mostrano dove cede la sicurezza digitale

🛡️ Cosa cambia

• Keio ha subito un ransomware che ha colpito sistemi commerciali del gruppo, ma non ha interrotto il traffico ferroviario.
• Times Car conferma il furto di circa 6,6 milioni di account, compresi dati anagrafici e immagini di documenti di identità.
• UpGuard ha individuato 16.326 database Supabase con tabelle pubblicamente leggibili, soprattutto per configurazioni RLS assenti o errate.

Tre incidenti diversi mostrano la stessa debolezza strutturale: la sicurezza digitale continua a cedere non soltanto davanti a exploit sofisticati, ma soprattutto quando segmentazione, gestione dei dati e configurazione applicativa non reggono il carico reale delle infrastrutture moderne. In Giappone Keio Corporation ha isolato la propria rete dopo un ransomware che ha compromesso alcuni sistemi commerciali senza fermare i treni; Times Car ha invece confermato la sottrazione di circa 6,6 milioni di account, compresi documenti di identità e dati di patente. Sul fronte cloud, una ricerca UpGuard ha individuato oltre 16 mila database Supabase con almeno una tabella accessibile pubblicamente, spesso per Row Level Security mancante o configurata in modo errato. Tre eventi senza relazione diretta, ma accomunati da un punto: il perimetro non coincide più con il server, bensì con come sistemi, dati e autorizzazioni vengono separati prima che qualcosa vada storto.

Keio dimostra che segmentare l’infrastruttura può evitare che un ransomware fermi il servizio essenziale

Keio Corporation ha confermato direttamente di aver rilevato nelle prime ore del 26 settembre un attacco ransomware contro server del gruppo, decidendo di interrompere rapidamente alcune connessioni di rete e avviare l’indagine con specialisti esterni e forze dell’ordine. L’incidente ha provocato problemi a sistemi commerciali di alcune società controllate, mentre la compagnia ha precisato che l’esercizio ferroviario non ha subito interruzioni e che, al momento della comunicazione, non risultava ancora confermata una fuga di informazioni. È proprio questa separazione tra sistemi corporate e sistemi operativi a costituire il dato più interessante: un ransomware è riuscito a produrre un impatto reale sull’organizzazione, ma non a propagarsi fino al servizio ferroviario che collega 69 stazioni e quasi 85 chilometri di rete tra Tokyo e Kanagawa. Non significa che l’incidente sia marginale, perché Keio sta ancora verificando eventuali accessi a dati aziendali e informazioni dei clienti, ma dimostra quanto la segmentazione possa trasformare una compromissione grave in un incidente contenibile. Il problema è particolarmente rilevante per le infrastrutture e i servizi che devono separare IT e componenti operative, perché il ransomware moderno tende a cercare simultaneamente file server, backup, credenziali e sistemi centrali invece di limitarsi alla cifratura di una singola macchina. Nel caso Keio la capacità di isolare la rete ha impedito almeno finora che il danno commerciale diventasse un problema di continuità del trasporto, confermando che la resilienza non consiste soltanto nel bloccare l’attacco iniziale ma nel decidere quali porzioni dell’infrastruttura possono cadere senza trascinare con sé il servizio principale.

Leggi anche: il declino dei pagamenti ransomware non ha fermato l’evoluzione delle strategie criminali

Times Car perde 6,6 milioni di account e mostra perché i documenti valgono più delle password

Molto diverso è il caso Times Car, che ha pubblicato il 28 settembre i risultati preliminari dell’indagine sull’accesso abusivo rilevato il 25 settembre alle 9:07. L’azienda ha confermato che un attaccante ha effettivamente acquisito informazioni appartenenti a circa 6,6 milioni di account, compresi clienti attuali, ex iscritti, persone che avevano iniziato ma non completato la registrazione e utenti del servizio business. I dati sottratti possono includere nome, indirizzo, data di nascita, numero di telefono, email, informazioni sulla patente e immagini utilizzate per la verifica dell’identità; Times Car precisa che i dati relativi alle carte di credito non risultano compromessi e che le password erano conservate in forma non reversibile. Il punto più delicato non è però la password: sono proprio le immagini dei documenti e i dati identificativi completi a trasformare l’incidente in una risorsa estremamente preziosa per frodi, apertura di account, social engineering e furti d’identità. Il precedente data leak di AT&T con milioni di clienti esposti mostrava già come il valore di un breach cresca quando le informazioni possono essere correlate; in Times Car la presenza di documenti ufficiali rende quella correlazione molto più pericolosa perché consente di costruire profili quasi completi di persone reali. L’incidente ricorda anche che conservare dati di utenti non più attivi o di registrazioni mai completate aumenta inevitabilmente la superficie di danno: ogni informazione mantenuta dopo la fine del rapporto continua a produrre valore operativo per l’azienda, ma diventa anche un asset che può essere rubato. In un modello basato sulla verifica dell’identità, la minimizzazione dei dati smette quindi di essere soltanto un requisito privacy e diventa una misura diretta di sicurezza.

Supabase espone 16.326 database senza zero-day: il problema è ciò che l’AI non configura

Il terzo incidente non nasce da un attacco ransomware né da una violazione tradizionale, ma da un problema più difficile da raccontare perché non richiede alcun exploit. UpGuard ha analizzato circa 300.000 domini riconducibili a Supabase e ha individuato 16.326 database nei quali almeno una tabella risultava leggibile pubblicamente; oltre metà mostrava indicatori compatibili con informazioni personali, mentre una quota inferiore conteneva riferimenti a password o token di autenticazione. Il problema ruota soprattutto intorno alla Row Level Security: Supabase consente di definire in modo granulare quali righe siano accessibili ai diversi ruoli, ma le tabelle create tramite SQL, migration o strumenti automatici possono non ereditare automaticamente le protezioni che uno sviluppatore otterrebbe passando dall’interfaccia amministrativa. È qui che entra il nodo del vibe coding. La diffusione di Claude Code, Codex, Cursor, Lovable e altri strumenti rende estremamente semplice generare backend completi e database funzionanti, ma se l’agente scrive la tabella senza creare contestualmente la policy RLS, l’applicazione può funzionare perfettamente mentre i dati restano leggibili dall’esterno. Il precedente del database DeepSeek esposto con chat, API e credenziali mostrava già quanto una misconfiguration possa produrre conseguenze paragonabili a quelle di un attacco vero e proprio; Supabase porta il problema su scala industriale perché l’errore viene replicato da migliaia di applicazioni costruite rapidamente.

Continua con:
Booking.com e i rischi dei log applicativi che espongono dati sensibili
DeepSeek: database esposto con chat, API e credenziali

Il legame tra Keio, Times Car e Supabase non sta quindi nella tecnica utilizzata dagli attaccanti, ma nel modo in cui l’architettura decide l’impatto finale. Keio ha subito un ransomware ma ha mantenuto separato il servizio ferroviario; Times Car ha lasciato che un accesso abusivo raggiungesse una concentrazione enorme di identità digitali; migliaia di sviluppatori Supabase hanno costruito applicazioni apparentemente funzionanti senza accorgersi che il livello di autorizzazione era incompleto. In tutti e tre i casi la sicurezza non fallisce nel momento spettacolare dell’exploit: fallisce prima, nella progettazione. Segmentazione, minimizzazione dei dati e policy di accesso sono meno visibili di un SOC o di un antivirus, ma sono proprio i controlli che decidono se un incidente resta locale o diventa sistemico.