Who this is for: anyone who has used Gyazo, and anyone who runs an image or file upload feature. This article is based on the operator's official notice and contains no attack techniques.
What happened (per Helpfeel)
On 16 September 2026, Helpfeel Inc. announced a data leak caused by unauthorised access to its image-sharing service Gyazo. Everything below comes from the company's official notice.
11 Sep 2026
A third party exploited a vulnerability in Gyazo's image upload server and ran arbitrary commands on the company's systems. Suspicious behaviour was detected that same night, and investigation and response began.Early hours of 12 Sep
Intrusion paths blocked and the third party's unauthorised connections cut.14 Sep
The leak was confirmed and precautionary measures taken.15 Sep
Further measures against secondary harm. Delivery resumed for images uploaded after the fix. Reported to the Personal Information Protection Commission.16 Sep
The confirmed scope and impact were published. A forensic investigation by an external specialist continues.
- User records, ~23.62M
- Display name (any name or nickname), email address, password hash, user ID, device ID, login session ID, X (Twitter) integration token (if linked), Google SSO email (if linked), profile data, language, registration and last-login timestamps, plan, billing status, usage statistics. Which items apply differs from user to user
- Image metadata
- Image ID, upload IP address, User-Agent, EXIF location, OCR text of the image, title, source URL, hashed passphrases for private images
- The images themselves
- No loss of image data confirmed. But the company "cannot fully rule out that some private images were viewed by a third party"
- Payment data
- Card numbers and other payment data were not leaked, the company confirms
- Authentication data
- After reviewing how each item works and could be misused, the company says it has already invalidated or restricted what was needed
- Cause
- A vulnerability in the image upload server — now fixed, with every path used in the intrusion blocked. The specific vulnerability has not been named
How to read it: 23.62 million is not a headcount, and 490 million is not images
The ~23.62 million figure includes anonymous accounts with no registered email address; the company says the number of people whose personal data actually leaked is still under investigation. The ~490 million figure counts records of information about images (metadata), not image files.
Neither means "nothing to worry about". As the next section shows, the contents of that metadata are a risk that is easy to overlook.
What the information about an image reveals
One uploaded image
Image ID / title / source URL / User-Agent
OCR text
The words on screen — keys and internal data included
EXIF location
Where a photo was taken — possibly your home
Upload IP
When, and from which connection, you uploaded
Fixed once you change it
- Your Gyazo password (its hash leaked)
- Login sessions and integration tokens (the company says it has invalidated or restricted these)
- Passwords you reused on other services
Not fixed until you change it at the source
- API keys, passwords, invite links that appeared in screenshots
- Customer data or internal documents that appeared in screenshots
- Where a photo was taken (a location cannot be changed)
What users should do today
Change your Gyazo password
This is the company's first request. What leaked is a hash, not the password itself, but the hashing method has not been published, and as a general rule short or common passwords are the easiest to recover (how it works: what password hashing is). Change it by opening Gyazo yourself, not by following a link in an email.
Change it on every service where you used the same — or a similar — password
The company asks you to change passwords on other services where you used "the same or a similar password". "Similar" matters: a password with only the trailing digits changed counts as the same one. A password manager is the practical way to find them.
Remember whether a screenshot showed a secret — and if so, revoke it
The leaked metadata includes OCR text, the words read out of each image. If you ever shared a development screen, admin panel, terminal or configuration file through Gyazo, revoke and reissue at the source any API key, token, password or invite link it showed. The metadata is described as mostly from images uploaded before January 2019 — but long-lived keys are exactly the ones that have not changed since then. How to handle secrets is covered in what's dangerous about .env and API keys and a case where a leaked API key ran up charges.
Check whether you uploaded photos with location data, and strip it from now on
EXIF location is among the leaked items. Photos uploaded straight from a phone may have carried the place they were taken. A location cannot be changed, so what you can do is change future settings: turn off location tagging in the camera, or strip location before sharing (smartphone security basics).
If you linked X or signed in with Google, review the connection
X (Twitter) integration tokens and Google SSO email addresses are among the items. The company says it has invalidated or restricted authentication data, but it is still worth opening X's list of connected apps yourself and removing any connection you no longer use.
Expect impersonation emails
Email addresses are among the leaked items. After a breach, "reset your password" emails pretending to be the operator tend to appear. Do not follow the link; open the service yourself (what phishing is).
For anyone who runs an upload feature
This site's view: they noticed the same day — and they still held old data
From a defender's point of view, this case has one thing to credit and one thing to think about.
What to credit is the speed of detection. The intrusion happened on 11 September and was detected that night, blocked by the early hours of the next day, and disclosed five days later. Among the major Japanese cases disclosed the same year, the time from intrusion to discovery ranged from 15 days to about three years (comparing 2026's four major Japanese breaches). Even when entry cannot be prevented, the sooner you notice, the smaller the damage.
What to think about is that the leaked metadata was centred on images from "mainly before January 2019". OCR text, location data and upload IPs for images uploaded years ago were still there at the time of this incident.
Keeping the images may be what users expect of such a service, but whether the surrounding data (IPs and locations) needs to be kept for just as long is a separate question. Data you do not hold cannot leak, and supporting data is where retention can most easily be shortened.
The stated cause, arbitrary command execution through a vulnerability in the image upload server, is a weak spot shared by every service that accepts uploads. The design principle of isolating the part that processes received files from the main system, and running it with minimal privileges is covered in file upload vulnerabilities; the term itself in what RCE is.
Sources
The facts above come from the following public records. No speculation about the unnamed vulnerability or intrusion details.
- Helpfeel Inc., notice and apology regarding the information leak caused by unauthorised access to Gyazo (published 16 September 2026, Japanese) — corp.helpfeel.com
- Reporting by ITmedia NEWS and Mado no Mori (16 September 2026), based on the notice above
Update log
2026-09-19: First version, based on Helpfeel's notice of 16 September. The company's forensic investigation continues, including the number of people actually affected and the potential for secondary harm; this article will be updated as details are published.
Read next
- The same year's major cases: comparing the KDDI, Aflac, Digital Agency and Sakura Internet breaches / the Times Car breach (driver's license images) / the SourceNext member data leak (22,519,960 records)
- Passwords: choosing a password manager / choosing multi-factor authentication
- Handling secrets: what's dangerous about .env and API keys / a leaked API key case
- For operators: file upload vulnerabilities / what RCE is