After a cloud env-var leak, why the new key should not go back into chat

In late August 2026, the cloud deployment platform Zeabur published an incident titled “Unauthorized Access to Project Environment Variable Data.” The official status page says the attacker used a leaked internal AWS administrative credential, reached the primary database, and ran targeted queries and exports against project Variables. The stated target was AI-service API keys and other credentials that can be used immediately.

The same page lists exposed key names, including OPENAI_API_KEY, ANTHROPIC_API_KEY, OPENROUTER_API_KEY, DATABASE_URL, AWS_ACCESS_KEY_ID, plus common JWT, Stripe, and GitHub shapes. Custom variable names were counted as exposed when the value matched those credential formats. Zeabur told affected users to revoke and replace the listed credentials and to review third-party usage and charges. A circulating “full dataset for sale” screenshot is treated as unverified: the status page says the evidence they hold does not support that claim, and this article does not treat it as a confirmed fact.

Incidents like this have a fixed first-aid list: revoke the old key, check usage, rotate to a new one. Round one already happened on the host. You cannot pull a string back out of someone else’s hands. The step teams skip is round two: after the vendor console prints a new key, someone still has to give it to a teammate, paste it onto another machine, or drop it into a temporary ticket. If that hop is a chat window, the “just-rotated plaintext” is written into a record that can be searched, synced, and exported by an admin.

The platform name is only here to pin a date and a public record. The conclusion holds for any “rotate, then hand off” job: database passwords, CI tokens, a temporary SSH password. The danger is not that the teammate can see the secret. The danger is that every hop can keep a complete plaintext copy. This article does not rebuild a host’s hardening plan, and it does not sell UsePwd as a vault that could have stopped the host-side read.

Paste a string that starts with sk- into a channel and several copies appear at once. The message body enters workspace history. Desktop and phone clients each keep a cache. Many products also send the text into a server-side search index so someone can type “openai” three months later and pull it back. Admin exports, legal holds, and the “pack the chat archive” step during offboarding take that plaintext with them. Deleting one bubble usually does not delete the other person’s already-read push notification, a downloaded client library, or the frame a screenshot tool already saved.

That is a different problem from “I trust my teammate.” The teammate needs the new key so the service can start again. The channel, by default, stores a retrievable work record, not a secret that should exist only while it is being read. Writing “new key below” in a channel is also a notice to everyone who can search that channel later: people invited next quarter, anyone with audit-export rights, and whoever can reach a backup in the future. Secret-scanning writeups treat this as a known sprawl path; GitGuardian’s API-key guidance puts it plainly: do not share secrets unencrypted in messaging systems such as Slack.

Spread a typical emergency runbook on the table and the danger is not “log into the vendor console and mint a new key.” It is the steps around that click. Someone screenshots the old key and asks a teammate “is this the one.” Someone captures the whole console page, so the address bar, other project names, and a billing figure land in Photos together. Someone mints the new key, the teammate is away from the desk, and the channel gets “use this for now.” All three turn plaintext into an object that will be kept.

Shared drives and git are easier to miss. A raw .env dropped into a team folder, or a sample commit that still contains a key, is another copy. Cloud sync writes that file onto every signed-in device. Changing the file later does not erase the string from older git commits. A local backup of a single file up to 5 GB should be turned into ciphertext in the current tab before it is stored, instead of uploading a plaintext .env as an ordinary document. UsePwd File Encryption Box does streaming local encryption with AES-256-GCM and writes .lock / .enc. The file is not uploaded by default. That is “keep a ciphertext file yourself,” not “stuff the key into chat.”

A chat window hands over plaintext. Copying is easy on both sides. The cost is that the workspace, the search index, and the backups each hold a copy. Email attachments work the same way: once a .env or a notepad file is attached, the mail server and both clients have the full file.

A one-time encrypted link hands over “a ciphertext id plus decrypt material that stays on the device.” UsePwd Burn-Link encrypts the text in the current tab with Web Crypto and AES-256-GCM, then sends only ciphertext to the server. The decryption key is appended after # in s.html?id={id}#{key}. Create and read both work immediately — neither side registers. The server stores ciphertext, a TTL in hours, and a read count. It does not see plaintext, and there is no account system that can “recover it by user.”

Putting the key after # addresses host access logs and the HTTP request line: the browser does not send the fragment as part of the request. That layer is unpacked in Why URL hash fragments never reach the server. This article covers the next layer. Even if the key never enters a UsePwd request line, pasting the full link into chat still stores the whole address in that chat product. Anyone who has the complete URL can open the read page and decrypt until the read count is used up. Burn-Link limits how long ciphertext lives on the server, and how many times it can be read. It does not stop the recipient from taking a screenshot or forwarding the link.

If the secret must be kept for a long time, synced across devices, or recovered later, do not use Burn-Link, and do not treat chat history as a safe. That is a password manager’s job. UsePwd does not provide accounts or a vault. After the read count is used up, or if the link is lost, it cannot restore the secret for you.

If the secret is a high-value master key, a root certificate, or a wallet seed that can move funds, neither a link nor a chat channel is enough. Say it in person, use offline media, or stay inside an end-to-end channel you already established. A fragment scheme does not stop a machine that is already owned, a browser extension that can read the current page, or a full URL projected onto a conference-room wall.

File backup is a different path: turn a plaintext .env into .lock / .enc on this machine, then put the ciphertext on a drive. Hand the unlock passphrase on a channel that is not the file itself. Do not collapse the two tools into one promise. Burn-Link governs how many times a short secret can be read. File Encryption Box governs a ciphertext file you keep.

Back to the question. After cloud environment variables are stolen, the old keys have to be revoked. There is no shortcut. The new key should not go back into a chat window because chat, by default, stores searchable plaintext, and the point of rotation is to make the old string die immediately — you should not spend the same minute making a copy that will live longer. When a teammate needs it once, use Burn-Link: local encryption, open immediately. When you need a backup you keep yourself, use File Encryption Box. Both pages, like this article, have only a language switch on the right of the top bar. There is no sign-in.