Gyazo

On September 11, 2026 a third party exploited a vulnerability in Gyazo's image upload server and executed arbitrary commands on it. Helpfeel, the Japanese company that operates Gyazo, noticed suspicious activity that evening, blocked the access routes by the early hours of September 12 and patched the vulnerability the same day.

Helpfeel confirmed data exposure on September 14, reported to Japan's Personal Information Protection Commission on September 15, and published its notice on September 16. Five days from intrusion to public notice is fast by any standard in this report.

23.62 million user records containing email addresses, password hashes, device IDs and login session IDs. No credit card numbers were affected. Separately, about 490 million image metadata records, mostly for images uploaded in January 2019 or earlier.

The second set is the problem. Those metadata records include the IDs that form Gyazo image links, and Helpfeel confirmed those IDs can be used to view images without permission. Gyazo is a screenshot tool. People capture what is on their screen, which is invoices, dashboards, private messages, internal tickets and credentials pasted into a chat window. The company has temporarily disabled viewing of some images.

Anyone who ever used Gyazo to capture something and share it with one person. The security model for an unlisted link is that nobody guesses the URL. Publishing the ID set removes the guessing.

Session IDs are the near term risk for accounts, since a valid session can bypass a password entirely. The longer term risk is the images. A screenshot taken in 2018 and shared once in a private message is not something a user remembers, reviews or can retract, and 490 million of them now have known addresses.

Hashing the passwords was correct and it held. So was the response: detection the same evening, containment within hours, a regulator notified within four days and a public notice within five. Measured against the six month silence in the Navigate360 entry, Helpfeel did the incident response part properly.

The assumption that failed was upstream of all of it. Unlisted URLs were treated as a privacy control. They are an obscurity control, and obscurity survives exactly as long as the identifier stays secret.

The user table was well understood. Emails and hashes are a known quantity with a known remedy, and the notice handles them cleanly.

The 490 million image records are a different category, and nothing in the public notice suggests anyone knows what is in them. That is not a criticism unique to Gyazo. Nobody running a screenshot service has read 490 million user images, and the content is pixels rather than fields, so it cannot be queried.

The result is a company that can state precisely how many accounts were affected and cannot state what the exposed images show. The count was always available. The contents were not, because they had never been examined.

No group has claimed it and no extortion demand appears in the public record. An upload server vulnerability exploited for command execution is a straightforward path rather than a signature.

The absence of a claim matters less here than the age of the data. Most of the exposed metadata predates 2019, which suggests the attacker reached an archive rather than live traffic, and archives are where the oldest and least remembered material sits.

Expiring the images. Metadata for content uploaded in January 2019 or earlier was still live and still resolvable in September 2026. A retention policy on shared captures would have shrunk the exposed set to a fraction of 490 million.

Beyond that, treating an unlisted link as public. If a screenshot service assumes every link ID will eventually be known, the design questions change: what gets kept, for how long, and whether sensitive captures should carry an access control instead of an address nobody is supposed to guess.