Gyazo exposed about 492.4 million image records. Its notice cannot rule out private-image viewing

23.62 million users and two image-metadata sets are confirmed

Gyazo has confirmed unauthorised access to systems holding user and image information. Its incident notice describes two large datasets: records associated with about 23.62 million users, and metadata for about 490 million images, primarily created before January 2019. A further 2.4 million image-metadata records were affected under separate conditions.

The user data may include names or nicknames, email addresses, password hashes, user IDs, device IDs, login session IDs, profile information, latest login time, plan or billing status, an X access token and the email address used for Google sign-in. Exposure varies by account. Gyazo says payment-card data was not included.

The scale is important, but the field types matter more. Screenshot services often capture fragments of work that users never intended to publish: support tickets, internal dashboards, authentication errors, customer records and code. Metadata can make that content easier to locate and correlate.

The notice confirms the middle of the chain and leaves both ends open

OCR, EXIF and source URLs can reconstruct what a screenshot was about

Gyazo says the affected image metadata can include image IDs, source IP addresses, User-Agent strings, EXIF location data, text produced by optical character recognition, titles, source URLs and hashes of passphrases used for private images. It also says the exposed information included data used to construct image URLs.

Those fields can be combined. An IP address can suggest an organisation or location. A source URL can name an internal application. OCR can reveal text displayed inside the screenshot. EXIF may carry precise location. A title can identify a customer, incident or project. An image ID and URL-construction information may help an attacker locate the related object. The risk is therefore not limited to identity theft. It includes reconnaissance, targeted phishing, credential discovery and the exposure of operational context.

How exposed Gyazo fields can be abused

Field	What it may reveal	Example risk
OCR text	Words visible inside a screenshot	Credentials, ticket text or customer data become searchable
Source URL and title	The application and page where capture occurred	Internal-system mapping and targeted phishing
Source IP and User-Agent	Network and device context	Organisation or user correlation
EXIF location	Where a source image was created	Physical-location exposure
Image ID and URL information	How an image object may be addressed	Attempted retrieval or enumeration
Private passphrase hash	A verifier for protected images	Offline guessing if weak passphrases were used

No image loss does not mean no image access

Gyazo has not publicly described the vulnerability or the path used to enter its systems. It says it blocked the access route and fixed the vulnerability. That means a diagram of a specific exploit, malware chain or remote-code-execution path would go beyond the evidence.

The service also distinguishes loss from access. It reports no image loss, meaning images were not deleted or destroyed. That statement does not establish that no image was viewed or copied. The conservative response is to identify sensitive captures, rotate any secrets visible in them and investigate downstream access.

Rotate what the screenshot exposed, not only the Gyazo password

Organisations should focus on secrets and context rather than attempting to inventory hundreds of millions of records. A practical hunt starts with screenshots used in engineering, customer support, security operations and finance. Those workflows are most likely to contain credentials, internal URLs or personal data.

The incident is also a retention lesson. Screenshot tools are fast precisely because they make capture and sharing frictionless. That convenience can turn a temporary debugging image into a long-lived record. Teams should define approved tools, default retention, access controls and a rule that secrets must never be captured.

The 492.4 million figure is arithmetic, not Gyazo’s estimate of people

Gyazo reports approximately 490 million image-metadata records, mainly for images registered before January 2019, plus approximately 2.4 million records obtained under separately narrowed conditions. Adding them produces about 492.4 million records. It does not produce 492.4 million affected people or even 492.4 million unique images unless the two sets are known to be disjoint and one row maps to one image. Gyazo has not published that schema.

The 23.62 million user figure is a separate population. One account can have many screenshots, and an anonymous device may create images without mapping neatly to a registered person. The useful incident model therefore has three datasets: user and session data, the older bulk metadata set and the separately narrowed metadata set. Converting any one of them into a single victim count would go beyond the notice.

The three confirmed populations in Gyazo’s notice

Population	Approximate count	What the count represents
Gyazo users	23.62 million	Accounts or users with one or more affected fields
Primary image metadata	490 million	Mostly images registered before January 2019
Additional image metadata	2.4 million	Records obtained under separately narrowed conditions
Private images viewed	Not established	Gyazo cannot rule out viewing but gives no count

The affected authentication data crosses four different response paths

Password hashes, login session IDs, device IDs, X integration tokens and Google sign-in email addresses are not interchangeable. A password hash may support offline guessing, especially where a password was weak or reused. A live session identifier can matter without the password. An integration token can carry the permissions granted to the connected service. A Google SSO email address is an identifier rather than the Google credential itself.

Gyazo says it assessed the design and potential misuse of authentication-related information and applied invalidation or restrictions where appropriate. It does not identify which token types were invalidated, when the action completed or whether every affected session was terminated. Users should therefore treat the service’s password-change advice as the minimum response, not the full boundary.

The account response and the screenshot response are also different. Changing a password does not rotate an API key visible inside an old screenshot, remove an address from OCR text or invalidate a recovery code captured on screen. The sensitive object may belong to another system entirely.

A field-by-field response is more useful than one password reset

Affected field	Primary risk	Response
Password hash	Offline guessing and reuse	Change Gyazo and every similar password
Login session ID	Session replay if still valid	Terminate sessions and verify invalidation
X integration token	Connected-account access within granted scope	Review and revoke the integration
Google SSO email	Targeted phishing and account correlation	Treat as exposed identity context
OCR or screenshot text	Secrets and personal data from another system	Find and rotate each still-valid secret

Gyazo disabled image delivery because the risk was still active

Gyazo’s frequently asked questions explain why some images and share links stopped working. The company temporarily disabled access to some images to prevent secondary harm and resumed delivery for images uploaded after countermeasures were completed. That is operational evidence that the investigation was not only retrospective.

The notice says the paths used for unauthorised access were blocked and the vulnerability fixed. It does not name the vulnerability, affected component, first-access date, dwell time or logging coverage. Without those facts, nobody outside the investigation can reproduce the intrusion path or calculate how long records were exposed. The current diagram deliberately begins at confirmed unauthorised access rather than inventing the missing exploit.

Helpfeel and Cosense run on separate configurations, and Gyazo says it has not confirmed exposure from those systems. Images embedded there may still be unavailable because they depend on Gyazo delivery. That is a dependency impact, not evidence that those separate systems were breached.

The question that exposes the gap

Which private-image objects were requested using the exposed URL-construction data, and which logs can still answer that question?

The incident notice is unusually specific about fields and counts, but its central content question remains open. A list of private files was obtained, image URLs could be constructed from exposed information and viewing cannot be ruled out. The next useful update is not another aggregate number. It is the evidence Gyazo has for object access, the period that evidence covers and the users whose screenshots can no longer be assumed private.