2026-09-19
The Gyazo breach exposed EXIF location data from photos uploaded before 2019 — what scrubbing metadata before you upload actually prevents
On September 16, 2026, Helpfeel Inc., the company behind the screenshot- and image-sharing tool Gyazo, disclosed that an attacker had exploited a vulnerability in Gyazo's image upload server on September 11 to run arbitrary commands and reach its database. By the company's own count, about 23.62 million user account records and roughly 490 million image metadata records were exposed — the vast majority of them tied to images uploaded before January 2019. The Hacker News reported the same figures the day the notice went out. Helpfeel says it detected the intrusion that same evening, cut off the attacker's access within hours, confirmed unauthorized disclosure on September 14, and reported the incident to Japan's Personal Information Protection Commission on September 15 before publishing its notice on the 16th. The notice "sincerely apologize[d] to all Gyazo users and other affected parties for the significant concern" the breach caused, and said Helpfeel could not rule out that the attacker had actually viewed some private images — which is why it temporarily disabled image viewing for the affected set while it investigated.
What makes this breach worth a closer look here isn't its size. It's the age of the data. Most of the exposed metadata belonged to images people uploaded seven years or more before anyone broke in — long before this breach, long before most people were thinking about what a screenshot tool keeps on file next to the picture itself. That gap between "when I uploaded this" and "when it can leak" is the part a metadata scrubber run before upload is built to shrink to zero, and it's worth being precise about how, and about exactly where that stops mattering.
What Helpfeel actually says was in the exposed metadata
The official notice lists the compromised metadata fields directly: image ID, the uploader's source IP address, User-Agent string, EXIF location data, OCR text extracted from the image, the image's title, its source URL, and — for images marked private — a hashed passphrase. A separate pass by the attacker, using targeted filtering, reportedly reached metadata for about 2.4 million additional images beyond that general set. None of those fields is exotic; it's the same handful of things any image-hosting service tends to keep in a database row next to a file it stores — but "EXIF location data" specifically means the GPS coordinates a phone or camera wrote into a photo at the moment it was taken, sitting there for years after the original upload, waiting for a server-side breach to turn a whole database of it into something an outside party can read in bulk.
The part scrubbing before upload actually changes
NearScrub runs entirely in the browser, before a file ever leaves your device. If a JPEG or PNG's EXIF GPS tag, XMP block, and IPTC fields are already stripped at that point, there is no "EXIF location data" for a host like Gyazo to store next to the file in the first place — not because the host promised to protect it well, not because it deleted it later, but because it was never handed the data to keep. A breach can't expose a field that was empty on arrival. That's the entire mechanism, and it's also the limit of it: this only helps for uploads that happen after the metadata is already gone. It does nothing for a file already sitting on a server today with its original metadata intact — including, by Helpfeel's own account, millions of images uploaded years before this breach happened. There is no way to reach back in time and scrub a photo you already sent somewhere in 2018.
What it would not have prevented — and never claims to
It's worth being just as direct about the rest of what leaked, because most of it has nothing to do with a file's metadata at all. The user account fields Helpfeel listed — name, email address, password hash, device ID, session ID, linked X/Twitter and Google sign-in tokens, subscription and billing status — belong to Gyazo's own account system, not to any image file. A metadata scrubber never touches an account database; running files through NearScrub before upload changes nothing about what a host stores about the account that uploaded them, and it isn't a password manager or a substitute for changing a reused password. The OCR text Helpfeel says was also exposed is a second, separate case worth naming plainly: OCR reads the actual visible pixels of an image — a screenshot of an email thread, a chat log, an API key pasted into a terminal — and if that text is visible in the picture itself, no metadata tool removes it, because metadata tools don't edit pixels. NearScrub strips the invisible fields wrapped around an image; it was never built to redact what the image itself shows, and nothing about this breach changes that scope. And for any of the exposed images that were GIFs — a format Gyazo's own capture tool produces — NearScrub doesn't cover that format at all; its coverage is JPEG, PNG, PDF, and Office/ODF documents only.
The honest summary
The Gyazo breach is a server-side story: a vulnerability in someone else's upload infrastructure, an attacker who reached a database, and an account system that kept image metadata on file for years after the images themselves stopped mattering to anyone. NearScrub has no reach into any of that — it can't patch a host's server, can't get an account record deleted from a breach that already happened, and can't retroactively clean a file uploaded before it was ever run through a scrubber. What it changes sits upstream of all of that: for a photo scrubbed before it's uploaded anywhere, the EXIF location field Helpfeel had to list among what leaked simply doesn't exist to be stored in the first place — which means it can't still be sitting in that database seven years later when something eventually goes wrong.