Cyber & AI intelligence
Wasteland.
Briefs indexed2769
Issues28
Published Mondays07:30 CT
▣ Breach GYAZO-BREACH-23M 2026-09-18

Gyazo: Image Upload Server Exploited for Mass Data Theft

"Helpfeel Inc., the Kyoto-based software company behind the screenshot-sharing service Gyazo, has confirmed that an unidentified third party exploited a vulnerability in its image upload server on September 11, 2026…"

Helpfeel Inc., the Kyoto-based software company behind the screenshot-sharing service Gyazo, has confirmed that an unidentified third party exploited a vulnerability in its image upload server on September 11, 2026, executed arbitrary commands on company systems, and reached the Gyazo database. In its own notice published September 16, Helpfeel put the exposure at approximately 23.62 million user records and roughly 490 million image metadata records, the latter representing about 14.4% of all Gyazo image data. Coverage varies slightly in how the headline number is rendered: BleepingComputer and SecurityWeek round it to 23.6 million, while Helpfeel's Japanese and English notices, The Hacker News, TechRadar and iSec News all cite the precise 23.62 million (約2,362万件) figure. The company says no payment card data was taken, but it also concedes it cannot rule out that private images were viewed.

What Happened

According to Helpfeel's own notice, the sequence began on September 11, 2026 (Japan Standard Time), when an attacker abused a flaw in the server that handles Gyazo image uploads to gain unauthorized access and run arbitrary commands. Helpfeel says it detected the suspicious behavior that same evening, opened an investigation, and by the early hours of September 12 had severed the identified intrusion routes and cut the attacker's connections.

Accounts differ modestly on detection timing. Helpfeel's notice and Cybernews both place detection on the evening of September 11; BleepingComputer states the company "detected the suspicious activity on September 12." SecurityWeek splits the difference, reporting the attacker "was kicked out the next day." The company's own account is the more precise one and should be treated as authoritative: intrusion and detection on the 11th, eviction completed in the small hours of the 12th.

iSec News reports a fuller disclosure timeline that is consistent with the company notice: exposure confirmed on September 14, the incident reported to Japan's Personal Information Protection Commission on September 15, and the public notice published September 16. Gyazo itself was taken offline; BleepingComputer quotes a post on X stating the service is "temporarily suspended for maintenance as a preventive measure."

TechRadar characterises the intrusion as the attacker abusing a vulnerability "to upload malware, gain access to the service's servers, and run arbitrary commands." The malware-upload element appears in TechRadar's account; Helpfeel's own notice describes arbitrary command execution via the upload server vulnerability without characterising a payload. The Hacker News notes plainly that Helpfeel "has not said what kind of flaw it was."

What Was Taken

Two distinct data sets were accessed, and the second is arguably the more dangerous.

User records: approximately 23.62 million. Helpfeel's notice lists the exposed fields, which vary from user to user: name or nickname (free text entered by the user), email address, password hash, user ID, device ID, login session ID, X (formerly Twitter) integration token where the account was linked, the email address used for Google SSO where linked, profile information, language preference, registration timestamp, last login timestamp, subscription plan, billing status, and usage statistics. Helpfeel states explicitly that no credit card numbers or other payment details were included, a point echoed by SecurityWeek, The Hacker News and TechRadar.

Critically, the 23.62 million figure counts records, not people. Helpfeel says the total "include[s] records for anonymous accounts with no registered email address or similar information," and that it is "continuing to determine the actual number of individuals whose personal information was disclosed without authorization." TechRadar adds that multiple records can map to a single user, meaning the affected-individual count is certainly lower than 23.6 million. For context on scale, BleepingComputer reports Gyazo claims 23 million users worldwide and 3.1 billion submitted media items; Cybernews describes the service as having "over 3 billion uploads" and attributes its early growth to gaming communities, Minecraft in particular.

Image metadata: approximately 490 million records. Helpfeel says these relate mostly to images registered in January 2019 or earlier and amount to roughly 14.4% of all image data, plus a separate batch of about 2.4 million image metadata records the company says were retrieved using specific filtering criteria. That 2.4 million figure appears in Helpfeel's Japanese notice and is reported by iSec News; it is largely absent from the English-language coverage.

The metadata fields are the problem. Per Helpfeel's notice and iSec News, they can include image IDs (the values that construct a Gyazo image URL), upload source IP address, User-Agent string, EXIF location data where present in the image, OCR text extracted from the image, image title, source URL, and hashed passphrases for private images. SecurityWeek frames the consequence bluntly: the metadata "includes information that could allow threat actors to reconstruct and access URLs associated with images uploaded by users."

Helpfeel has also confirmed that a file listing of private images was obtained, and states it cannot completely rule out that some private images were viewed by the third party. SecurityWeek notes the company has not disclosed the volume of that private-image list. Helpfeel says its investigation has found no evidence of image data being deleted, and that Helpfeel's other products, Helpfeel and Cosense, run on separate system architecture with no confirmed data leakage, though some images displayed in those products via Gyazo may be unavailable while image delivery is suspended.

Why It Matters

The user-record haul is bad in a familiar way. The metadata haul is bad in an unfamiliar one.

Password hashes plus email addresses is a credential-stuffing kit, which is why Helpfeel is asking every user to change their Gyazo password and to change it anywhere they reused it. Cybernews notes the practical severity depends on how strong the hashing was, information Helpfeel has not published. Live login session IDs, X integration tokens, and Google SSO email addresses widen the blast radius beyond Gyazo itself: session identifiers permit account takeover without touching a password, and OAuth-style integration tokens can grant access to a linked third-party account. Helpfeel says it has reviewed the exposed authentication data against its specifications and exploitability and has already applied "necessary measures, including invalidation and restrictions."

The image metadata is the part defenders should sit up for. Gyazo's model is obscure-URL sharing: a screenshot gets an unguessable link, and possession of the link is effectively the authorisation. An attacker holding 490 million image IDs holds 490 million such links. Helpfeel acknowledges this directly, saying the leaked information could be used to access and view the corresponding images without permission, which is why it has temporarily disabled viewing of some images. The Hacker News makes the same point: the IDs that compose Gyazo image links can be used to view images without authorisation.

Then consider what is actually in those screenshots. Gyazo's core use case is capturing whatever happens to be on someone's screen and pasting the link into a chat window. Ten years of that, at enterprise and consumer scale, means internal dashboards, ticketing systems, error traces, config files, chat threads, invoices, and credentials. The exposed OCR text makes that corpus searchable without ever fetching an image: an attacker can grep 490 million extracted text blobs for "password," "api_key," "AKIA," or a target company's domain, and then pull only the high-value links. EXIF location data and upload IP addresses add a deanonymisation and targeting layer on top. Hashed passphrases for private images mean the one control users applied to sensitive captures is now itself an offline cracking target.

This is a supply-chain-adjacent exposure for any organisation whose staff used Gyazo informally. The company breached is not yours, but the screenshots may well be of your systems.

The Attack Technique

The initial access vector is confirmed and consistent across every source: exploitation of a vulnerability in Gyazo's image upload server, leading to arbitrary command execution on Helpfeel's systems, followed by lateral access to the Gyazo database. Helpfeel says it has blocked all access routes used in the incident and completed remediation of the vulnerability.

What has not been disclosed is the nature of the flaw. The Hacker News states directly that Helpfeel has not identified the vulnerability class; no CVE, patch reference, or third-party component has been named, and there is no public indication whether this was a zero-day, an unpatched known issue, or a bespoke application logic bug. TechRadar's description of malware being uploaded is consistent with a classic unrestricted-file-upload-to-webshell chain, in which an upload endpoint that fails to validate content type or storage location is used to plant an executable payload in a web-reachable path, but that characterisation goes beyond what Helpfeel itself has stated and should be treated as one outlet's framing rather than confirmed detail.

The operational tempo is worth noting for defenders: intrusion, database access, and exfiltration of hundreds of millions of records all occurred within roughly a single day, before the company's detection and containment closed the window. Cybernews makes the point directly, observing that the short time attackers spent inside was still enough to reach a very large volume of personal information. Fast detection did not prevent the loss. No threat actor has been named or attributed by any source, and no claim of responsibility or leak-site posting has been reported.

Timeline

What Organizations Should Do

  1. Treat Gyazo credentials as compromised and rotate them, along with every reuse. Helpfeel has asked all users to change their Gyazo password and to change it on any other service where the same or a similar password is used. Feed the Gyazo domain into your credential-stuffing watchlists and force resets for any corporate identity that used a Gyazo account, especially where the account was created with a work email address.

  2. Revoke and re-establish linked identity integrations. Exposed X integration tokens, Google SSO email addresses, and login session IDs mean password rotation alone is insufficient. Helpfeel says it has invalidated and restricted exposed authentication data, but users should independently revoke the Gyazo connection from their X and Google account security settings and re-authorise only after service restoration.

  3. Inventory what your people actually screenshotted. Query egress logs, proxy records, and chat archives (Slack, Teams, Discord, ticketing systems) for gyazo.com and i.gyazo.com links posted by staff. Every such link is now a candidate for unauthorised access by anyone holding the leaked image IDs. Prioritise links shared by engineering, finance, IT support, and executive assistants.

  4. Assume any secret visible in a Gyazo screenshot is burned and rotate it. OCR text extraction makes the leaked corpus keyword-searchable at scale, so obscurity provides no protection. Rotate API keys, tokens, internal URLs, and any credential that plausibly appeared in a shared capture, and check for anything that would expose internal network topology or customer PII.

  5. Audit your own upload endpoints for the same failure mode. Any service accepting user-supplied files should enforce content-type and magic-byte validation, store uploads outside the web root or in object storage with execution disabled, run processing in a sandboxed context with no database credentials in scope, and apply least privilege between the upload tier and the primary datastore. The step that turned this from a web compromise into a 23.62 million record breach was the upload server's reach into the user database.

  6. Reconsider unguessable-URL sharing as a security control, and set policy accordingly. Capability-URL models fail completely the moment the identifier space leaks. Where staff need to share screenshots of internal systems, route them through tooling with real authentication and access logging, and treat consumer screenshot services as public-by-default. Helpfeel's private-image passphrases were hashed and still exposed, which illustrates the limit of the model.

Helpfeel's investigation is ongoing and the company has said further findings may be published. The affected-individual count, the vulnerability class, and the volume of private images on the compromised file list all remain open questions.

Sources: Gyazo breach exposes 23.62 million user records and 490 million ima... | Gyazo server flaw exploited to steal 23.6 million user records | 23 Million User Records Compromised in Gyazo Data Breach  - Securit... | Notice and Apology Regarding a Data Breach Resulting from Unauthori... | Gyazo Breach Exposes 23.62 Million User Records and 490 Million ... | Gyazo data breach exposes 23.6M user records, 490M metadata records | Gyazo breach exposed 23.62 million user records and 490 million ima... | 「Gyazo」への不正アクセスによる情報漏えいに関するお知らせとお詫び