Gyazo: Command Execution Exposed 490M Records

A flaw in Gyazo's image upload server gave an attacker arbitrary command execution, then the database. It was contained in overnight and still lost 23.62 million account records.

Stop Execution Before Exfiltration
  • September 22, 2026

A hacker managed to exploit the vulnerability within Gyazo’s picture uploading server on September 11, 2026. After obtaining remote control over Helpfeel’s machines, the hacker gained access to its backend database. It was discovered that night, and the attack was stopped before dawn. The files had already been extracted.

What Is Known About The Entry Point

The vulnerability had three features according to HelpFeel. First, it was found in the image upload server. Second, exploitation would yield arbitrary command execution, followed by database access containing both user data and images.

Anything else was still undisclosed. No CVE number has been revealed or assigned yet. Nothing is said about the category of the flaw, the request triggering the flaw, and whether the vulnerable path needs authentication.

This is important for determining potential vulnerabilities anywhere else. The lack of the flaw class means there would be nothing to pattern-match with other image upload handlers. No authentication boundaries mean there would be nothing to determine whether a similar flaw is present anywhere else.

What is the Gyazo breach? A breach in September 2026 targeting HelpFeel, the Japanese company running the Gyazo screenshot sharing site. Through exploitation of the vulnerability in the image upload server, arbitrary command execution happened, allowing the hacker to gain access to the database containing 23.62 million user data and 490 million image metadata data. No payment card data were compromised.

The Timeline, In JST

September 11. Exploitation and arbitrary command execution on the upload server. Abnormal behaviour is detected that evening and investigation begins.

Early on September 12. Confirmed intrusion routes are blocked and the third party’s connections severed. Patching of the vulnerable code completes later the same day.

September 14. Database access and exfiltration are confirmed. Emergency maintenance halts image delivery.

The following day. Delivery is partially restored, authentication data is invalidated or restricted, and the filing goes to Japan’s Personal Information Protection Commission.

September 16. Public notice.

Detection to containment runs overnight. Intrusion to public disclosure runs five days.

The Account Records

Roughly 23.62 million user records were confirmed as leaked. Information like display name, email address, hashed passwords, user ID, device ID, session ID, X integration tokens, Google SSO email addresses, profile information, language preferences, timestamp of registration, timestamp of last login, subscription level, billing status and usage statistics were present.

Of these, three fields contain live credentials while the other two are just descriptive. Session ID is used to authenticate a web browser which is already logged in. An X integration token is an OAuth grant for a different platform. Google SSO email addresses point to the federated account associated with the login.

According to HelpFeel, the authentication credentials were invalidated and restricted upon discovery. This was the right step, but also explains why password reset alone would not suffice in this case. The hashing algorithm for the passwords is unknown. Credit card data was not compromised.

What Your Screenshot Metadata Gives Away Without the Image

WHAT ONE METADATA RECORD CAN REVEAL

The image identifier, which is the entire access control for an unlisted capture.

The upload IP address, which places a person or an office on the map.

The device and browser, which narrows things down to a specific machine inside an organisation.

Location coordinates, where the original file carried them and the service kept them.

Extracted text from the picture, so the contents are readable without ever fetching the image.

The capture title and source page, which together name the system that was on screen.

MYTH VS REALITY
Common belief
What is actually true
“Metadata is harmless compared with the file.”
A record with extracted text and the file’s identifier can stand in for the file.
“An unlisted link is private.”
It is unguessable, not private. Once the identifier is known, nothing stops a request.
“Hashed passwords are safe.”
Hashing buys time. Reused and common passwords still fall to offline cracking.
“Resetting passwords ends the exposure.”
Sessions and connected-account tokens are separate credentials and need separate invalidation.
“Old uploads stop mattering.”
Retained captures stay addressable for as long as the service keeps them.
“Screenshots are not corporate data.”
They are whatever was on screen, which is often internal systems.
WHO RELIES ON CAPTURE AND SHARE TOOLS
01

Software engineering: Bug reports and incident threads push error output, stack traces and consoles into third-party services.

02

IT support & helpdesk: Screens captured to guide users routinely show admin consoles and configuration panels.

03

Design & marketing: Drafts and competitor pages are shared for comment before anything is public.

04

Finance & operations: Reports, invoices and dashboards are captured for quick sign-off instead of approved exports.

05

Education: Coursework and grading discussions pull student information into consumer tools.

© 2026 XCITIUM THREAT LABS

The Metadata Store

There are two distinct numbers. It was found that there were about 490 million image metadata entries leaked, representing roughly 14.4% of all image metadata. These include images that were registered till January 2019. Additionally, there were 2.4 million records that have been filtered using some unknown filter.

If the two groups intersect in any way, it is not mentioned, so the two numbers can’t be summed up.

Metadata included: image ID, source IP address, User-Agent header, geolocation data (in case of EXIF), OCR text, title, referrer URL, and hash of the passphrase.

OCR Text Is Content, Not Metadata

Gyazo obtains text from images by means of optical character recognition, and this text is contained in the documents that have been leaked.

It is the one that elevates the importance level of the event under discussion. Metadata describes a file, here it contains the exact content of the file in a greppable format.

The only thing an attacker should do with such documents is not to download any image at all; text describes systems shown on the screenshots, interface used as well as any text written in it. Source IP and geolocation EXIF are in the same row, and referrer URL specifies the website where the screenshot has been taken from.

Image IDs Function As Access Tokens

The Gyazo URLs are formed based on the image ID. The ability to view an unlisted capture depends on knowing the image ID rather than verification of the requesting individual.

Thus, leaked IDs can form URLS. HelpFeel stopped delivering the images of interest on September 14, and by September 15, it restored access to any newly posted images but left the already exposed ones unavailable.

Additionally, private images have an extra passphrase, and its hashes were found in the same data. File listings for private images have also been accessed, so it cannot be ruled out that they were viewed. No viewing had been confirmed at that point.

Machine Clock Against Human Clock

The response was competent. Detection came the same evening and containment came overnight. Notification to the regulator followed inside four days. The public notice then enumerated specific field categories rather than hiding behind generalities. Set that against a lender that took 96 days from finding an intrusion to telling 1.2 million people and the gap in discipline is wide.

The outcome barely moved. Both incidents end with the records gone.

Detection and response run on a human clock, in evenings and early mornings and business days. A SELECT against a large table runs on a machine clock and completes before an analyst has finished reading the first alert.

Which places the decisive moment earlier than any of it. Arbitrary command execution on the upload server is the event that made the rest arithmetic. Once code the operator never wrote is executing inside the upload path, the remaining variables are scope and duration. Governing what unrecognised code is permitted to do at the instant it executes is the only control operating on the same clock as the extraction.

Conclusion: Command Execution Made the Rest Arithmetic

The Gyazo breach shows how quickly a server-side execution flaw can turn into a data-loss event. Once the attacker gained arbitrary command execution through the image upload server, the problem was no longer limited to the vulnerable request path. The compromised server became a route into backend data holding authentication-related records and hundreds of millions of image metadata entries.

Helpfeel detected abnormal activity the same evening and blocked the identified intrusion routes by the following morning. That response was fast. It was still slower than the machine performing the extraction. By the time investigation established the full scope, user-related records and image metadata had already left the environment.

The affected data also illustrates why breach impact cannot be measured by record count alone. Session identifiers and integration tokens carry authentication value. Image IDs can help construct URLs. EXIF data can reveal location. OCR text can expose the actual content visible inside screenshots, including information that users may never have considered searchable database content.

Why This Threat Matters

  • Remote command execution changes the security boundary immediately. Once unauthorized code runs on the server, downstream databases and services become part of the attack surface.
  • Fast response does not undo earlier execution. Blocking the intrusion route stops continued access but cannot reverse data already extracted.
  • Metadata can contain operationally sensitive content. OCR text, source URLs, IP addresses, geolocation data, and image identifiers can reveal far more than conventional file metadata.
  • Authentication material requires separate recovery actions. Session IDs and integration tokens need invalidation or restriction independently of password changes.
  • Patching and compromise assessment are different tasks. Fixing the vulnerability closes the known route. It does not establish what commands were executed before the fix.

Where Defensive Control Must Operate

Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, is the primary endpoint and workload layer once exploitation reaches command execution, helping expose unfamiliar processes, malicious payloads, persistence, and follow-on activity.

Execution Governance adds the critical runtime decision by restricting what unknown or untrusted code is permitted to do when it executes, rather than waiting for post-execution evidence to establish that the activity was malicious.

Govern the First Command, Not Only the Aftermath

For internet-facing workloads, the decisive security moment occurs when attacker-controlled code first attempts to execute. Patch the vulnerable application, investigate commands and processes launched before remediation, invalidate exposed authentication material, and determine what backend resources the compromised server could reach. Detection explains what was observed. Runtime enforcement reduces what untrusted code can do before human response begins.

Like what you see? Share with a friend.

Move Away From Detection With Patented Threat Prevention Built For Today's Challenges.

No one can stop zero-day malware from entering your network, but Xcitium can prevent if from causing any damage. Zero infection. Zero damage.

Book a Demo