Helpfeel’s latest update on the Gyazo breach turns a big incident into a more complicated one. In its September 25 notice, the company said unauthorized access exposed about 23.62 million user records and also reached metadata tied to roughly 174 million previously deleted images. That is on top of other image-metadata exposure the company had already described. The immediate significance is not that Helpfeel has confirmed every image was taken or every user was individually compromised; it has not. The significance is that a service many companies treat as a handy screenshot tool was storing identity data, access artifacts, and a long tail of metadata about old and deleted content.
That leaves security and IT teams with a practical question: what do you do when a “small” sharing app turns out to be a sensitive system of record, and what counts as a safe restart after it comes back online?
According to Helpfeel’s September 25 update, the 23.62 million figure refers to user records, not people. It includes about 18.01 million anonymous-user records with no registered email address and about 5.62 million records tied to users with a registered email address. For image-related data, the company says the exposed categories include approximately 490 million metadata records associated mainly with images uploaded in or before January 2019, 2.4 million records retrieved under specific filtering criteria whose scope is still under investigation, and approximately 174 million metadata records associated mainly with images deleted in or before February 2023. Those are metadata-record counts, not counts of image files.
Why the metadata matters
The most useful way to read this incident is that metadata is not harmless residue. Gyazo is built for quick capture and sharing, but in many organizations it also becomes a durable visual archive of work: screenshots of dashboards, code, customer records, contracts, bug reports, product plans, chats, and credentials. Even when a company has not confirmed that image files themselves were lost, metadata about those captures can still be valuable to an attacker.
As reported by TechRadar, exposed data categories included names, email addresses, password hashes, user and device IDs, login-session IDs, X integration tokens, Google SSO-linked email addresses, profile and usage information, and image metadata such as image IDs, upload IP addresses, user agents, EXIF location data, OCR text, titles, source URLs, and hashed passphrases for private images. Helpfeel says payment information, including credit-card numbers, was not included, and says the exposed X tokens alone could not be used to sign in to or operate X accounts; related OAuth authentication information was invalidated.
That list shows why metadata expands the breach surface. OCR text can reveal what was inside a screenshot. Source URLs and image identifiers can show what internal system was captured and how it may have been shared. IP addresses, user agents, and EXIF data can place users, devices, or locations in context. For businesses, that creates privacy risk, fraud risk, competitive-intelligence risk, and a large review burden even before any image-file theft is proved.
Deleted does not mean gone
The update’s most important new fact may be the exposure of metadata for previously deleted images. That detail changes the story from a current-user-data breach to a record-lifecycle problem.
Users often assume deletion ends the risk. In practice, a screenshot service can generate multiple layers of persistence: the uploaded object, OCR output, indexing data, sharing-link information, logs, historical lookup tables, and backups. Helpfeel has not published the full technical path here, and it has not said whether the 2.4 million filtered metadata records overlap with the larger metadata categories. But the incident already demonstrates the gap between what users mean by “deleted” and what a service may still retain for operational reasons.
That matters well beyond Gyazo. Lightweight SaaS tools are frequently adopted outside formal records-management processes. A screenshot utility can sit below the threshold that triggers procurement reviews, retention schedules, or deletion testing, while still accumulating sensitive business material for years. When something goes wrong, the missing inventory becomes part of the damage. Helpfeel’s own numbers underscore that challenge: Gyazo supports anonymous use, so some corporate exposure may sit in employee-created accounts with no registered business email at all.
Restarting the service is not the same as recovering it
Helpfeel says it blocked the unauthorized access route, remediated the root-cause vulnerability, restricted or invalidated authentication information, started broader security reviews, engaged external forensic specialists, and reported the incident to Japanese regulators. As of the September 25 update, it had not confirmed misuse of personal information, loss of stored image files, or impact to Helpfeel’s separate Helpfeel and Cosense systems.
Those are meaningful containment steps. They are not the same thing as verified recovery.
When Gyazo resumed service on September 27, previously uploaded images were initially visible only to their owners, and users had to choose whether to restore earlier sharing settings. That design reduces immediate exposure by putting a hard boundary around historical links. It also turns recovery into a customer-by-customer access-control project. Someone now has to decide which old screenshots should become shareable again, whether the old audience is still appropriate, and whether broken links will disrupt a workflow, a support article, or a product record.
That is the right direction for containment, but it shifts operational work to customers and leaves key questions open: what historical metadata may already have been copied, how long those data persist elsewhere, and how an organization proves that restored sharing settings match current policy rather than yesterday’s habits.
What businesses should do now
The response starts with discovery. Companies should assume Gyazo may have been used both officially and informally, then look for that use across browsers, SSO records, proxy logs, expense systems, password managers, chat threads, documentation, and repositories containing old Gyazo links. The aim is not just to count accounts, but to find content and workflows that depended on them.
Next comes credential and session hygiene. Where employees reused Gyazo passwords elsewhere, those credentials should be rotated. Security teams should review sign-in sessions, linked integrations, and SSO or OAuth connections that touched the service, keeping in mind that exposure varied by user and that Helpfeel says it invalidated related authentication information.
Then classify the content risk. Screenshots are often treated as disposable, but they may contain regulated data, confidential customer information, internal architecture, financial details, or location information. That classification will shape who needs notice, which business owners must review old links, and whether public sharing should be restored at all.
Finally, use the incident to ask harder vendor questions than “Was the file encrypted?” Ask how deletion propagates through OCR stores, indexes, backups, logs, and URL tables. Ask what the vendor can prove about revocation and restoration. Ask for a testable plan before public links are re-enabled.
The broader lesson is not that every screenshot was exposed. It is that a tool small enough to escape governance can still become a large and persistent repository of sensitive data. In that kind of breach, getting the service back online is only the beginning. The real recovery work is knowing what the metadata says, what “deleted” ever meant, and whether the old sharing state is something the business would choose again today.
By
By
By
By
By
By
By
