The Gyazo Breach Took 490 Million Image Records Including OCR Text. Your Screenshot Tool Was Reading Your Screenshots.
Gyazo is offline. Helpfeel, the company that runs it, says an attacker exploited a vulnerability in its image upload server on September 11 and got into the database before being cut off, taking roughly 23.62 million user records and metadata for about 490 million images.
The user records include password hashes, which is the part everyone leads with. They also include X integration tokens, Google SSO email addresses, and login session IDs, which is the part that actually matters this week. And the image metadata includes OCR-extracted text, which means Gyazo had already read every screenshot you ever uploaded and turned it into searchable strings, and those strings were in the breach.
What was taken
From Helpfeel's disclosure, the exposed user data varies per account and may include names and nicknames, email addresses, password hashes, user and device IDs, login session IDs, X integration tokens, Google SSO email addresses, profile details, subscription information, billing status, and usage statistics. Payment card data was not included.
Separately, metadata for roughly 490 million images, most of them uploaded before January 2019. That metadata includes:
- Image IDs used to construct image URLs
- Upload IP addresses
- User-Agent strings
- EXIF location data
- OCR-extracted text
- Image titles and source URLs
- Hashed passphrases for private images
Helpfeel says the attackers also obtained a list identifying which images were private, and that it cannot rule out that some were viewed. It has temporarily disabled access to files whose records were exposed, and has found no evidence that data was deleted or that its Cosense and Helpfeel products were affected.
Gyazo claims around 23 million users and 3.1 billion media items uploaded. So this is most of the user base and a meaningful slice of the archive.
The hashes are the least of it
Password hashing works. A hashed password is a slow problem: the attacker has to crack it, you have time to rotate, and if you used a password manager you were never exposed in the first place.
Three other items in that list are fast problems.
Login session IDs. A session ID is not a password, it is proof you already logged in. If those sessions were still valid when they were taken, the attacker did not need your password at all. Gyazo pulling the service offline limits this, but the window between September 11 and the shutdown is the window that counts.
X integration tokens. This is an OAuth grant you made, possibly years ago, probably by clicking a button that said "share to X." It does not expire because you changed your Gyazo password. It expires when you go to X and revoke it. Until you do, it is a live credential against a different service than the one that got breached.
Google SSO email addresses. Less severe, but it tells an attacker exactly which accounts are worth a targeted phishing attempt and which Google address to aim at.
The OCR detail is the one that should bother you
Gyazo ran OCR on uploaded images. That is a useful feature, it makes your screenshot history searchable. It also means that for 490 million images, the text visible in those screenshots existed as indexed strings in a database, and that database was read by someone else.
Think about what is actually in a solo operator's screenshot history. A Stripe dashboard with revenue figures. A terminal with an API key still on screen from a debugging session. A staging environment URL. A customer support thread with a real name and email in it. A .env file you screenshotted to send to yourself. An invoice. A password reset screen.
None of that required the attacker to look at an image. It was already transcribed.
Combine that with the image IDs. Gyazo links are unlisted rather than private, which is a distinction most people never think about: the URL is hard to guess, and that is the entire security model. If the IDs used to construct those URLs are in the breach, "hard to guess" stops applying to the exposed set. Helpfeel disabling access to those files is the right call and it is also an admission of exactly this.
And there is EXIF location data, which for anyone who uploaded phone photos rather than desktop captures means coordinates.
What I'd actually do, in order
Revoke the X integration first. Go to X, find connected apps, remove Gyazo. Do this before you change any password, because it is the item most likely to still be live. If you connected Google SSO, review that grant too.
Then rotate the Gyazo password, and anywhere you reused it. Helpfeel is advising the same.
Then audit, which is the slow part. Work out what you actually put through Gyazo. If you used it during any period where you were debugging with real credentials, treat any API key that could plausibly have been on screen as exposed and rotate it. This is tedious and you will want to skip it. The OCR detail is the reason not to.
Then decide what you want from a screenshot tool going forward. The honest question is not whether Gyazo handled this well, they disclosed in five days and reported to Japan's Personal Information Protection Commission, which is better than a lot of companies manage. The question is whether you want a cloud service holding a transcribed, searchable, location-tagged archive of everything you ever put on your screen. For me the answer turned out to be no, and I did not notice I had answered yes for about eight years.
Where I might be overreacting
Most Gyazo usage is not sensitive. It is popular in gaming communities and the median uploaded image is a screenshot of a game, not a Stripe dashboard. If that describes your usage, revoke the token, change the password, and stop reading.
The 490 million metadata records also skew old, mostly pre-2019, so if you started using Gyazo recently your exposure on the image side is smaller than the headline number suggests. And Helpfeel's response has been reasonably fast and reasonably transparent by the standards of breach disclosure.
But the general lesson survives the specifics. Every OAuth grant you have ever clicked through is a credential you own and are responsible for, sitting in a service whose security you have never evaluated. The Gyazo breach is a clean, well-documented argument for going through that list once a year. I am going through mine this week, and it is longer than I expected.
Author
Lukas
@lukcombinator