Gyazo Breach Exposes 23.6 Million User Records and 490 Million Image Metadata Records
Gyazo Breach Exposes 23.6 Million User Records and 490 Million Image Metadata Records
Helpfeel, the Kyoto-based operator of the Gyazo image-sharing service, disclosed on September 16, 2026 that an attacker had compromised one of its servers and walked away with roughly 23.62 million user records and about 490 million image metadata records. The exposed user records include email addresses and password hashes; the metadata dump includes the IDs that make up Gyazo image links — meaning that, for years of older captures, the only secret protecting a private screenshot from the public Internet has been leaked.
What Happened
Helpfeel said the attacker exploited an unspecified vulnerability in Gyazo's image upload server, ran arbitrary commands on the company's systems, and accessed the Gyazo database. Suspicious activity was noticed on the evening of September 11, Japan time. By the early hours of September 12, Helpfeel had blocked the access routes it had identified, cut the attacker's connections, and patched the vulnerability the same day. The company confirmed on September 14 that data had been exposed, reported the incident to Japan's Personal Information Protection Commission on September 15, and published its user notice on September 16.
The exposed user records — 23.62 million of them — include names (any text the user entered), email addresses, password hashes, user IDs, device IDs, login session IDs, X (formerly Twitter) integration tokens where linked, the email address used for Google SSO where connected, profile information, language preference, registration date and time, last login date and time, subscription plan, billing status (no card numbers or other payment details), and usage statistics. Helpfeel noted the 23.62 million figure counts records, and that it is still working out the number of unique people affected, because anonymous accounts with no registered email address are included.
The Image Side of the Breach
The metadata set is much larger and arguably more dangerous. About 490 million records — roughly 14.4 percent of Helpfeel's image-related data, mostly for images from January 2019 or earlier — contain the fields a Gyazo image URL is built from, plus the upload IP, User-Agent, EXIF location data where present, OCR text the platform extracted from each image, image title, source URL, and the hashed passphrase for private images. The IDs are the very secret Gyazo's help pages describe as "long enough that a link can't be guessed." A further 2.4 million metadata records were pulled separately via "specific filtering criteria" that Helpfeel has not disclosed. Helpfeel has temporarily disabled viewing of some affected images and said it "cannot rule out the possibility that the third party may have viewed some private images."
What Should You Do?
- Change your Gyazo password now, and rotate any account that shared it. Helpfeel has asked every user to change their Gyazo password and to change it on any other service where they reused the same or a similar one. Password hashes were exposed; assume they will be cracked.
- Revoke X and Google SSO connections. X integration tokens and Google SSO email addresses were exposed for accounts that had those features enabled. Revoke Gyazo's access in your X account settings and re-authorize Google SSO after rotating your password.
- Treat any Gyazo link from January 2019 or earlier as if it has been viewed. The leaked IDs make up the unguessable part of the URL. If you shared a link with sensitive content before January 2019 and expected it to stay private by link obscurity, assume that secret is gone.
- Watch for targeted phishing that uses your metadata. Attackers now have file titles, OCR text, EXIF locations, and the original upload IP for hundreds of millions of captures. Personalized phishing built from that context will be highly convincing — treat any email referencing your Gyazo activity as suspicious.
The WAF Angle
Gyazo is the kind of consumer service that rarely appears in a WAF discussion — but the breach is a clean case study in why "we have a WAF in front of our upload endpoint" is not enough. The attacker exploited an application vulnerability, ran commands on the server, and reached the database from inside. The lesson for WAF operators is to instrument upload paths for the things a payload WAF cannot see: command-execution post-signals (unexpected outbound connections, spawned shells, database queries against the user table from non-application principals), and to enforce strict egress controls so that even a successful command-injection cannot easily reach the database tier. At the customer end, the breach also illustrates a recurring mistake: relying on long, unguessable URLs as a privacy control. The IDs were the secret; once the IDs leaked, every "private" image link was effectively public.
