Gyazo's breach leaked the OCR text inside 490 million screenshots, and the IDs that open them

Five days, and a number that is not a headcount

Count the days yourself. Helpfeel Inc., the Kyoto company that operates the screenshot service Gyazo, says the intrusion happened on 11 September 2026 and that it detected suspicious activity the same evening. It published its public notice on 16 September. That is a gap of five days between incident and disclosure, and because detection was same day, it is also five days between knowing and saying. Japan's Personal Information Protection Commission received its report on 15 September, four days after discovery.

By the standards of this genre that is fast. Say so plainly, because most of what follows is critical.

Now the number everyone has printed. Helpfeel says approximately 23.62 million records containing data related to Gyazo users were disclosed without authorisation. Almost every headline has turned that into 23 million customers. Helpfeel's own notice says it is not a headcount. The English text is explicit: the 23.62 million records include records for anonymous accounts with no registered email address, and the company is still working out the actual number of individuals whose personal information was disclosed.

For scale, Gyazo's own front page in late July 2026, before any of this, advertised 23 million users, 242 countries and regions, and 3.1 billion uploads. So 23.62 million records is, to within a few per cent, the whole book. Whatever the headcount turns out to be, the sensible planning assumption for a UK security team is that every Gyazo account your staff have ever opened is in the set.

The question nobody is asking: what is actually inside a screenshot service

Almost all the coverage has treated this as an account breach with an unusually large side order of metadata. That gets the story backwards.

A screenshot is the densest payload of credentials and personal data per byte on the internet. People screenshot one-time codes, password manager windows, internal dashboards, private chats, customer records, invoices, bank statements and error traces full of tokens. They do it precisely because a screenshot is quicker than describing the thing. And a screenshot sharing service is the one place where that payload is uploaded to a third party, indexed, and given a permanent public address, all in a single keystroke. Gyazo's marketing described that as a feature: capturing, uploading and generating a shareable link, all done in one action.

So the question is not how many accounts leaked. It is whether image content or only account metadata was exposed, and whether the links to images are guessable or long random tokens. A private image behind an unguessable URL is only private while the URL is secret.

Answering that means knowing what such a service holds. From Gyazo's own published API documentation and from the incident notice, one capture produces four distinct things:

• The image file. The pixels, served from i.gyazo.com under the image identifier.
• The derived index. Gyazo runs optical character recognition over every capture. The API returns an ocr object carrying a locale and a text description. Alongside it sit the image title, the name of the application captured from, the source URL of the page, the upload IP address, the User-Agent, and EXIF location data where the image carried it.
• The link. A 32 character lowercase hexadecimal image identifier, used as both the page address on gyazo.com and the file name on i.gyazo.com.
• The account. Name, email address, password hash, user identifier, device identifier, login session identifier, an X integration token where the user connected X, and the Google SSO email address where the user connected Google.

Hold that list against the leak. Helpfeel confirms the derived index, the link identifiers and the account records were all disclosed. The image files are the one store it does not place inside the breach, and it does not place them outside it either.

The OCR field is the part to sit with. It means the text inside the screenshot was already extracted, stored server side as text, and made searchable, before any attacker arrived. So for every capture in the leaked set that contained legible writing, the attacker did not need the image at all. The readable content was in the metadata. That is why calling this a metadata breach understates it: for a screenshot service, the metadata is a transcript.

The quantity is the operator's own figure. Approximately 490 million image metadata records, which Helpfeel describes as roughly 14.4 per cent of all image-related data, mainly for images registered in or before January 2019. Divide 490 million by 0.144 and you get about 3.4 billion, which sits within about ten per cent of the 3.1 billion uploads Gyazo advertised in July. The percentage and the marketing figure corroborate each other. A separate 2.4 million image metadata records were retrieved using specific filtering criteria, which reads like targeted selection rather than bulk extraction, although Helpfeel does not say what the criteria were. Nor does it say whether the 490 million and the 2.4 million overlap.

Stated by the operator, and not stated

Everything in the left column comes from Helpfeel's notice of 16 September 2026, in the English text the company published itself. The right column is what the notice does not say, checked against the 18 September follow up and against Helpfeel's news index as at 23 September 2026.

Gyazo breach: what Helpfeel has stated against what it has not, from the incident notice of 16 September 2026 and the follow up of 18 September 2026.

Item	Stated by Helpfeel	Not stated
Record count	About 23.62 million user records. About 490 million image metadata records, plus about 2.4 million retrieved under filtering criteria.	Whether the 490 million and 2.4 million sets overlap. No revised figure since 16 September.
What a record means	Data related to a Gyazo user. Types and extent vary by user. Anonymous accounts with no registered email are included.	How many individuals. Helpfeel says it is still determining that. Whether one person can hold several records.
Image content	A list identifying private images was obtained. Helpfeel cannot rule out that some private images were viewed. No loss of image data confirmed.	Whether any image file was actually read. How many private images were on the list. Anything at all about public images being viewed.
Image URLs in the data	Yes. Image IDs, described as the information used to construct the image URL, were in the leaked metadata and could be used to view images.	How image IDs are generated. Whether identifiers for images after January 2019 were reached beyond the 2.4 million set.
Password hashing	Passwords were held as hash values. All users are asked to change their password, and any reused password elsewhere.	The algorithm. The work factor. Whether the hashes were salted. Same silence for the hashed private-image passphrases.
Linked account tokens	X integration tokens where X was connected. Google SSO email addresses where Google was connected. Authentication data has been invalidated or restricted.	Which credentials were invalidated, and when. No Google OAuth token is named, only the email address. No count of connected accounts.
Notification to users	Emails planned to affected users, with in-product notices for anonymous accounts. Recipients to be decided as the investigation proceeds.	Whether any notification has yet been sent. No date. No criteria for who qualifies as affected.
Discovery against disclosure	Intrusion and detection 11 September. Containment by early 12 September. Exfiltration confirmed 14 September. Regulator 15 September. Public 16 September.	When the vulnerability was introduced. Whether the attacker held access before 11 September. The vulnerability class, and any CVE number.

A link is only private while the link is secret

Gyazo's documented image identifier is 32 hexadecimal characters, the example in the API reference being 8980c52421e452ac3355ca3e5cfe7a0c. That is an address space of 16 to the power of 32, which is about 3.4 times ten to the power of 38 possible values. Nobody guesses their way into that. Which is exactly the point, and exactly the trap.

Gyazo's upload API documents an access_policy parameter with two values. The default is anyone, and the documentation states plainly that it means anyone with the link can view the image. The alternative is only_me. A third mechanism exists for private images protected by a passphrase, because Helpfeel lists hashed private-image passphrases among the leaked fields.

So the default sharing model is a capability URL: possession of the address is the authorisation. That model has one failure mode, and it is total. It does not degrade when the secret leaks. It inverts. An unguessable identifier that appears in a stolen database is no longer unguessable, it is enumerated. Helpfeel says as much: the affected metadata includes information used to construct Gyazo image URLs, and this could be used by a third party to access and view the corresponding images. The company temporarily disabled viewing of some images in response, which is a reasonable emergency measure and also an admission of how thin the control was.

There is one more structural detail worth knowing. Gyazo publishes an oEmbed endpoint that takes an image page URL and returns the raw file URL, its width and its height. Unlike the other documented endpoints it takes no access token. That is normal for oEmbed and useful for embedding, but it confirms the architecture: for a default-policy image, the identifier is the access control, and nothing else stands behind it.

Two comforting labels that are not controls

The first label is metadata. In most breaches the word is a genuine mitigation: metadata means timestamps and identifiers rather than content. At a screenshot service running OCR over every upload, metadata means the words that were on the screen. Anyone reading 490 million image metadata records as a lesser category than 23.62 million account records has the severity ordering upside down.

The second label is hashed. Helpfeel says passwords were held as hash values and that private-image passphrases were hashed. It names no algorithm, no work factor and no salting, and a week after disclosure it still has not. The reflex in the industry commentary was to treat the word as reassurance on its own. Filigran's Damian Skeeles, quoted in Infosecurity Magazine, offered a fair version of it: "In any case, they are hashed, which will reduce risk exposure." That is true as far as it goes, and it does not go far. Hashed with bcrypt at a sensible cost factor is a different fact from hashed with unsalted SHA-1, and only the operator can tell you which. Until it does, the honest position for a defender is that the word carries no information.

The same reasoning applies to the login session identifiers in the account data. Helpfeel says it has reviewed the technical characteristics of the authentication-related information involved and already implemented invalidation and restrictions. It does not say which credentials those measures covered, nor when they took effect relative to 11 September. Session identifiers and an X integration token in an attacker's hands between the intrusion and the invalidation is a window, and the notice does not size it.

What the Japanese regime requires, and what a UK reader can rely on

Helpfeel reported to Japan's Personal Information Protection Commission on 15 September. The Commission's published guidance requires a preliminary report promptly, which it glosses as approximately within three to five days of discovery, for incidents including any breach numbering more than 1,000 people and any breach arising from an act carried out with an unlawful purpose. Four days from discovery puts Helpfeel inside that window.

The second deadline matters more, and it has not arrived. Where a breach may have been caused by an act carried out with an unlawful purpose, which covers third-party intrusion, the Commission allows the definitive report within 60 days of the date of discovery. Discovery was 11 September 2026. Sixty days from that date is 10 November 2026. That is the date by which the record count, the definition of a record, and the scope of image access should stop being provisional in the regulator's file, whatever appears on the public page.

For a UK reader the next question is which regulator you would go to, and the answer is uncomfortable. Gyazo's privacy policy, as published in English by Helpfeel and archived in July 2026, contains no reference to the UK GDPR, the EU GDPR, the European Economic Area, or a UK or EU representative. The document closes by stating that it is executed in Japanese, and that Japanese "shall be the governing language and any translation of this Policy into any other language is for convenience of reference only". The company address given for data requests is in Kamigyo-ku, Kyoto.

Credit where it is due on the incident itself: Helpfeel published a full English version of the 16 September notice, not a summary, and it is complete. But the 18 September follow up covering the impact on its Helpfeel and Cosense products exists only in Japanese, and as at 23 September the company's English news index carries exactly one item. A UK organisation tracking this incident is reading a Japanese page, or waiting.

Two other checks came back empty, and the emptiness is a finding in itself.

Have I Been Pwned has no Gyazo or Helpfeel entry. That is checked against the service's own breach API on 23 September 2026, which listed 1,038 breaches with the most recent addition dated 22 September. So the standard self-service question a UK employee asks, whether their address was in it, currently has no answer from the usual place. Twelve days after the intrusion, the only authority on who was affected is Helpfeel.

And no reputable researcher has published a sample analysis. There is no CVE, no vulnerability class beyond the phrase "image upload server", and no credible report of the data appearing for sale. The Japanese incident aggregator piyolog, which tracked the case closely on 17 September, records the same gaps, noting explicitly that neither the vulnerability type nor a CVE number has been disclosed. Everything technical anyone knows about this breach comes from the party that suffered it.

Why your data loss prevention rule did not fire

Most UK organisations that are exposed here are exposed through personal accounts used for work content, and most of them have data loss prevention controls that were supposed to catch exactly that. They usually do not, for four separate reasons that compound.

There is no file upload event to watch. A screenshot tool captures a region of the screen into memory and posts it straight to the vendor's upload endpoint, in Gyazo's case a dedicated host at upload.gyazo.com. There is no file picker, no attachment dialog, no document leaving a managed folder. Endpoint rules keyed on a user choosing a file to upload never see it, because the user never chose a file.

The payload is pixels. Content inspection built around regular expressions for card numbers, National Insurance numbers or key formats reads text streams. A PNG of a terminal window containing an API key is, to that inspector, an opaque blob. Optical character recognition on outbound traffic is available in several suites and is very rarely switched on, because it is expensive at line rate. The irony is exact: the vendor ran OCR on the content and your egress controls did not.

The sensitive artefact that travels internally is a URL. After the upload, what gets pasted into Slack, Teams, Jira or an email is a short link. Nothing that looks like data crosses your boundary again. A control watching for confidential content in messages sees a string of hexadecimal.

The destination looks benign. gyazo.com is a widely used, long-established productivity domain. It is on allow lists, it is categorised as software or business tools by most web filters, and blocking it produces immediate complaints from engineers and support staff who rely on it. Shadow IT discovery tools that score applications by risk category tend to rate screenshot utilities low, because the category is judged on the service and not on what people put into it.

What to do, in the order worth doing it

The question that exposes the gap

Helpfeel moved quickly, published in two languages, told the regulator within the window, and was candid enough to say that its own headline number is not a headcount. Those are not small things, and plenty of larger companies have done worse with more time.

But the notice answers the question the industry asks after every breach, which is how many records, and leaves the question a defender actually needs unanswered. Everything that would let you assess your own exposure sits in the right-hand column of that table. The algorithm behind the word hashed. Whether any image was opened. How the identifiers are generated. How many people. Which credentials were revoked, and when.

So here is the question to put to any service that holds your staff's captures, and it is worth asking before the incident rather than after. If your database were copied tonight, would the person holding it be able to read what was on our screens without ever fetching a single image file from you?

At Gyazo, for 490 million captures, the answer is yes, and it was yes by design, because that is what the search feature was.

Key facts