Gyazo breach exposes 23.6 million accounts, including session IDs and X integration tokens
An attacker reached Gyazo's database through its image upload server and took 23.62 million user records: emails, password hashes, login session IDs, device IDs and X integration tokens, plus 490 million image metadata records.
Helpfeel, the Kyoto company behind the screenshot service Gyazo, disclosed on September 16 that an attacker exploited a vulnerability in Gyazo's image upload server, ran commands on its systems and accessed the Gyazo database. The intrusion was detected on the evening of September 11, Japan time, and blocked and patched early on September 12. About 23.62 million user records were exposed, including email addresses, password hashes, user and device IDs, login session IDs, X (Twitter) integration tokens and Google sign-in email addresses. A further 490 million image metadata records, mostly from 2019 or earlier, included upload IP addresses, EXIF location data and OCR-extracted text. Helpfeel has asked every user to change their password and says it invalidated or restricted the exposed authentication data, without specifying which. It has not disclosed the password hashing algorithm.
Why it matters
The password reset is the least important part of this list. Session IDs and third-party integration tokens are live credentials in their own right: a stolen session skips the password and any MFA entirely, and a password change only helps if the service also kills existing sessions. Helpfeel says it invalidated exposed authentication data but not which kinds, so affected users should sign out of every session, and anyone who connected Gyazo to X should revoke that app from X's connected-apps settings rather than wait for Helpfeel to confirm.
For everyone else, the lesson is about what your own breach notice would be able to say. If session identifiers and OAuth tokens sit in the same database as the user table, one database read yields replayable access. Hash or encrypt session identifiers at rest, store third-party tokens separately and encrypted, and make "revoke every active session" a single operation you can run in an incident. With the hash algorithm undisclosed, assume these hashes will be cracked and feed credential stuffing elsewhere. See session cookie theft.
Source: The Hacker News
Related on Start with Identity
- BlogChick-fil-A's second credential stuffing breach in three years hit 13,322 loyalty accounts
Automated login attempts using credentials obtained from a third-party source, not a Chick-fil-A breach, compromised 13,322 Chick-fil-A One loyalty accounts ove
- BlogBitget's $388 million theft ran on legitimate admin credentials through a third-party security product
Attackers exploited a zero-day in an unnamed security product Bitget used, reached an internal management system, and inserted withdrawal commands while posing
- BlogInfostealers are draining Claude subscriptions with stolen session cookies, no password needed
Anthropic warned that commodity infostealers are lifting Claude session cookies from browsers and replaying them to drain paid usage. No password, no MFA prompt
- CVECitrix Bleed, session-token leak from NetScaler ADC
A buffer over-read on NetScaler ADC/Gateway leaked session tokens in the clear. Attackers replayed them and skipped the login, including MFA. CISA KEV. October
- GlossaryDevice Bound Session Credentials (DBSC)
Device Bound Session Credentials (DBSC) is a web standard that binds a browser session to a private key held in the device's hardware, so a session cookie stole
- GuideDevSecOps Identity Integration Guide: Securing CI/CD Pipelines and Developer Workflows
Integrate identity security into DevSecOps workflows covering CI/CD pipeline identity, secrets management, service account governance, and OIDC for GitHub Actio