- Bitget and its investigators say attackers used a zero-day flaw in third-party security products to reach the exchange's wallet system and move $387.5 million.
- Security tools hold credentials and reach into production, so their access belongs in the same risk count as any other system.
- Ask your team which security tools can reach production, where their secrets are stored, and who approves large payments.
The guard had the keys
A security product earns its place by being trusted. It sees traffic, holds credentials and can run commands on the systems it protects. That is also what makes it worth attacking.
The Bitget case shows the trade-off. The argument here is that a defensive tool's access should be counted as part of your attack surface. Many inventories may list the tools without recording what each one can reach.
What Bitget and its investigators say happened
The exchange disclosed the theft on September 24, 2026. Attackers had pulled $387.5 million out of the wallets it keeps online for everyday payouts, known as hot and warm wallets. Bitget paused withdrawals for a time.
In a later post on X, Bitget said its investigators had linked the attack to a previously unknown flaw in security products from an outside vendor. That kind of flaw is called a zero-day. Bitget cited findings from the blockchain security firm SlowMist.
Bitget said the flaw yielded high-level internal credentials. The attackers used them to send fraudulent withdrawal commands to the wallet system. Bitget has told the vendor and switched off the affected functionality until a fix is ready.
How the intrusion worked
SlowMist's report describes two unnamed security products, labelled A and B. The reports do not name the vendor and give no CVE ID for the flaw.
SlowMist ties the zero-day to a service running on one of Product A's nodes. It says the attacker ran a hidden script under that service process and read the database password from an environment variable. An environment variable is a setting held in the running system. The attacker then connected to the database.
On Product B, SlowMist says the attacker signed in to the management platform using an internal employee's identity. Three attempts followed to inject system commands into task settings. The attacker then used the platform's web execution endpoint to try to change server configuration and build malicious files.
Mandiant, which also investigated, reports that the attacker placed a web shell on appliance B. A web shell is a hidden control panel on a server. The attacker also opened a link to a remote control server. From that foothold, Mandiant says, the attacker reached the server that runs Bitget's wallet jobs and installed malicious packages.
SlowMist also recovered a custom tool from deleted files. It was built around the wallet system's withdrawal logic.
Linked activity starts about three and a half weeks earlier
SlowMist dates the earliest linked malicious activity to August 31, 2026. It also saw similar hidden-script activity on two other nodes, on September 23 and September 25. Those two dates sit close to the theft, not spread across the weeks since August 31.
SlowMist's conclusion is that the affected service environments were compromised before the assets moved.
August 31 is about three and a half weeks before Bitget's September 24 disclosure. The reports do not say whether any alert fired in that period. It is unknown whether anyone could have seen the activity.
What the reports leave unexplained
Bitget says the transfers bypassed its existing risk controls. The reports do not say why.
One plausible reading is that the commands arrived with valid internal credentials, so they looked like legitimate instructions. That is interpretation, not a finding.
Bitget also says IP behaviour patterns and on-chain analysis point to North Korean threat actors. It says Elliptic and TRM Labs found wallet overlaps with earlier hacks. This is Bitget's attribution, and the public reports do not set out the evidence.
What leaders should ask their teams
First, ask for a list of every security and network appliance that can reach production systems, with the permissions each one holds. A list of tools without their reach leaves this question open.
Second, ask where passwords and keys are kept on those tools. SlowMist's account of Product A involved a database password held in an environment variable.
Third, ask whether management consoles are separated from production networks. Ask whether employee logins to them need a second proof of identity.
Fourth, ask whether a large withdrawal or payment needs approval that does not depend on the same credential path. One compromised identity should not be enough.
Fifth, ask how far back security logs go and who reviews them. SlowMist's earliest linked activity predates the disclosure by about three and a half weeks.
A defensive tool is a door with a good reputation. Treat it like any other door and ask who holds the key.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: The Hacker News.
