The Gyazo breach leaked the description of your screenshots, not the screenshots

Every write-up of the Gyazo breach leads with the count. Roughly 23.62 million user records. It's the right number to lead with if you're reporting a breach, and it's the least interesting thing in the disclosure.

The interesting part is the list. Helpfeel's own notice, published on 16 September about an intrusion on 11 September, sets out what was in the image metadata that went with those accounts. Image ID. Source IP address used for the upload. User-Agent. EXIF location data. OCR text extracted from the image. Image title. Source URL. Hashed passphrase for private images.

Read that as an inventory instead of a casualty list and it stops being a story about Gyazo accounts.

A screenshot is a picture of something else

This is the bit that I think deserves more attention than it's getting. Gyazo is a screenshot tool. That's its entire job.

A photo you take is a picture of the world. A screenshot is a picture of a screen, and the screen usually belongs to work. It's a ticket, a dashboard, an error message, a spreadsheet, a chat thread, a draft, a config file, a page somebody was midway through reading. People take screenshots precisely because something on the screen matters enough to keep or to send to somebody.

So the content of a screenshot archive isn't the user's personal life in the way a photo library is. It is a sample of whatever their employer, their colleagues and their clients had on a screen at the moment it seemed worth capturing.

Now add the OCR field. Gyazo was extracting the text from those images and storing it as a queryable field, which is a sensible product decision. It lets you find a screenshot by what it says. It also converts an image store into a searchable text corpus of other people's documents.

The difference matters because of how an attacker uses it. Images have to be looked at. Text can be grepped. A hundred million images of unknown content are a burden; a hundred million rows of extracted text with an associated source URL and an upload IP are a queryable dataset, and the notice says metadata for about 2.4 million images was separately retrieved using specific filtering criteria, which is what querying a dataset looks like.

The retention line is where this becomes a design verdict

The 490 million metadata records are, in Helpfeel's own description, associated primarily with images registered in or before January 2019.

Sit with that. The bulk of what leaked was derived data about images uploaded more than seven years ago. Not the images themselves. The extracted text, the upload IP, the location, the source URL.

Nobody decided to keep that for seven years. That's the point. Somebody built an OCR feature, the output went into a column, and the column inherited the retention policy of the table it lived in, which was probably forever because that's the default. The image lifecycle may well have had a policy. The text extracted from the image almost certainly did not, because it didn't look like user content. It looked like an index.

Derived data is the part nobody classifies

Most organisations I've worked with can tell you where their sensitive data lives. They have a classification exercise, a spreadsheet, a tag on a table. What that exercise reliably misses is the second-order stuff: the thumbnail, the embedding, the extracted text, the parsed address, the cached response, the analytics event that happens to carry a free-text field.

Derived data gets classified by what it looks like rather than by what it came from. OCR output is text, so it goes in the text bucket. An embedding is a float array, so it never reaches the personal data conversation at all. A thumbnail feels harmless because it is smaller, and a cached API response feels like infrastructure because it lives next to the cache. None of that reasoning survives contact with an incident, because the sensitivity of derived data is inherited from its source and not from its shape. It's a cousin of the point in the ZCode piece: a tool quietly collected more than its users pictured, and the gap only became legible once something went wrong.

The version of this I've run into is duller and more common: logs. A team adds a log line for debugging, the line includes a request body, the request body includes a field that nobody thought of as personal, and the log retention is ninety days because that is what the platform defaults to. It's the same mechanism. A convenience feature creates a copy, the copy is filed by format, and the retention decision is made once, by default, by whoever set up the storage.

What else is in that list

Two more items in the user record deserve a mention, because they change who the victim is.

Login session IDs and an X integration token were included. That means the exposure doesn't stop at Gyazo. A session ID is an authenticated handle, and an integration token is authority on another platform. Whatever a user connected their screenshot tool to is now part of the blast radius, and most of them won't remember what they connected.

And EXIF location data, attached to uploads. For a screenshot that's often empty. For anything uploaded from a phone camera it isn't, and it puts a place and a time against an account with a name and an email on it.

The private image passphrases were hashed, which is the one piece of good news in the inventory and worth saying plainly.

What I would check this week

Not a project. One question, asked of whoever owns your data model: which fields in our system are computed from user content, and what retention do they have?

The useful follow-up is whether anyone can answer without opening the schema. If the derived fields are not on the classification spreadsheet, they have the retention of the table, which means they have no retention at all.

The second question, if you want to be thorough, is what your extraction features produce. OCR, transcription, summarisation and embedding all take something a user uploaded and make a version of it that is easier to search. Easier for you, and easier for anyone who gets a copy.

Marking my confidence

Established. Every fact above comes from Helpfeel's own notice of 16 September 2026, which I opened: the 11 September intrusion through a vulnerability in the image upload server, access routes blocked by the early hours of 12 September, approximately 23.62 million user records, approximately 490 million metadata records associated primarily with images registered in or before January 2019, metadata for approximately 2.4 million images separately retrieved using specific filtering criteria, and the two field lists quoted as published.

Single source. This is the company's own disclosure and I haven't corroborated it against an independent technical analysis. Self-disclosure is usually accurate about categories and optimistic about scope, so treat the field lists as reliable and the counts as the company's best current figure.

Inferred. That the OCR text and the other derived fields ended up with no retention policy because they were filed by format instead of by origin. That's a reconstruction from how the data is described and from how this goes in every organisation I have seen, not something Helpfeel has said. They may have had a policy and it may have been deliberate.

Guess. That the next few years of breach notices are dominated by derived fields instead of primary records, because extraction features have been shipped much faster than anyone has reclassified their output. Held loosely.

What would change my mind. Evidence that the OCR corpus was retained under an explicit, reviewed policy. That would make this a deliberate trade-off and not an omission, and a much less interesting story, though not a safer one.

The screenshots themselves weren't in the disclosed set. What leaked was the description of them, compiled automatically, kept indefinitely, and easier to search than the pictures ever were.