A screenshot tool that most people use without a second thought just became one of the biggest data breach stories of September 2026. Helpfeel Inc., the Kyoto-based company behind the widely used image-sharing service Gyazo, confirmed on September 16 that an attacker broke into its systems five days earlier and walked away with roughly 23.62 million user records and metadata tied to about 490 million images. The official notice from Helpfeel is short on drama and long on numbers, but the scale places this among the year’s largest disclosed breaches involving a single consumer-facing tool.
What makes the Gyazo data breach different from a typical credential dump isn’t just the size. It’s the type of data involved. Gyazo built its business on frictionless screenshot sharing, where a captured image gets a unique link and anyone holding that link can view it. That model depended on those links staying unguessable. The breach exposed the very image IDs that made those links private in the first place, along with emails, password hashes, IP addresses, OCR-extracted text, and in some cases embedded location data. Outlets including The Hacker News, TechRadar Pro and Security Affairs independently confirmed the same 23.62-million and 490-million figures in their September 2026 coverage, citing Helpfeel’s own breach notification, which was dated September 16, 2026.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Happened: Gyazo’s September 11 Attack
According to Helpfeel’s account, an attacker exploited a vulnerability in Gyazo’s image upload server on September 11, 2026. In its September 16, 2026 disclosure, Helpfeel confirmed that flaw let the intruder upload malicious files and execute arbitrary commands on the underlying system. From there, the attacker moved into the database that stores account records and image metadata. Helpfeel says it detected suspicious activity the same evening and cut off the attacker’s access by September 12, but by then the database had already been read and, per multiple reports, copied.
The attack chain is fairly ordinary by 2026 standards: find a flaw in a public-facing upload endpoint, use it to gain remote code execution, then pivot to the data layer. What made it costly wasn’t sophistication. It was Gyazo’s sheer scale as a fifteen-plus-year-old screenshot service embedded in countless personal and workplace workflows, from bug reports to Slack threads to customer support tickets. A single upload server flaw ended up exposing over two decades’ worth of accumulated image metadata in one incident.
Inside the Exploit: How an Image Upload Endpoint Becomes a Foothold
Helpfeel hasn’t published a technical root-cause report beyond confirming that the flaw let the intruder upload malicious files and execute arbitrary commands, but the vulnerability class it describes is one of the most common ways attackers turn an upload feature into a full server compromise. Image upload endpoints are a persistent weak point because they must accept binary data from anonymous users, and validating that data safely is harder than it looks. Three failure modes recur across this category of breach: trusting a file’s declared extension or MIME type instead of its actual contents, which lets a disguised script pass as a JPEG or PNG; running uploads through vulnerable third-party processing libraries, since thumbnail generators and metadata extractors have a long history of parser bugs; and storing uploaded files somewhere the web server will also execute as code, so a disguised script runs the moment it’s requested.
Any one of those gaps can hand an attacker a foothold, and once arbitrary command execution is possible, the next move is almost always the same: search the compromised server for database credentials, then pivot directly into whatever data store the application uses. That two-stage pattern, an upload flaw for the initial foothold followed by a database pivot, matches Helpfeel’s own account of the September 11, 2026 intrusion, where access to the image upload server preceded exposure of the account and metadata database. Services that isolate public-facing upload infrastructure from core databases through strict network segmentation can limit how far an attacker gets even after a successful exploit. Services that don’t risk exactly what happened here: one endpoint’s flaw turning into a data exposure affecting 23.62 million records.
The Numbers: 23.62 Million Records, 490 Million Images
Helpfeel’s own language is precise: “approximately 23.62 million records containing data related to Gyazo users were disclosed without authorization,” according to the company’s notice as quoted by Security Affairs. The Hacker News’s September 2026 reporting put a figure on the image side of the breach as well, confirming roughly 490 million records of image metadata were exposed, the bulk of it tied to images uploaded in January 2019 or earlier, a cutoff Helpfeel itself cited in that same September 2026 notice â meaning some of the exposed data has been sitting in Gyazo’s systems for roughly seven years.
That gap between the two figures (23.62 million user records versus 490 million image entries) says something about how the service works: most users upload far more images than they create accounts, and a huge share of Gyazo’s stored metadata predates any recent privacy hardening the company may have added since. MLex reported that Helpfeel described its investigation as still ongoing as of mid-September, meaning the final scope could shift as forensic work continues.
Helpfeel has also attached an important caveat to that headline number: the company says the approximately 23.62 million figure reflects records, not a confirmed count of unique individuals. A single person can generate multiple records over years of using a free screenshot tool â separate device registrations, re-created accounts, or legacy entries tied to an unused email address â so the true number of distinct people affected could be lower than 23.62 million, though Helpfeel hasn’t published a deduplicated estimate. That distinction matters when comparing headline breach figures across incidents: a large record count doesn’t automatically equal an equally large number of affected people, but it doesn’t reduce the real scope of exposure either, since every record still ties back to genuine account or image data that sat on Gyazo’s servers.
What Attackers Actually Got Their Hands On
The exposed dataset breaks into two broad buckets. The first is standard account data: names, email addresses, hashed passwords, user and device IDs, login session IDs, billing information (though not card numbers), and usage statistics â a breakdown The Hacker News’s September 2026 coverage specifically confirmed, naming email addresses and hashed passwords among the exposed fields. Helpfeel has been explicit that no payment card numbers were part of the breach, a detail confirmed by both CyberInsider and Security Affairs.
The second bucket is where this breach gets more interesting, and more concerning, than a typical credential leak. It includes X (formerly Twitter) integration tokens for linked accounts, Google single sign-on email addresses and profile data for users who signed in with Google, and the image metadata itself: the IDs that construct Gyazo’s shareable URLs, EXIF location data embedded in some images, and OCR-extracted text pulled from screenshots. That last category matters because screenshots frequently contain exactly the kind of sensitive material people assume stays private â internal chat logs, spreadsheets, error messages with API keys, or personal correspondence. If the OCR layer indexed readable text from those images, that text was part of what got exposed.
Why Hashed Passwords and OCR Text Carry Different Risks
Helpfeel’s repeated point that passwords were hashed rather than stored in plaintext is a genuine mitigation, but it isn’t the same as safe. A hash is a one-way transformation: it can’t be reversed directly, but it can be attacked offline. Attackers holding a stolen hash database can run large-scale password-guessing operations on specialized hardware, checking enormous numbers of candidates without ever touching Gyazo’s servers again. Properly configured modern hashing algorithms slow that process down considerably, but Helpfeel hasn’t disclosed which algorithm protected Gyazo’s password database, so outside researchers can’t independently judge how much protection it provides. The practical guidance doesn’t change either way: any reused password should be treated as compromised, since offline cracking happens silently and gives no warning before a cracked credential surfaces in an unrelated account-takeover attempt.
The OCR data sits on the other side of that equation, because no hashing was ever involved. If Gyazo’s systems extracted and indexed readable text from uploaded screenshots to make them searchable, that text existed in the database as plain, legible content, not a scrambled derivative of it. Anyone who ever screenshotted an email thread, an internal chat log, a password manager entry, or an error message containing an API key was, in effect, storing a plaintext copy of that content in Gyazo’s OCR index, separate from whatever protected their account password. There’s no cracking required and no hash to break; sensitive text stays exposed exactly as it was written. That’s why security researchers tend to treat OCR and full-text indexing in screenshot tools as a materially higher-risk design choice than simply storing the images themselves.
Five Days of Silence: The Disclosure Timeline
The attack occurred on September 11. Helpfeel’s public notice is dated September 16, roughly five days later. Media coverage followed within another one to two days, with The Hacker News publishing on September 17 and Security Affairs and CyberInsider following on September 18. That puts the gap between the actual intrusion and the first mainstream security-press coverage at six to seven days, a window that gave Helpfeel time to contain the attacker and begin an internal investigation before facing public scrutiny, but also a window during which affected users had no idea their data was already out.
Five to seven days isn’t an unusually long disclosure delay by the standards of 2026 breach reporting, where companies often cite ongoing forensic work as the reason for a gap between detection and notification. But for a breach involving hundreds of millions of image records tied to years-old uploads, even a short delay leaves a meaningful window in which exposed image links, if they leaked further, could be accessed before anyone was warned to treat them as compromised.
How Helpfeel Is Responding
Helpfeel says it has closed the vulnerable upload server, launched an internal investigation into the full scope of the intrusion, and is notifying affected users directly. The company has also confirmed it reported the incident to Japan’s Personal Information Protection Commission, the country’s primary data protection regulator, according to MLex’s summary of the disclosure. Beyond that, Helpfeel’s public messaging has stayed high-level: an apology, a promise to strengthen security controls, and repeated reassurance that no payment card data was involved.
What’s notably absent from the public record so far is any detail on remediation specifics such as forced password resets, token revocation for the exposed X and Google SSO links, or a breakdown of how many users are in the U.S., EU, or other non-Japanese markets. Gyazo has a global user base built up over more than a decade, and how Helpfeel handles notification outside Japan will likely shape whether this becomes a purely regional story or draws attention from regulators elsewhere.
The Image ID Problem: When “Private” Links Weren’t Private
Gyazo’s core privacy model, like many screenshot and file-sharing tools, relies on obscurity rather than access control. By default, a captured image gets a long, effectively unguessable ID, and that ID is the only thing standing between a “private” screenshot and anyone who has the link. That design trades convenience for a specific kind of risk: if the list of valid IDs is ever exposed in bulk, the obscurity that protected those links disappears overnight.
That’s precisely what happened here. The breach exposed the image IDs that make up Gyazo’s share URLs, which means anyone holding the leaked dataset could, in theory, reconstruct working links to images their creators believed were private. Combined with the OCR text and EXIF location data bundled into the same metadata records, the exposure isn’t just “here’s a list of email addresses” â it’s a map that could be used to pull actual private content and, in some cases, tie it to a physical location.
Gyazo Breach by the Numbers
| Metric | Figure |
|---|---|
| User records exposed | ~23.62 million |
| Image metadata records exposed | ~490 million |
| Date of intrusion | September 11, 2026 |
| Attacker access cut off | September 12, 2026 |
| Public disclosure date | September 16, 2026 |
| Disclosure delay | ~5 days (attack to notice) |
| Data types exposed | Emails, password hashes, user/device/session IDs, image IDs, OCR text, EXIF data, X and Google SSO tokens |
| Payment card data exposed | None, per Helpfeel |
| Regulator notified | Japan’s Personal Information Protection Commission |
| Bulk of exposed images date to | January 2019 or earlier |
How Gyazo Compares to 2026’s Other Major Breaches
2026 has already produced a steady drumbeat of large-scale disclosures across very different industries, and Gyazo’s numbers put it near the top of that list by raw record count, even before factoring in the 490 million image entries. Earlier this year, CenterPoint Energy disclosed a breach affecting roughly 7.49 million records, while identity-verification vendor IDScan confirmed exposure tied to roughly 153 million IDs. A Dropbox breach linked to Lenovo’s SSO system affected a comparatively small 5,000 accounts, and hardware wallet maker Trezor saw roughly 347,000 crypto owners targeted in phishing that followed a Brevo-linked breach. A Revolut-linked incident tied to an alleged 147GB leak of Italian police data rounds out a busy year for breach disclosures across finance, identity, and infrastructure sectors.
| Breach (2026) | Scale | Primary data type |
|---|---|---|
| Gyazo / Helpfeel | ~23.62M user records + ~490M image entries | Account data + image metadata/OCR text |
| IDScan | ~153M IDs | Identity verification documents |
| CenterPoint Energy | ~7.49M records | Utility customer data |
| Trezor-linked phishing (Brevo) | ~347K targeted | Crypto wallet holder contacts |
| Dropbox (Lenovo SSO) | ~5K accounts | Cloud storage account data |
By pure record count, Gyazo isn’t the single largest breach of the year. But when you add the 490 million image metadata records, few 2026 disclosures come close in total exposed data points, and almost none involve the same combination of persistent, years-old content (screenshots from 2019 and earlier) resurfacing all at once.
Why Screenshot and Cloud-Capture Tools Are an Overlooked Attack Surface
Security teams tend to focus threat modeling on obvious targets: identity providers, payment processors, code repositories. Screenshot and clipboard tools rarely make that list, despite sitting in the middle of workflows where people paste exactly the things they shouldn’t: credentials caught in error dialogs, internal dashboards, private messages, even ID photos captured for reference. Gyazo and similar screen-capture utilities function as an unofficial extension of a company’s data perimeter, and this breach is a reminder that most of them were never built with that threat model in mind.
The OCR angle compounds the problem. Once a service starts indexing the text inside uploaded images to make them searchable, it’s effectively building a second, less-visible copy of whatever sensitive text users pasted into their screenshots. That index becomes a high-value target in its own right, separate from the images themselves, and it’s not the kind of data most users think to ask a screenshot tool whether it retains.
Japan’s Regulatory Response and the Global Compliance Angle
Helpfeel’s confirmed notification to Japan’s Personal Information Protection Commission puts the company under Japan’s Act on the Protection of Personal Information, which requires prompt reporting of breaches involving sensitive personal data. As of publication, there’s no public record of enforcement action, fines, or formal findings tied to this incident, and MLex reported the investigation is still ongoing on Helpfeel’s end as well.
What’s less clear is the international angle. Gyazo has long had a substantial user base outside Japan, including in the U.S. and Europe, but available reporting doesn’t confirm specific notifications to EU data protection authorities under GDPR or to U.S. state attorneys general. If a meaningful share of the 23.62 million affected records belong to EU residents, GDPR’s 72-hour breach notification rule could eventually put additional disclosure obligations on Helpfeel, though nothing in current reporting confirms that process has started.
Market and Industry Impact
Helpfeel is a private company, so there’s no stock price to move on the news the way a breach at a publicly traded firm might trigger. But reputational damage in the developer and IT-tooling space compounds differently: Gyazo’s user base skews toward technically literate people, including engineers, QA teams, and IT support staff who embedded the tool into daily workflows precisely because it was frictionless. That’s also the audience most likely to notice a breach notice, question whether their screenshots contained anything sensitive, and migrate to a competing tool.
Competing screenshot and clipboard services, along with enterprise-focused alternatives that offer stricter access controls, are the most likely near-term beneficiaries. For IT security teams, the more immediate impact is procedural: this breach gives CISOs a concrete, citable example to justify auditing which third-party screenshot, clipboard, and file-sharing tools employees use informally, outside any approved software list.
Historical Context: A Pattern in Cloud Storage Breaches
The Gyazo breach fits a recognizable pattern that has repeated across cloud storage and file-sharing services for years: a convenience-first sharing model built on unguessable links, running for a long time without a major incident, until a single server-side vulnerability exposes the entire link index at once. The core lesson security researchers have drawn from this category of incident, repeatedly, is that “unguessable” is not the same as “access-controlled,” and that assumption tends to hold right up until it doesn’t.
What sets Gyazo apart from a typical file-sharing incident is the age of the exposed data. Roughly 490 million image metadata records tied to uploads from January 2019 or earlier means this breach didn’t just expose recent activity, it resurfaced nearly a decade of accumulated content that most users likely forgot existed. That’s a growing risk for any service that treats indefinite data retention as a default rather than a deliberate choice.
What Gyazo Users Should Do Right Now
Anyone with a Gyazo account should treat their account password as compromised, particularly if it was reused on any other service, since exposed data includes password hashes that can potentially be cracked offline. Changing the Gyazo password and any account that shares that password is the first step. Users should also check that they’re running the latest Gyazo browser extension â the Chrome Web Store listing shows version 5.17.0, last updated in July 2026 â since an outdated install is less likely to carry whatever client-side hardening Helpfeel pushes out in response to the breach. Users who linked Gyazo to X or signed in via Google SSO should review and, where possible, revoke those connections, then re-authorize only after confirming Helpfeel has rotated the underlying tokens.
Because image IDs were part of the exposure, anyone who has shared sensitive screenshots via Gyazo links over the years, particularly before 2019, should assume those links could theoretically be reconstructed from the leaked metadata and treat old “private” share links as no longer private. Deleting old uploads that contain sensitive material, where the platform allows it, is a reasonable precaution while Helpfeel’s investigation continues.
Predictions: Where the Gyazo Fallout Goes From Here
- Expect a broader scope revision. Helpfeel has described its investigation as ongoing, and breach figures in incidents of this size frequently get revised upward as forensic teams complete their review.
- More screenshot and clipboard tools will face scrutiny. Security researchers are likely to start auditing similar link-based sharing tools for the same class of vulnerability now that Gyazo has demonstrated the blast radius.
- International regulatory attention is plausible but not yet confirmed. Given Gyazo’s global footprint, EU or U.S. state-level inquiries are a realistic next step if a meaningful share of affected users turn out to be based outside Japan.
- Enterprise IT policies will tighten around unsanctioned screenshot tools. Expect more companies to formally restrict or vet third-party screen-capture and clipboard utilities following this incident, similar to past crackdowns after other SaaS breaches.
- Password-reuse fallout will outlast the headlines. Historically, breaches involving hashed passwords generate a secondary wave of account-takeover attempts weeks to months later as attackers crack and test credentials against unrelated services.
Frequently Asked Questions
What is the Gyazo data breach?
It’s a September 2026 security incident in which an attacker exploited a vulnerability in Gyazo’s image upload server, gaining access to a database that held roughly 23.62 million user records and about 490 million records of image metadata, according to Helpfeel’s official disclosure.
When did the Gyazo breach happen?
The intrusion occurred on September 11, 2026. Helpfeel says it cut off the attacker’s access the following day, September 12, and publicly disclosed the incident on September 16, 2026.
Was my password stolen in the Gyazo breach?
If you have a Gyazo account, your password hash was likely included in the exposed data, along with your email address and other account details. Helpfeel has not confirmed the passwords were stored in plaintext, but hashed passwords can still be vulnerable to offline cracking, especially if reused elsewhere.
Were payment details exposed in the Gyazo breach?
No. Helpfeel has stated explicitly that no payment card information or credit card numbers were part of the exposed data, though some billing information and usage statistics were included.
Are my Gyazo screenshots at risk after this breach?
Potentially. The breach exposed the image IDs that make up Gyazo’s share links, plus OCR-extracted text and, in some cases, EXIF location data from uploaded images. That combination means links assumed to be private could theoretically be reconstructed from the leaked metadata.
What should Gyazo users do now?
Change your Gyazo password and any account where you reused it, review and revoke linked X or Google SSO connections, and treat older shared links, especially those from before 2019, as no longer private.
Has Gyazo notified regulators about the breach?
Yes. Helpfeel has confirmed it reported the incident to Japan’s Personal Information Protection Commission. Current reporting does not confirm specific notifications to EU or U.S. regulators.
How does the Gyazo breach compare to other 2026 data breaches?
By user record count, it’s smaller than the roughly 153 million IDs exposed in the IDScan breach, but its combined total of user records plus image metadata (over 500 million data points) makes it one of the largest disclosed incidents of 2026 by total exposed records.
