Gyazo, the screenshot and media-sharing platform beloved by developers and IT professionals, has disclosed a major data breach affecting approximately 23.62 million user records — along with metadata tied to roughly 490 million uploaded images. The operator, Kyoto-based Helpfeel Inc., said an attacker exploited a vulnerability in the platform's image upload server on September 11, 2026, executed arbitrary commands, and reached into the company's database. What makes this breach genuinely unusual is not the user records, which follow a familiar pattern, but the metadata: because Gyazo makes screenshots searchable with optical character recognition, the stolen data includes extracted text from images — terminal output, API keys, credentials pasted into configuration files — now sitting in unknown hands as indexed, searchable secrets.
The disclosure, published by Helpfeel on September 16 and updated as the investigation continued, separates the exposure into two categories with very different risk profiles. Understanding the split is essential to understanding why security researchers are treating this incident as more than a routine credential leak.
The timeline
According to Helpfeel's official notice, the sequence unfolded quickly. On September 11, 2026, a third party exploited a vulnerability in Gyazo's image upload server to gain unauthorized access and execute arbitrary commands. That evening, the company detected suspicious activity and began investigating. By the early hours of September 12, it had blocked the identified access routes and terminated the attacker's connections. On September 14, further investigation confirmed that the attacker had accessed the database and extracted data; the company suspended some image delivery while implementing additional safeguards. On September 15, Helpfeel reported the incident to Japan's Personal Information Protection Commission. On September 16, it published its public notice. On September 24, it provided an update on the suspended service and security measures, and on September 27 the Gyazo service resumed following verification efforts.
The response timeline — detection the same evening, containment within hours — compares favorably with many breach disclosures. But the speed of the response does not undo the exposure: once data leaves a network, it cannot be recalled.
23.62 million user records
The first category of exposed data is the conventional one: approximately 23.62 million records containing Gyazo user information. According to Helpfeel's notice, the data includes names or nicknames entered by users, email addresses, password hashes, user and device identifiers, login session identifiers, profile information, language preferences, registration and last-login timestamps, subscription plans, and billing status. Where users had connected third-party accounts, the records also include X (formerly Twitter) integration tokens and email addresses associated with Google single sign-on.
Two points deserve emphasis. First, 23.62 million is a record count, not necessarily 23.62 million distinct people; the figure includes anonymous accounts. Second, Helpfeel confirmed that payment card information was not among the exposed data — billing status was exposed, but not credit card numbers or other payment-method details. That is the standard credential-and-PII breach that incident responders know how to handle: force password resets, invalidate sessions, revoke tokens, and monitor for credential-stuffing attacks that reuse the stolen emails and password hashes elsewhere.
490 million metadata records — the bigger story
The second category is stranger and far larger: roughly 490 million image metadata records, tied mostly to images uploaded in or before January 2019 — about 14.4 percent of all image-related data on the platform. An additional 2.4 million records were retrieved with extra filtering, according to analysis of the disclosure.
The metadata fields read like a surveillance dossier on a decade of developer workflows: image identifiers that can be reconstructed into URLs, upload IP addresses, user-agent strings, OCR-extracted text, image titles, source URLs, hashed passphrases for private captures, and EXIF location data where present. The image files themselves were not taken — but with image IDs and URL patterns in hand, an attacker can attempt to reconstruct URLs and access uploaded content directly, including content users believed was private.
That last point is the most alarming detail in Helpfeel's disclosure. The company confirmed that the attacker obtained a list identifying which images were marked private, and said it could not rule out the possibility that some of those private images were actually viewed. For a service whose core promise is frictionless sharing, the compromise of the private-image boundary strikes at the product's reason for existing.
Why OCR makes this breach unusual
Gyazo's signature feature is what turns this incident from a large breach into a distinctive one. The platform's OCR capability extracts and indexes all visible text from every screenshot, making captures searchable. Analysts quoted in trade coverage have pointed out what that implies: the text of terminal sessions, API keys and tokens visible in browser tabs, credentials sitting in configuration files, internal application screens, database connection strings, and sensitive documents photographed or screenshotted over the years are now in an attacker's hands not as inert pixels but as searchable, indexed data.
Consider the practical reality of how developers use screenshot tools. A developer debugging a production issue captures a terminal showing an AWS secret key. A support engineer screenshots a customer's admin panel with session tokens visible. A founder shares a dashboard containing revenue figures. Each of those images was, to Gyazo's systems, a bag of searchable text — and is now, potentially, a bag of searchable text in someone else's database. Credentials can be rotated; the knowledge of which credentials existed, and where, is harder to erase.
The age of the metadata — mostly images from January 2019 and earlier — cuts both ways. Many exposed secrets will long since have been rotated. But infrastructure has long memories: old hostnames, internal IP schemes, employee names, and architectural details remain useful to an attacker conducting reconnaissance years later.
The response
Helpfeel's handling of the incident has been notably transparent by the standards of breach disclosure. The company published a detailed notice within five days of the intrusion, itemized the exposed data fields, reported to the regulator within four days, and kept the service partially suspended for nearly two weeks while implementing additional safeguards before resuming on September 27. Its investigation found no evidence of compromise at its other two services, Helpfeel and Cosense, which use separate infrastructure.
No ransom demand has been confirmed, and there has been no attribution to a specific cybercrime group. The exact technical nature of the exploited vulnerability has not been disclosed as a CVE, which leaves other organizations unable to check whether they share the flaw — a gap in the disclosure worth noting.
What Gyazo users should do
Anyone who has ever used Gyazo should treat this breach as a prompt for a deliberate audit. Change the Gyazo password and any password reused elsewhere, and revoke third-party integrations — particularly X and Google connections — then re-authorize them. Enable two-factor authentication everywhere it is offered. More importantly, think back over what was ever captured: search memory, not just the platform, for screenshots that contained API keys, tokens, passwords, or customer data, and rotate every secret that may have appeared in an image. Old screenshots die hard; the credentials in them should not be allowed to.
For organizations, the lesson is architectural. Screenshot and screen-sharing tools are part of the shadow data estate: they accumulate sensitive material with none of the governance applied to code repositories or document stores. Data-loss-prevention policies that ignore the tools employees use a dozen times a day are policies with a Gyazo-sized hole in them. Classify what may be captured, restrict sharing defaults, and treat OCR-indexed image stores with the same seriousness as any database — because, as this breach demonstrates, that is exactly what they are.
Sources
