The $387.5M Theft Came Through the Security Appliance — and the Vendor Still Hasn't Been Named

On September 24, 2026, the crypto exchange Bitget watched $387.5 million walk out of its hot and warm wallets. The first theft landed at 18:31 UTC; the last, a little over three hours later, across eleven blockchains. That's not the surprising part. The surprising part arrived a week later, on October 1, when Bitget told the world how it happened: the attackers broke in through a zero-day in a third-party security product — the very kind of gear companies buy to keep attackers out.

And here's the detail that should make every engineer sit up: nobody will say which product. No vendor name, no CVE, no patch advisory. A security product with a zero-day severe enough to enable the largest crypto theft of the year is still unidentified in public. If you run security appliances with privileged network access — and if you work in infrastructure, you do — you're reading about an attack path that could already exist in your stack, with no way to check.

The kill chain, from the teams that dug it up

Bitget brought in blockchain-security firm SlowMist on September 25 and had Google's Mandiant assisting too. Both investigation reports were released on September 30, and together they reconstruct a break-in that started weeks before the money moved:

August 31: the earliest malicious activity in the logs. A service on one of the security product's nodes — "Product A" in the reports — was hit by a zero-day. The attacker ran a hidden script inside the service process, read an environment variable containing the database password, and connected to the database. Similar hidden-script activity showed up on two more nodes on September 23 and 25. The service environments were compromised before a single coin left.
September 24: Mandiant found the attacker gained privileged access to two third-party security appliances (A and B), planted a web shell on appliance B with a command-and-control connection, then moved laterally onto Bitget's production wallet job server and dropped malicious packages there.
Early September 25: the attacker accessed Product B's management platform using an internal employee's identity, made three consecutive attempts to inject system commands into the platform's task parameters to write malicious files, then submitted code through its web execution endpoint — modifying server config, writing a communication relay file, and assembling malicious programs in batches.
01:49 a.m. September 25: a bespoke withdrawal tool, later recovered from files the attacker had deleted, began executing. SlowMist times the first theft transfer at 02:31 and the last at 05:23 — nearly three hours, multiple chains.

Bitget's response, once it noticed, was fast: discrepancy at 19:05 UTC, withdrawals blocked, full emergency by 19:14, signing services shut by 21:44. Root cause found the next morning at 08:43; law enforcement notified by 13:42. Cold wallets and private keys were never touched — but the last thefts still slipped out 43 minutes after the sweep began, from wallets the response hadn't reached yet.

The tool that spoke fluent wallet

The attackers never stole Bitget's private keys. Instead, SlowMist recovered a purpose-built withdrawal tool tailored to Bitget's own wallet logic: it spoofed risk-control parameters, generated withdrawal requests, and triggered the corresponding approval procedure. The signing system wasn't cracked — it was convinced.

That's a much uglier lesson than "patch your servers." CEO Gracy Chen said the attacker compromised a backend system in the wallet infrastructure, spoofed transaction data, and triggered the authorization process. When the system that builds the transaction is compromised and the system that signs it trusts the backend, a valid signature lands on a malicious payment. Your cryptography can be perfect and your money still leaves — because the theft happened inside a legitimate authorization flow, not around it.

If you run any service where one component prepares payments, orders, or API calls and another component approves them, audit the trust boundary between the two. That's where this $387.5 million went missing.

Where $387.5 million goes when it's stolen

The aftermath has been a live, public chase. Bitget (backed by Chainalysis, Elliptic, and TRM Labs' wallet-overlap findings) attributes the attack to North Korean threat actors. About $1.1 million was frozen by Circle, Tether, and NEAR Intents — a rounding error against the total. Bitget runs a public tracing dashboard and pays a 5% bounty for frozen or recovered funds.

Independent on-chain tracking has followed the money through the standard laundering playbook: ETH and XRP swapped into Bitcoin via bridges, then THORChain, CoinJoin mixing rounds, and Zcash's shielded pool. As of October 6, Bitget's own ledger counted $343.84 million held and $39.08 million untraced across 4,981 addresses — with 26 round Zcash parcels now labeled as HitBTC deposits and 2,619 ZEC routed through 95 NEAR Intents swaps into TRON USDT on October 5. On the bright side for customers: Bitget says user balances were unaffected, its Protection Fund covered the loss, and withdrawals were fully restored by October 2.

The vendor nobody will name

Here's the part that keeps nagging. Bitget says it notified "the relevant third-party vendor" and disabled the affected functionality. That's the entire public disclosure of the root-cause product: unnamed, unversioned, un-CVE'd. The investigation continues, and naming the vendor might complicate a criminal probe — a fair counter-argument.

But consider the other side. If a zero-day in a security appliance sold to exchanges and enterprises is severe enough to enable a $387.5 million theft, every other customer of that product is sitting exposed right now with no way to check, no advisory to apply, no CVE to feed into their vulnerability scanner. Coordinated disclosure exists precisely for this scenario. "We told the vendor" is not disclosure; it's a footnote.

There's a structural reason this keeps happening: security vendors sell trusted, privileged, deeply embedded products — and their own incident histories are rarely part of the procurement conversation. The product that watches your network often runs with the network's highest privileges. When it falls, it falls with the keys to the building.

What to actually do

Forget the crypto angle. This is a supply-chain story, and here's the mechanical checklist it earns:

Inventory your security appliances as tier-0 attack surface. Every third-party security agent, appliance, and management platform with privileged access goes on the same critical list as your domain controllers — because Mandiant's report shows that's exactly how attackers treat them.
Get database credentials out of environment variables. SlowMist's root-cause detail is almost boring: the attacker read a DB password from an env var. Secrets manager, short-lived credentials, rotation after any incident. This one is cheap to fix and expensive to skip.
Separate transaction-building from transaction-signing. If one compromised backend can persuade your signer to approve arbitrary destinations, your signature is decoration. Require an independent verification of the destination — an out-of-band approval, a second quorum, an allowlist the builder can't rewrite.
Ask your security vendors for their incident history — in writing. Patch SLAs, breach disclosure policy, whether their management plane has ever been abused. If a vendor can't answer, that answer tells you something too.

The cruelest irony of the Bitget hack isn't the dollar figure. It's that the company's security stack did exactly what security stacks do — sat at the most privileged point in the network — and became the front door. Trust, but audit the locks. Especially the ones you paid for.