If you upload a screenshot with a password to Gyazo, what hashes, sessions, and image text still keep

An operator mints a database password, grabs the terminal, and the Gyazo client posts a gyazo.com/… link into chat. The other person opens it faster than a file drop. You delete your side of the thread and treat the job as closed: the picture went out, and your window no longer holds the URL. Between 11 and 16 September 2026, Helpfeel filled in the rest of that path. The image-host account, and the metadata sitting next to every capture, do not empty when the chat window does.

A previous piece covered who can still see a password — and the key after # — in a screenshot or screen share: that is the PNG on the Desktop, the Screenshots album, and the meeting recording. This one changes the question. After the capture has already gone to Gyazo, which official fields still hold the account password hash, the login session, the Image ID, and the OCR text pulled from the picture. If a key has to move, use a one-time link in the shape s.html?id=…#…. Create and read both work without an account. MyPassGen’s tools open without sign-up. The rest of this page does not explain how to exploit any host. It lines up the fields already written in Helpfeel’s 16 September 2026 English notice and the same-day Japanese notice, plus the library you can open in your own account.

An upload is more than a picture

Gyazo is a cloud host for screenshots, GIFs, and short recordings: the client captures the screen, uploads it, and returns a shareable link. Helpfeel’s notice defines “images” as everything captured and stored through Gyazo, including screenshots, GIFs, and video. A free account on the website often lists only the most recent captures. Older files are not deleted just because they dropped off that list. Whoever still has the full URL can open them. The Hacker News restated the help pages: at the default setting, the link itself is the protection. A URL that is “long enough that it can’t be guessed” is not the same as a URL that still protects you after the identifier has already left the database.

That is a different path from “did this website upload the password I am generating.” On MyPassGen’s generator page you can check Network and see that the plaintext is not sent as business data. The PNG you choose to upload rides Gyazo’s own API. The host stores more than pixels. On the account side: email, a password hash, a login session. Next to each picture: an Image ID, the upload IP, a User-Agent, EXIF location if the file had it, and OCR text extracted from the image. Deleting the chat row does not delete that database row.

The clipboard piece covered a leftover after Copy: the password left the generator field and entered the system clipboard. A screenshot leaves the screen and enters a local file. An upload then leaves this machine and enters someone else’s server. None of those three leftovers ends because “I already sent it” or “I already changed the password.” Dropping an unredacted ticket screenshot onto an image host is the same class of problem as writing the password into an email body: the other side is looking at a copy you handed over. That path is in if you put a temporary password in an email, what Sent, forwards, and phone previews still keep.

The numbers in Helpfeel’s 16 September notice

Unless noted otherwise, the times are Japan Standard Time. On 11 September 2026 a third party used a vulnerability on Gyazo’s image-upload server to run arbitrary commands. That evening Helpfeel saw the activity and started responding. In the early hours of 12 September it blocked the routes it had identified and cut the unauthorised connections; the same day it finished remediating the vulnerability. On 14 September the investigation confirmed that information had been disclosed without authorisation, and the company took precautionary steps that included suspending image delivery. On 15 September it resumed delivery of images newly uploaded after those measures, and filed a report with Japan’s Personal Information Protection Commission. On 16 September it published the notice.

On the user-information side, about 23.62 million records were confirmed as disclosed without authorisation. Fields vary by person. The published list includes: a name or nickname, email address, password hash, user ID, device ID, login session ID, an X (formerly Twitter) integration token if connected, a Google SSO email if connected, profile text, language, registration time, last login time, subscription plan, billing status (not credit-card numbers or other payment-method details), and usage statistics. The 23.62 million includes anonymous accounts with no registered email. Helpfeel is still counting how many natural persons had personal data disclosed. It wrote that payment information, including card numbers, was not disclosed without authorisation.

On the image-metadata side, about 490 million records were confirmed as disclosed, mainly for images registered in or before January 2019 — about 14.4% of all image-related data. Metadata for about 2.4 million further images was pulled with “specific filtering criteria” and disclosed as well. Helpfeel did not say whether those two sets overlap, or whether the second set includes newer captures. The metadata fields include: the Image ID used to construct the image URL, the source IP at upload, User-Agent, EXIF location if the image contained it, OCR text extracted from the image, the image title, source URL and other metadata, a hashed passphrase for private images, and related information. The investigation so far has not confirmed loss of the image files themselves. Helpfeel and Cosense have different architectures from Gyazo; the company has not confirmed disclosure from those two systems because of this incident. Gyazo captures embedded in them may still fail to load while delivery stays paused.

Password hashes, session IDs, and third-party tokens

A password hash is not the line you type in the login box. It is the stored form the server uses to check whether the next attempt is the same string. A leaked hash is not the same as someone reading the plaintext immediately. It is also not the same as “they can never read it.” That is why Helpfeel asked every Gyazo user to change the password, and to change it on any other service that still uses the same or a similar string. “I only used a throwaway password on the image host” is a different sentence from “I reused it.” If you reused it, the host’s hash is material for other login boxes. A local check against a public weak-password list can only prove a hit on that list. It cannot prove the string never entered some other dump. That difference is in local leaked-password lists vs Have I Been Pwned: what each check proves.

The login session ID is a second layer. A site does not ask for the password on every click. After a successful login it leaves a session that proves “already this person.” If that session ID sat in the accessed database, the other party may hold a still-valid card rather than another trip through the login box. Helpfeel wrote that it invalidated and restricted authentication-related information. It did not write that every session ID is already dead, or that a fresh-IP code is enough to block replay. The previous leftover piece on AI sessions used Okta’s name for an unexpired token: a skeleton key. Changing the password does not kill a session that is still alive, as in after you change the password and MFA, who can still walk into the AI session in your browser. On the Gyazo side, trust whether an old device is still signed in after the notice, and whether you actually changed the password. Do not substitute the headline “they wrote invalidated.”

X integration tokens and a Google SSO email are a third layer. The token speaks to a connected account in your name. The email binds the image-host identity to a Google login. Helpfeel also asked users to watch for suspicious mail and messages tied to this incident. A phishing letter will use a real email, a real nickname, and the true fact that you used Gyazo. Revoking third-party connections, changing the password, and checking the session are three separate jobs. Doing the one you remember leaves the other two in someone else’s hands.

Image IDs and the “can’t be guessed” link

The notice calls the Image ID “information used to construct the image URL,” and it says a third party could use that information to access and view the matching pictures without authorisation. Helpfeel temporarily disabled viewing of some images. It did not say which captures were paused, or how a user can tell whether their own files sit in the affected set. A free account on the website often shows only the latest captures. An older file does not vanish from the server because it dropped off that list. Whoever can rebuild the URL can still open it.

Gyazo’s “Is Gyazo safe?” help page writes that a long string of characters “can’t be guessed,” and it cites 2¹²⁸ possible addresses. That claim depends on the ID itself not leaving the host in bulk. About 490 million metadata rows carried Image IDs. That pulls part of the “can’t be guessed” premise away — mainly the January 2019-and-earlier batch, plus about 2.4 million captures pulled under a filter. A terminal screenshot you uploaded in 2018 with an internal address or a test password may have left chat years ago. The ID in metadata can still let someone rebuild the same picture.

The notice also confirmed that the third party obtained a list identifying private images. Helpfeel wrote that it cannot rule out that some private images were viewed, and that the investigation continues. Paid “only me” or passphrase-lock settings face a stranger who does not have the link or the passphrase. They do not face someone who already entered the database and holds the private list. The help-page line “only you can see this” is no longer a claim you can check on the spot against that person. Private-image passphrases also appear in the metadata list as hashes — the same class of leftover as the account password hash. Treat them as extra offline material, not as “it is hashed, so it is safe.”

OCR text: pixels became a searchable string

The notice lists “OCR text extracted from the image” among the disclosed metadata. Gyazo’s OCR scan help page describes a paid feature you turn on yourself. Once enabled, it scans the account’s images. The same page says “Only you can see OCR results.” Text that can be searched is text that can be exported and parked in a database field. Terminal output, a browser address bar, and the visible result list on a password manager are the same class of pixels to OCR. A previous piece already noted: MyPassGen prints the generated string as visible text, not as dots. After a one-time link is created, the full s.html?id=…#… string is shown on the page. Network can prove the request line never carried the slice after #. It cannot prove the image host’s OCR field is empty.

That is one layer beyond “who opened the Gyazo link.” A person who opens the link sees pixels. A person who has the metadata can search for the string after password= without opening every picture. EXIF location is another row: a phone screenshot or a camera photo that still carries coordinates can leave a place next to the upload. Source IP and User-Agent write “who, on which machine” into the same record. The fields you redact before sending a ticket are not only the phone number in the chat body. They include the password and the key still sitting in the screenshot. That list is in which fields to redact before sending tickets and chat logs.

Uploading a screenshot that still shows a complete one-time URL hands over both the pixels and, if OCR ran, the whole address as text. Putting the key after # keeps it off the HTTP request line. It does not keep it off a person who can see the picture or run OCR. When someone must see the error, crop to the error. Leave the result list and the address bar out of the frame. Send the key on a one-time link. Do not bundle it with the screenshot on the same host URL.

Side by side: this machine and the image host

The same test password that just appeared on screen splits into at least four “who can still read it” paths. The difference is not an algorithm name. It is where the pixels and the account fields were copied.

Do not mix the fifth row with the first four. Writing a full s.html?id=…#… into a screenshot and uploading it still leaves one credential for OCR and for anyone who can see the picture. The host that parks ciphertext cannot see the key. Split the id and the key and a full-text search cannot find a link that opens. Treat a complete link as the password itself. Encrypting a file on this machine before a cloud upload is a file job. It is not “replace a plaintext screenshot with a ciphertext screenshot.” Once the pixels are taken, the image host stores a picture.

Check on the spot

The steps below do not depend on any vendor promise. Use a test password and a test screenshot that will never sign in to real work — for example a terminal line that says orange-lake-7, then crop that rectangle. Do not practise with a live master password, a production API key, or a live one-time URL.

1. Open the Gyazo website or client library and walk it from old to new. A free account may list only the latest captures. Retry any old link you still have: if it opens, “not on the list” is not the same as “gone from the server.” Mark pictures that show a test password, an address bar, or a #. Delete what you can delete. Stop sharing what you can stop.
2. If you ever turned on OCR or in-image search: search for the words in that test password. A hit means the text already sits in a searchable field, not only in pixels. Helpfeel listed OCR text among the disclosed metadata. What you can search, someone with the metadata can search as a string.
3. Change the Gyazo password. If that string, or a close variant, still unlocks mail, a drive, or a code host, change those too and mint a new random password. MyPassGen’s password generator uses a random mode of 6–128 characters, default 16, and warns below 8. It opens without an account. The result is not uploaded as business data. Do not skip this step because “the image host did not matter, so reuse was fine.”
4. Look at third-party connections in the account: X, Google SSO. Revoke what you can revoke. After the password change, sign in again from a second browser or an Incognito window and see whether the old window stays signed in. Helpfeel wrote that it invalidated and restricted authentication information. Trust the session you refresh now. Do not substitute a news headline for that look.
5. Search this machine for the same test screenshot: Desktop, Pictures, Pictures\Screenshots, Downloads, any synced-drive folder. Deleting it on the host often leaves a copy here and another in the drive. Handling is in before you drop a file in the cloud, who can read the plaintext — and which path the passphrase should take, and in the screenshot leftover piece.
6. Create a MyPassGen one-time link with the same test sentence, expiry 24 hours, reads left at 1. In chat or a ticket, paste only the part before the hash, s.html?id=…. Speak the key on a call or in person. Opens without an account. With only the id, the recipient should see an incomplete link; both halves are required to decrypt. After reading, overwrite the clipboard. Do not store an address that still has # in a browser profile that syncs, and do not upload a full-screen capture of the result page to any image host.

On a company account, add half a step: ask which image host screenshots go to by default, whether auto-upload can be turned off, and whether history can be deleted in bulk. MyPassGen will not tell you whether a given host stored another copy. Trust the windows you just opened.

If you have to hand off a key, split it

For a one-to-one handoff the other person can open now, do not write the password into a screenshot that will enter an image host, a chat archive, and an OCR field. Generate it on this device, then wrap it in a one-time link. On create, the browser encrypts with AES-256-GCM. A single note caps at 32 KB. Reads default to 1 and cap at 10. Expiry can be 1 hour, 24 hours, 7 days, or count-only with no TTL. The server parks ciphertext only. The key sits after # in the URL, so access logs and Referer do not see that slice. The screen and an image-host OCR field can still see it. Do not photograph the result page.

When a repo or a ticket still needs an entry point, split the channel. The file carries only the owner, the id, and the sentence “key by phone.” A call, an in-person handoff, or a different messenger account carries only the slice after #. Neither half decrypts alone. That is a usage pattern, not a product default. The create page still emits one full link, which is convenient for a one-to-one send. On a channel that draws preview cards, run a test link first and see whether the preview counts a read, as in if you paste a one-time link into Slack or WeChat, does the preview burn it first. Redact the error screenshot in Clean URL / redaction before you decide whether it still needs an upload.

A key pack or export larger than 32 KB does not belong on a one-time text link. Use the file encryption box: streaming AES-256-GCM in the browser, one file up to 5 GB, output .lock / .enc, passphrase sent separately. Encrypt on this device first, then sync; the other side should see ciphertext only. Pushing an unredacted terminal screenshot into Gyazo is the same class of problem as pushing an unencrypted .env into a drive: the copy that proves “this is me” or “this is the key” left the window you thought you had already cleared.

After you have checked “does the old link still open,” “can OCR still find the test password,” and “does changing only the password empty the library,” you can answer this article’s question: the Gyazo link is gone from chat, and the account hash, the session ID, the Image ID, and the image text can still sit in fields the notice already named. Helpfeel invalidated the authentication material it could invalidate. The text and IDs in 490 million metadata rows do not empty because you changed a password once. The library and reused passwords are a place to check. They are a poor place to assume “I already deleted the chat, so this is over.”

FAQ

I changed the Gyazo password. Are the old screenshots gone too?

Those are different jobs. A password change affects the next login box, and the authentication material the company already invalidated. Image IDs, OCR text, and the old picture files are not inside that click. Trust whether an old link still opens, and whether a library search still hits.

If only the hash leaked, does that mean someone already has my plaintext password?

It does not mean they can read the original string immediately. It also does not mean you can keep reusing it. Helpfeel asked every user to change the password, and to change it anywhere the same or a similar string is still in use. Change it first, then decide whether this machine should sign into the image host again. Do not skip the change because “it was only a hash.”

The capture was private, or locked with a passphrase. Can I treat it as never uploaded?

No. The notice confirmed that the third party obtained a list of private images, and it cannot rule out that some private pictures were viewed. The private passphrase itself also appears in the metadata list as a hash. Private settings block a stranger. They do not block someone who already entered the database.

Do create and read need an account? If I send the wrong channel, can support recover it?

No sign-up. Create and read are public to a visitor. After ciphertext burns by count or expiry, there is no server-side plaintext backup and no support inbox that can recover it. Generate a new password and a new link. Do not keep refreshing the same URL to see if it comes back, and do not screenshot the result page onto an image host to resend it.