# Gyazo.com has been hacked and almost half a billion records are in the wild now **URL:** \ **Category:** Privacy News\ **Tags:** gyazo\ **Created:** [September 23, 2026, 6:14pm UTC](https://community.redact.dev/t/gyazo-com-has-been-hacked-and-almost-half-a-billion-records-are-in-the-wild-now/510 "2026-09-23T18:14:17Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![sheesh](https://yyz1.discourse-cdn.com/flex027/user_avatar/community.redact.dev/sheesh/32/248_2.png) [@sheesh](https://community.redact.dev/u/sheesh)\ **Post date:** [September 23, 2026, 6:14pm UTC](https://community.redact.dev/t/gyazo-com-has-been-hacked-and-almost-half-a-billion-records-are-in-the-wild-now/510/1 "2026-09-23T18:14:17Z")
If you use Gyazo, you’ve probably noticed it’s been down for days. It got hacked on September 11 and it’s been fully offline since September 18, with no return date yet. I wrote up the full breakdown on our blog. > **[Gyazo Was Just Hacked, Pretty Badly. You May Want to Delete Your Images.](https://redact.dev/blog/gyazo-data-breach-2026)** > > Gyazo was hacked on Sept. 11, 2026. What leaked from 23.6 million user records and 490 million image records, and how to delete your Gyazo images. **What leaked** - **About 23.6 million account records** , with names, emails and password hashes (not the passwords themselves), plus your Google sign-in email or Twitter token if you linked either. No payment info. - **Records on about 490 million images** , mostly from January 2019 or earlier, so if you joined after that, most of yours probably aren’t in there. Each has the image ID its Gyazo link is built from, plus the upload IP, any GPS data and the text Gyazo’s OCR read off it. The attacker also got a list of which images are private. **What I’d do right now** 1. If you’ve used your Gyazo password anywhere else, change it there. Gyazo’s own has to wait until it’s back. 2. Unlink Gyazo in Twitter’s [connected apps](https://x.com/settings/connected_apps) if you ever linked the two. 3. Don’t click links in emails about the breach. Go to [gyazo.com](https://gyazo.com/) yourself. **Once it’s back, delete the old images** A new password won’t do anything about those leaked image links. Gyazo says it’s building a way for you to review your images and make them viewable again, and when it does, I’d delete the old ones instead. Redact clears them in one run right from your computer, either everything or just the years the leak covers. > **[Redact - Mass delete Gyazo images](https://redact.dev/services/gyazo)** > > Mass delete your image captures and collections on Gyazo.com The app might need a quick tweak if Gyazo changes things when it relaunches, so I’ll update this thread once it’s working. Anyone else have years of screenshots sitting on there? ---
**Author:** ![TimBuckToo420](https://yyz1.discourse-cdn.com/flex027/user_avatar/community.redact.dev/timbucktoo420/32/200_2.png) [@TimBuckToo420](https://community.redact.dev/u/TimBuckToo420)\ **Post date:** [September 23, 2026, 6:21pm UTC](https://community.redact.dev/t/gyazo-com-has-been-hacked-and-almost-half-a-billion-records-are-in-the-wild-now/510/2 "2026-09-23T18:21:27Z")
funny I was just reading a thread on reddit about this very topic [Reddit](https://www.reddit.com/r/cybersecurity/comments/1wk7pk0/gyazo_server_flaw_exploited_to_steal_236_million/) ---
**Author:** ![kittycat](https://yyz1.discourse-cdn.com/flex027/user_avatar/community.redact.dev/kittycat/32/137_2.png) [@kittycat](https://community.redact.dev/u/kittycat)\ **Post date:** [September 23, 2026, 10:07pm UTC](https://community.redact.dev/t/gyazo-com-has-been-hacked-and-almost-half-a-billion-records-are-in-the-wild-now/510/3 "2026-09-23T22:07:39Z")
Oh fantastic. I’ve been using gyazo since like 2015, can only imagine what kind of crap is about to be flaoting around the “dark web”. ---
**Author:** ![h4ck3r](https://avatars.discourse-cdn.com/v4/letter/h/5f9b8f/32.png) [@h4ck3r](https://community.redact.dev/u/h4ck3r)\ **Post date:** [September 23, 2026, 10:40pm UTC](https://community.redact.dev/t/gyazo-com-has-been-hacked-and-almost-half-a-billion-records-are-in-the-wild-now/510/4 "2026-09-23T22:40:17Z")
Ha, yeah, it’s been all over. I went down the rabbit hole on the technical side, so here’s the nerdy version. **How they got in** Helpfeel (the company behind Gyazo) [says](https://corp.helpfeel.com/en/news/news-20260916) someone exploited a bug in the image upload server, got arbitriry command execution, and made it from there into Gyazo’s database. No CVE, no bug class. Gyazo’s a Kyoto company, so the good discussion’s on the Japanese side, over on [Hatena Bookmark](https://b.hatena.ne.jp/entry/s/corp.helpfeel.com/news/news-20260916-1) (you have to use google translate), which is basically Japan’s Hacker News (your browser’s translate button handles it fine). Hiroshi Tokumaru, who wrote the web security book a lot of Japanese devs learned from, pointed out there that “arbitrary commands” means full RCE, which isn’t necessarily a plain command injection. That covers a lot of ground, anything from a poisoned image parser to a deserialization bug. Image upload pipelines have a rough history here (ImageTragick, or the ExifTool DjVu bug that got a pile of self-hosted GitLab servers popped in 2021), but nobody’s said it was one of those. What I’d really like to know is why a box that eats random files off the internet could reach the user database at all. **Why the image IDs are the real problem** Gyazo links are capability URLs. That 32-character hex ID works out to 2^128 possible addresses, which is why [Gyazo’s help page](https://help.gyazo.com/Is%20Gyazo%20safe%3F-5de75e1e040e1d0017df4359) says they can’t be guessed. Nobody has to guess when the real IDs are sitting in the dump. You also can’t rotate a URL without breaking every embed that points at it, so they pulled image viewing, and the plan is to have you review your images before anything’s viewable again. **Other stuff in the notice worth knowing** - The 490M image records are only about 14.4% of Gyazo’s image data, mostly January 2019 or older. Could be a dump that ran oldest-first and got cut off, could be a legacy table. They haven’t said. - There’s a separate pull of about 2.4M image records “retrieved using specific filtering criteria.” That’s someone running targeted queries, and nobody’s said what they filtered on. - The metadata includes the OCR text Gyazo pulled off the images, so anything readable in the leaked screenshots is now searchabl e text. Long-term AWS keys all start with AKIA, so stuff like that is easy to fish out. If you ever captured a terminal or a .env file, rotate whatever was in it, even if it’s from 2017. - Password-locked captures (a Pro and Teams feature) leaked their passphrase hashes, plus the list of which images are private. Helpfeel hasn’t said what hashing it used for those or for account passwords. - The 23.62M user count is rows, not people. It includes anonymous accounts that never had an email on them. **Devs are feeling it too** Gyazoa image links are all 404ing right now and the upload API’s returning 502s. This PR’s a fun one. A docs site’s CI kept timing out because every build retried all ~916 of its Gyazo lookups, and every one came back 502. The fix is a neat little negative cache. > > > \## Problem > > CI started failing on every branch with: > > \`\`\` > Error: Timed out waiti…ng 120000ms from config.webServer. > \`\`\` > > The Gyazo oembed API is currently returning \*\*502\*\* for every lookup. > > \`refreshGyazoMetadata()\` runs on \`beforeBuild\` for every build and looks up each of the site's ~916 Gyazo URLs, sleeping 200ms after each request. It only wrote the cache on success, so while the API is down nothing is ever cached and \*\*every build retries all 916 URLs\*\*. > > Measured on this branch's parent, with a cold \`.cache\`: > > \- eleventy build: \*\*7m12s\*\*, \`916 lookups failed\` > \- Playwright's \`webServer\` (\`npm run dev:test\`) has a 120s timeout, so it never came up > > \`.cache/\` is gitignored, so CI always starts cold. \`main\` last passed at 2026-09-18 02:46Z, before the API went down. > > \## Change > > Failed lookups are stored as \`{ failedAt }\` and skipped for 24 hours: > > \- a cold build pays one attempt per URL, exactly as before > \- every later build is fast, outage or not > \- once Gyazo recovers, the next build after the retry window picks the dimensions back up on its own > > The warning now reports how many lookups failed, which is what distinguishes an outage from URLs that simply have no metadata. > > While the API is down those images still fall back to a 16:9 aspect ratio. That is the existing behavior for missing dimensions and is not changed here. > > \## Checks > > \- cold build \*\*7m12s\*\* → warm build \*\*3.6s\*\* > \- \`npm run check\` passes (380 workflows, 42 production media entries) > \- \`npm run build\` and \`npm run check:build\` pass (942 files) > \- \`npm run test:playwright\` — \*\*48 passed\*\* > > \## Follow-up > > The CI job still pays the cold cost once per run, since \`.cache/\` is not restored between runs. Caching \`.cache/gyazo-images.json\` in the workflow would remove that too, but it is a separate change and not needed to get CI green. > > > > > \## Summary by CodeRabbit > > \- \*\*Bug Fixes\*\* > - Failed Gyazo metadata lookups are now recorded with timestamps and temporarily skipped for 24 hours. > - Failed lookups are retried automatically after the cooldown period. > - Existing successful metadata continues to be cached. > - Warnings now include counts for failed lookups and missing image dimensions. If you’ve got Gyazo images in READMEs or docs, it’s a decent week to move them somewhere you control. ---
**Author:** ![Hollywood](https://yyz1.discourse-cdn.com/flex027/user_avatar/community.redact.dev/hollywood/32/204_2.png) [@Hollywood](https://community.redact.dev/u/Hollywood)\ **Post date:** [September 24, 2026, 4:32pm UTC](https://community.redact.dev/t/gyazo-com-has-been-hacked-and-almost-half-a-billion-records-are-in-the-wild-now/510/5 "2026-09-24T16:32:20Z")
thats crazy! and their site is still down. when will it be back up? it’s going to be a race against the hackers to delete your images before thew hackers can load the URLs