The Gyazo Data Breach: When “Metadata” Becomes a Security Problem
A data breach does not always mean someone stole the files you thought were most important.
Sometimes, the information surrounding those files can be enough to reveal far more than expected.
The Gyazo data breach is a significant example. Helpfeel, the company behind the image-sharing service Gyazo, confirmed unauthorized access to its systems after an attacker exploited a vulnerability in Gyazo’s image upload server. The incident resulted in the exposure of approximately 23.62 million user records and hundreds of millions of image metadata records.
But the numbers are only part of the story.
The more important question for organizations is:
What information are you protecting that you don’t actually consider sensitive?
Because metadata can sometimes tell a story even when the original file is not directly exposed.
What happened in the Gyazo data breach?
According to Helpfeel’s investigation, an unauthorized third party exploited a vulnerability in Gyazo’s image upload server on September 11, 2026.
The attacker was able to execute arbitrary commands and gain unauthorized access to the service’s systems.
Gyazo detected suspicious activity that same evening and blocked the identified access routes by the early hours of September 12. The subsequent investigation found that the attacker had accessed the Gyazo database and disclosed user information and image-related metadata.
SecurityWeek initially reported that approximately 23.6 million user records and approximately 490 million image metadata records had been accessed.
Helpfeel’s investigation has since provided additional information.
As of its September 25 update, the company confirmed:
- Approximately 23.62 million user records were affected.
- Approximately 490 million image metadata records were affected, primarily involving images uploaded in or before January 2019.
- Approximately 2.4 million additional image metadata records were retrieved using specific filtering criteria and remain under investigation.
- Approximately 174 million metadata records associated with previously deleted images were also exposed.
- The newly identified deleted-image exposure concerns metadata, not the deleted image files themselves.
The investigation remains ongoing.
That last point matters.
A breach investigation is not finished simply because the initial number has been published.
What information was exposed?
The affected user records did not contain one identical set of information for every user.
Helpfeel said the exposed information may include:
- Names or nicknames
- Email addresses
- Password hashes
- User IDs
- Device IDs
- Login session IDs
- Profile information
- Registration and last-login information
- Subscription information
- Billing status
- Usage statistics
- X integration tokens for connected accounts
- Google SSO email addresses for users who used that authentication method
Helpfeel also confirmed that credit card numbers and other payment information were not exposed.
The company subsequently clarified that the 23.62 million records include approximately 18.01 million anonymous-user records and approximately 5.62 million records associated with users who had registered email addresses.
That distinction is important.
23.62 million records does not automatically mean 23.62 million individuals had identical personal information exposed.
The company is continuing to determine the actual number of individuals whose personal information was disclosed.
The part many organizations may overlook: image metadata
This is where the Gyazo incident becomes particularly interesting from a digital-forensics perspective.
Metadata is often treated as secondary information.
The image is considered the important asset.
The metadata is considered background information.
That assumption can be dangerous.
Helpfeel confirmed that the exposed metadata can include information such as:
- Image ID
- Source IP address
- User-Agent
- EXIF location information, when present
- OCR text extracted from an image
- Image title
- Source URL
- Other related metadata
- Hashed passphrases associated with private images
Consider what that means.
A screenshot may appear harmless.
But the information surrounding that screenshot could potentially reveal:
Who uploaded it. Where it was uploaded from. What device or software was used. What text appeared inside it. Where the image originated. How the image may be referenced.
Suddenly, “metadata” doesn’t sound quite so insignificant.
Can image metadata expose private information?
Yes. Image metadata can contain information that creates privacy or security risk even when the original image is not directly exposed.
In the Gyazo case, Helpfeel specifically stated that some exposed metadata contains information used to construct image URLs. The company said this information could potentially be used by a third party to access corresponding images without authorization.
Helpfeel therefore temporarily disabled viewing of certain images as a precaution.
The company also confirmed that a list of private image files had been obtained and said it could not completely rule out the possibility that some private images had been viewed by a third party.
However, there is an important distinction:
The exposure of metadata is not the same thing as confirmation that every associated image file was stolen or viewed.
As of September 25, Helpfeel said it had not confirmed loss of stored image data as a result of the unauthorized access.
That distinction matters in responsible incident reporting.
What about the 174 million deleted-image records?
The September 25 update adds another layer to the investigation.
Helpfeel confirmed approximately 174 million metadata records associated with images previously deleted by users were also exposed.
The affected metadata primarily relates to images deleted in or before February 2023.
The company specifically stated that the corresponding deleted image files themselves were not included in this newly identified exposure.
This raises an important forensic question:
When an organization says data was deleted, what exactly was deleted?
The answer may not always be as simple as “the file is gone.”
Depending on how a system is designed, information associated with a deleted object can potentially remain in databases, indexes, logs, caches, backups, analytics systems, or other supporting infrastructure.
That does not mean every system retains deleted information indefinitely.
It means investigators need to understand the actual data lifecycle, rather than assuming that a delete button represents the complete disappearance of every associated record.
A breach is a timeline, not just an event
One of the biggest mistakes organizations can make after an incident is focusing exclusively on the moment of unauthorized access.
A digital-forensics investigation needs to reconstruct the sequence.
In a case like Gyazo, investigators would need to understand questions such as:
1. Initial access
What vulnerability was exploited?
2. Execution
What commands or processes were executed after access was obtained?
3. Privilege and movement
What systems, databases, accounts, or resources became accessible?
4. Data access
What information was queried or retrieved?
5. Selection
Was data accessed broadly, or were particular records targeted using specific criteria?
6. Exfiltration or disclosure
What evidence exists showing what information left the environment?
7. Persistence and follow-on activity
Did the attacker establish additional access or authentication mechanisms?
8. Detection
What activity triggered the organization’s response?
9. Containment
What access routes were blocked, and when?
10. Secondary risk
Could the exposed information be used to cause additional harm?
This is why breach investigations cannot be reduced to:
“There was a vulnerability.”
The vulnerability explains the entry point.
It does not necessarily explain everything that happened afterward.
Why the attacker’s access matters as much as the vulnerability
The vulnerability is important.
But from an investigative perspective, another question follows immediately:
What could the attacker actually do after exploiting it?
Helpfeel said the attacker exploited a vulnerability in the image upload server and was able to execute arbitrary commands. The subsequent investigation confirmed access to the database containing user information and image metadata.
That creates an investigative chain:
Vulnerability → Access → Execution → Database Access → Data Exposure
Each link needs evidence.
If an organization only patches the vulnerability without reconstructing what occurred, it may fix the doorway without fully understanding what happened inside the building.
What should organizations investigate after a similar breach?
Organizations experiencing a comparable incident should consider more than vulnerability remediation.
A broader forensic investigation should examine:
1. The original attack path
Determine precisely how the attacker entered.
Was it a vulnerability, stolen credential, exposed API, misconfiguration, compromised dependency, or another mechanism?
2. Authentication activity
Review accounts, sessions, tokens, authentication events, privilege changes, and unusual access patterns.
3. Command execution
Determine what commands or processes were executed after the initial compromise.
4. Database activity
Identify which databases were accessed and what queries, tables, records, or datasets were involved.
5. Data selection behavior
This can be particularly important.
Was the attacker simply dumping whatever was available?
Or were specific records selected according to criteria?
Targeted selection can provide investigators with additional information about attacker behavior and objectives.
6. Metadata exposure
Organizations should identify what information exists around their primary data.
That can include:
- timestamps
- IP addresses
- device information
- location information
- OCR data
- URLs
- identifiers
- application logs
- authentication records
- deleted-object references
7. Deleted data
Investigators should determine what “deleted” means within the actual architecture.
Was the record removed from the primary database?
Was it retained in another system?
Was it replicated?
Was it included in backups?
Was metadata retained?
8. Secondary access
Determine whether exposed authentication-related information could create additional risk.
In the Gyazo case, Helpfeel said it invalidated or restricted necessary authentication information as a precaution and later confirmed that the affected X integration tokens could not, by themselves, be used to log into or operate X accounts.
The lesson isn’t simply “patch your vulnerabilities”
Patching matters.
But the Gyazo incident illustrates why cybersecurity cannot stop at vulnerability management.
A vulnerability tells you where the attacker entered.
Forensics attempts to establish what happened after they entered.
That difference is significant.
An organization can remediate a vulnerability and still have unanswered questions about:
- what was accessed;
- what was copied;
- what was changed;
- what authentication information was exposed;
- what records were targeted;
- what systems were reached;
- what information remains at risk;
- and whether additional unauthorized activity occurred.
Security is about reducing the opportunity for compromise.
Digital forensics is about understanding the evidence when compromise occurs.
You need both.
What the Gyazo breach teaches us about “small” data
Organizations often prioritize obvious sensitive information:
Passwords. Financial records. Customer databases. Medical information. Identity documents.
But attackers do not necessarily need one enormous database containing everything.
Sometimes information becomes powerful because different pieces can be connected.
An IP address.
A timestamp.
An image ID.
A location embedded in EXIF data.
Text extracted through OCR.
A user identifier.
A session record.
A source URL.
Individually, these may appear insignificant.
Together, they can form a much clearer picture of a person, system, activity, or event.
That is why digital investigations are fundamentally about relationships and timelines, not just individual records.
The forensic question organizations should be asking
The most useful question after a breach is not:
“How much data was stolen?”
That is important.
But it is only the beginning.
A stronger investigative question is:
“What does the evidence allow us to reconstruct?”
Can you reconstruct the attacker’s entry?
Can you reconstruct their activity?
Can you identify the systems they accessed?
Can you determine what information was actually exposed?
Can you distinguish confirmed exposure from possible exposure?
Can you identify what remains uncertain?
And can you establish what happened after containment?
Those questions turn a breach from a headline into an investigation.
Greyhawk Manila Perspective
At Greyhawk Manila, we look at cybersecurity incidents as investigative problems, not simply technical problems.
A vulnerability may explain the opening.
A log may show an event.
A database record may show access.
But the investigation has to connect those pieces.
Who? What? When? Where? How? And what happened next?
That is where cybersecurity and digital forensics meet.
The Gyazo incident is still being investigated, and Helpfeel says it is working with external specialists while conducting additional service-wide security reviews and strengthening its security program.
The final lesson may therefore evolve as more evidence becomes available.
But one lesson is already clear:
Data does not become harmless simply because we call it metadata.
And deleting the visible file does not necessarily mean every trace surrounding that file has disappeared.
In a connected digital environment, the surrounding evidence can be just as important as the object itself.
Investigate the data. Investigate the timeline. Investigate what the evidence actually says.
Greyhawk Manila
Cybersecurity • Digital Forensics • Intelligence
- The Laptop That Looks Fine Is Usually the One That Matters
- Four Kinds of Trust, Four Ways They’re Being Broken
- The Gyazo Data Breach: When “Metadata” Becomes a Security Problem
- When the Attacker Has AI: Inside the Campaign Targeting Online Retailers
- When the Platform Isn’t Breached: What the BigCommerce–Ribon Incident Reveals About Third-Party Risk