Bitget’s $387.5M Theft: A Security Appliance, an Environment Variable, and a Forged Withdrawal

The most useful detail in the Bitget incident is not the amount. It is that, by the exchange's own account, the attackers did not need to break the wallet's cryptography. They needed a credential that was sitting where any process on the host could read it. Bitget says about $387.5 million left its hot and warm wallets in the early hours of 25 September. In its post-incident statement, the exchange says the intruders got in through a zero-day vulnerability in third-party security products, reached the production wallet job server, and read a database password from an environment variable.

Most of the technical detail is still unpublished. What is public is enough to turn into a checklist for any team that runs privileged infrastructure.

What Bitget and the investigators say

BleepingComputer reports Bitget's statement that the attackers breached its systems by exploiting a zero-day flaw in third-party security products, which Bitget refers to as Product A and Product B. The exchange engaged Mandiant and SlowMist to investigate. SlowMist's preliminary findings, as republished by TechFlow, trace the earliest malicious activity to 31 August, about 25 days before the theft. They describe a zero-day in a third-party security product node, internal accounts being accessed, and another security product's management platform being infiltrated.

Per the reporting on Bitget's statement, the attackers deployed web shells, moved laterally to a production wallet job server, read the environment variable containing a database password and used it to reach the database. They then installed a custom withdrawal tool. SlowMist describes customised tools that forged withdrawal parameters and triggered withdrawals; the first abnormal transfer was at 02:31 on 25 September, and transfers continued across several blockchains for roughly three hours.

Bitget says its User Protection Fund, reported at over $464 million, covers customer losses, and that withdrawals were suspended and then restored in stages, with Bitcoin first.

What is not established

The vendors. Neither Bitget, SlowMist nor Mandiant has named the two security products, and nothing we reviewed says whether patches exist. We do not link this to any other vulnerability in the news.
Whether private keys were taken. Some analysts, including Halborn, describe an attack that forged transactions through legitimate workflows without key access. SlowMist's own published findings do not state either way. Treat “no keys stolen” as reported by analysts, not confirmed by the investigators we could read.
Attribution. Bitget's CEO attributes the attack to North Korean hackers, citing IP behaviour and on-chain analysis. That is the exchange's claim; the public material does not include the evidence behind it.
Final loss and recovery. The figure is Bitget's, and the extent of recovery is not settled. Bitget has launched a recovery bounty programme, per the reporting.
The lateral path. How the attackers moved between the appliance, the management platform and the wallet server has not been published.

Three secrets lessons that do not depend on the missing details

1. An environment variable is readable by whatever runs on the host

Putting a password in an environment variable keeps it out of source control, which is the reason people do it. It does nothing against an attacker who already has code execution on that machine: the value is available to every process with the right privileges, and often to child processes, crash dumps and diagnostic tooling. If the account behind that password can reach customer-facing data or move money, a single foothold on one host becomes access to everything that password allows.

The remedies are well known and unglamorous. Give each service its own identity with the narrowest permissions it needs, fetch short-lived credentials at run time instead of storing long-lived ones, and make the database refuse connections from hosts and accounts that have no business using them. A stolen password should be useful for minutes and from one place.

2. Your security tooling is a high-value target, not a trusted bystander

The reported entry point was a security product, and the investigators describe a second product's management platform being reached. Security appliances sit in privileged network positions, often hold credentials for the systems they monitor, and are frequently exempt from the controls applied to ordinary servers. Treat them like domain controllers: restrict who can reach their management interfaces, keep their stored credentials narrow, log their administrative actions somewhere the appliance cannot edit, and put them on your emergency-patch list. This is the same pattern as the Citrix NetScaler flaws we covered this week, though we are not suggesting the two incidents are related.

3. Whoever can write the withdrawal can spend the money

Reports say the attackers wrote forged withdrawal commands that the wallet system accepted as ordinary payouts, bypassing risk checks. Whether or not keys were involved, the lesson is structural: a system that executes a transaction should not trust the same database and host that requested it. Require an approval that originates somewhere the compromised server cannot reach, such as a separate signing service that validates amount, destination and policy independently and alerts on anything outside a baseline. Rate limits and velocity alarms on the execution side could also limit a three-hour drain.

If you are responding to something like this

Assume the stolen credential works everywhere its account does. Inventory what the compromised service account and the database password could reach, not just what they were meant to reach.
Preserve evidence before you rotate. A dwell time of weeks means the first indicators are in old logs. Snapshot, then rotate.
Rotate in dependency order. Revoke sessions and tokens, replace the credentials the appliances and management platforms hold, then the application and database secrets, then anything that could authorise a payout.
Move to short-lived credentials while you are there. Replacing a long-lived password with another one resets the clock; it does not remove the risk.
Plan how new values reach people. Replacement credentials for database, wallet and appliance owners should not be pasted into the incident chat or ticket, which retains them and which the attacker may be reading.

Where Secretus fits, and where it does not

Secretus helps with the last step above: an authorised person handing another a small text secret, such as a rotated database password or a break-glass credential, over a link that is encrypted in the browser and stops working after the expiry you set or the first open. Team Split can require several holders to reconstruct a high-value text secret.

It is not a secrets manager, a signing service, an approval workflow or an exchange security product. It does not make an application fetch short-lived credentials, restrict a database to specific hosts, or stop forged withdrawals. Those controls belong in your infrastructure. Use a one-time channel for the human handover, and fix the environment variable, the appliance exposure and the approval path where they live.