Gyazo, rubati 23,62 milioni di record: il server di upload era la falla

Helpfeel, la società giapponese proprietaria di Gyazo, ha confermato che il 11 settembre 2026 attaccanti hanno compromesso il server di upload immagini del servizio di screenshot più diffuso tra sviluppatori e professionisti IT. La violazione ha esposto circa 23,62 milioni di record utente e quasi 490 milioni di record di metadata di immagini, trasformando una falla di perimetro in un problema di profondità per chi usava la piattaforma per condividere terminal, codice e configurazioni sensibili.

Il meccanismo: upload server, comandi arbitrari e accesso al database

La fonte cita la notifica ufficiale di Helpfeel: l'attaccante ha "exploited a vulnerability in its image upload server" per "gain unauthorized access to Gyazo's systems and run arbitrary commands". Questa formulazione, riportata da Help Net Security e confermata da The Hacker News, indica un percorso di attacco che parte dal perimetro — un server esposto a Internet gestito per ricevere file multimediali — e si estende lateralmente fino al database centrale.

L'attività sospetta è stata rilevata la sera dell'11 settembre 2026, con blocco degli accessi nelle prime ore del 12 settembre e correzione della vulnerabilità nello stesso arco temporale. Helpfeel ha segnalato l'incidente alla Personal Information Protection Commission del Giappone il 15 settembre. La notifica pubblica è apparsa il 16 settembre secondo la cronologia riportata da The Hacker News.

Il servizio Gyazo era ancora in manutenzione al momento della stesura delle fonti, senza una timeline di ripristino comunicata. Helpfeel ha esplicitamente escluso che i servizi correlati Helpfeel e Cosense siano stati compromessi.

Il dato che amplifica: 490 milioni di metadata e l'OCR come superficie di attacco

Il dato di impatto non è solo numerico. I circa 490 milioni di record di metadata — circa il 14,4% dei dati immagine secondo Help Net Security — includono informazioni tecniche che trasformano ogni screenshot in un punto di ingresso ricostruibile: image ID usati per generare URL diretti, IP di upload, user agent, dati EXIF di posizione geografica, titoli, URL sorgente e, in modo particolarmente rilevante, "OCR text extracted from images".

"Gyazo is a screenshot tool. Developers use it constantly to share what is on their screen, which means those images contain terminal output, API keys, credentials in config files, internal application screenshots, and sensitive documents... Whatever text was visible in those screenshots is now in an attacker's hands as searchable, indexed data, not just pixels" — Michael Bell, fondatore e CEO di Suzu Labs

Questa citazione, riportata da Infosecurity Magazine, delinea il problema specifico del caso. La feature OCR, progettata per rendere ricercabili le immagini, ha creato un database testuale parallelo al contenuto visivo. Un attaccante che accede a questi metadata non si trova di fronte a file binari da analizzare, ma a testo già estratto, indicizzato e interrogabile. Per sviluppatori che usano Gyazo per condividere terminal e configurazioni, il passaggio da "immagine esposta" a "credenziale ricercabile" è immediato.

Seemant Sehgal, CEO di BreachLock, ha sottolineato nella stessa fonte che "EXIF coordinates, OCR-extracted text, session IDs, and image URL construction data give an attacker enough to reconstruct user behavior and location history". La sovrapposizione tra metadata tecnici e contenuto semantico estratto costituisce il cuore del rischio di questo breach.

La privacy di Gyazo: ID a 32 caratteri e immagini "private"

The Hacker News ha analizzato tecnicamente il modello di privacy di Gyazo, basato su URL con image ID a 32 caratteri. Questa architettura, descritta dalla fonte come "security through obscurity", rende le immagini teoricamente non individuabili senza conoscere l'identificatore completo. L'esposizione dei metadata include però esattamente i dati necessari per costruire questi URL: la fonte cita Helpfeel secondo cui "information used to construct Gyazo image URLs... could be used by a third party to access and view the corresponding images without authorization".

Il dossier documenta inoltre che l'attaccante ha ottenuto "a list identifying private images" e che Helpfeel "cannot rule out the possibility that some private images may have been viewed". Le immagini private su Gyazo sono protette da passphrase, ma i metadata esposti includono "passphrase hashes for private images". L'algoritmo di hashing non è specificato nella fonte, rendendo impossibile valutare la resistenza a eventuali attacchi offline.

Gyazo ha sospeso temporaneamente la visualizzazione di alcune immagini come misura preventiva, ma il numero di immagini effettivamente visualizzate dall'attaccante resta un punto non chiarito.

Timeline e limiti del dossier

La cronologia consolidata dalle fonti converge su queste date: exploit iniziale l'11 settembre 2026, rilevazione e contenimento nella notte tra 11 e 12, correzione della vulnerabilità il 12 settembre, conferma dell'esposizione dati il 14 settembre, segnalazione alle autorità giapponesi il 15 settembre, notifica pubblica il 16 settembre.

Il brief non identifica la natura tecnica esatta della vulnerabilità nel server di upload. Non emerge alcun CVE specifico, né attribuzione a un threat actor o gruppo noto. Restano inoltre non specificati: l'algoritmo di hashing per password e passphrase, la validità dei session ID esposti, i criteri di filtro applicati per estrarre 2,4 milioni di immagini aggiuntive (un dato riportato da The Hacker News), e la timeline precisa di ripristino del servizio.

Perché è importante

Il caso Gyazo non è una violazione di database generica. Il nucleo rilevante sta nell'intersezione tra una falla di perimetro — server di upload esposto — e funzionalità di prodotto che hanno trasformato il contenuto visivo in dato strutturato ricercabile. L'OCR, progettato per comodità utente, ha creato una superficie di attacco che non richiede analisi forense delle immagini: il testo è già estratto e indicizzato.

Per il settore, il dossier offre un caso studio su due tendenze convergenti: l'accumulo di metadata a scala miliardaria e il rischio che funzionalità di "comodità" amplifichino l'impatto di un breach. Per utenti e sviluppatori, la fonte non documenta misure correttive specifiche oltre alla sospensione temporanea di alcune immagini e alla segnalazione alle autorità. La natura esatta dei token X esposti e il loro stato di revoca non sono dettagliati nel brief.

La mancanza di un advisory strutturato da vendor o ente di coordinamento CVE, combinata con l'assenza di dettagli sulla vulnerabilità del server di upload, lascia un'area di opacità che impedisce una valutazione tecnica completa del perimetro di rischio. Il brief non specifica inoltre se i 2,4 milioni di immagini con "specific filtering criteria" si sovrappongano ai 490 milioni di metadata o costituiscano un set separato.

Fonti

• https://www.helpnetsecurity.com/2026/09/21/helpfeel-gyazo-data-breach/
• https://thehackernews.com/2026/09/gyazo-breach-exposes-2362-million-user.html
• https://www.infosecurity-magazine.com/news/experts-gyazos-breach-490-million/
• https://www.schneier.com/blog/archives/2026/09/reverse-engineering-flock-cameras.html
• https://www.bleepingcomputer.com/news/security/gyazo-server-flaw-exploited-to-steal-236-million-user-records/
• https://www.bleepingcomputer.com/news/security/sakura-internet-hack-exposes-data-of-up-to-136-million-accounts/
• https://www.bleepingcomputer.com/news/security/ernst-and-young-discloses-data-breach-after-support-system-hack/
• https://www.schneier.com/essays/archives/2024/05/llms-data-control-path-insecurity.html
• https://thehackernews.com/
• https://thehackernews.com/p/upcoming-hacker-news-webinars.html
• https://thehackernews.com/search/label/Threat%20Intelligence

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti