A flaw in Gyazo's upload server exposed about 23.62 million user records and roughly 490 million image metadata records, including the identifiers needed to open the images themselves. Suspending delivery was the only control left.
On 11 September a third party exploited a vulnerability in the image upload server behind Gyazo, the screenshot sharing service, and used it to execute arbitrary commands on the host. Helpfeel Inc., which operates Gyazo, published a notice on 16 September putting the exposure at approximately 23.62 million user records and approximately 490 million image metadata records, with a further 2.4 million images retrieved through filtering. BleepingComputer reports Gyazo's own published figures at 23 million users and 3.1 billion submitted media items.
Helpfeel says suspicious activity was detected on the evening of 11 September, and that by the early hours of 12 September it had blocked the identified access routes and terminated the unauthorised connections. The vulnerability was remediated on 14 September, the same day image delivery was suspended. A report went to Japan's Personal Information Protection Commission on 15 September, and the public notice followed on 16 September. No payment information, including credit card numbers, was disclosed.
The user records cover names, email addresses, password hashes, user and device IDs, login session IDs, third-party integration tokens for X and Google SSO, profile and language settings, registration and login dates, subscription plans, billing status and usage statistics. Session IDs and integration tokens are the part worth acting on quickly, since they authenticate without a password.
Gyazo works by handing you a URL. You take a screenshot, the client uploads it, and you paste a link. The image metadata the attacker took includes image IDs and source URLs, and Helpfeel is explicit about what that means: the metadata "could be used by a third party to access and view the corresponding images without authorization."
That is a statement about the design rather than about the bug. In this model the secret protecting a shared image is the unguessable identifier inside its URL. Anyone holding the identifier is authorised by definition, because holding it is the entire check. Once an index of identifiers leaves the building there is no second factor to fall back on, which is why image delivery was paused service-wide. Turning the door off was the only remaining way to lock it.
Private images had a passphrase, and the notice says the stored passphrases were hashed. It also says the attacker obtained a list identifying which images were private, and that Helpfeel "cannot rule out the possibility that some private images may have been viewed by the third party." A hash slows an attacker down; a list of exactly which files are worth the effort speeds one up.
The metadata records also carry EXIF location data, image titles, upload IP addresses, user agents and OCR text. That last field deserves attention. Gyazo runs optical character recognition so images become searchable, which means the words inside each screenshot are stored as plain text alongside it. For a screenshot service the words inside the image are frequently the sensitive part: an invoice, a private message thread, an internal dashboard, a recovery code. Someone reading the metadata dump gets that text without needing the image file at all.
This is the standing cost of server-side features. Search, previews and thumbnails all require the provider to parse your content, and anything it parses becomes a second copy in another format, with its own attack surface.
Gyazo almost certainly encrypts stored objects at rest, and it would have made no difference here. Arbitrary code execution on the upload server placed the attacker inside the boundary where the provider's own keys are applied, so the storage layer decrypted on request exactly as designed. The pattern matches the McKesson intrusion we looked at earlier this month, where attackers used valid sessions instead of attacking cryptography. Encryption under provider-held keys defends against someone stealing the disks. It does nothing against someone standing where the keys are applied.
The alternative is to make the file unreadable to the server that holds it. If the key is generated on the sender's device and never transmitted, the server stores an opaque blob and an identifier that maps to it. An attacker with full read access to the database and the object store gets ciphertext and identifiers, and those identifiers open nothing, because the key was never part of any request the server saw. There is no OCR text to leak, because the server could never read the words.
Two honest caveats. A design like this still exposes some metadata: object sizes, upload times, request counts. And it gives up the features that need plaintext, so there is no server-side search and no thumbnail grid. For files whose exposure actually costs you something, that trade is usually worth making.
An identifier that grants access is a key, and the server keeps a copy of every one it issues.
SpaceBox Lite encrypts each file on the sender's device before it leaves, using post-quantum ML-KEM-768 (NIST FIPS 203) key exchange with AES-256-GCM. Keys stay on the device, our servers hold ciphertext only, and a sender needs no account and gives us no personal data. Post-quantum key exchange is not unique to us; the part that matters for a breach of this shape is where the keys sit, and ours sit somewhere we cannot reach. See Why SpaceBox for how that compares with mainstream cloud storage.
The free tier covers 1 MB, one sender and three files. A free voucher at beta.i46.space adds 100 MB and 100 files, and requires an email address. During the beta, SpaceBox Lite is not available to residents of the EU or EEA.
Helpfeel has handled this disclosure carefully, with a clear timeline and a regulator notified inside four days. Disclosure still cannot undo the exposure, because the files were readable by the server for their whole life. Choosing a design where they are not is a decision taken long before anything goes wrong.