How attackers reached Bitget’s wallet environment
A security product is still a system that can be compromised. In Bitget’s case, reporting based on findings from SlowMist and Mandiant says attackers accessed the exchange’s wallet environment after compromising two third-party security appliances with zero-day exploits. That is the central fact worth examining—not a claim that every security appliance is unsafe, but a reminder that protective infrastructure can become part of an attack path.
BleepingComputer reported that the earliest malicious activity identified in available logs dated to August 31, 2026. SlowMist said a service on one node of “Product A” was affected by a zero-day vulnerability. The attacker ran a hidden script under the service process, issued a command to read an environment variable containing a database password, and connected to the database. Similar hidden-script activity was observed on two other nodes on September 23 and September 25.
Mandiant’s account, as quoted in the report, placed unauthorized privileged access to third-party security appliances A and B on September 24. The attacker deployed a web shell on appliance B and established a command-and-control connection. Mandiant said the attacker used persistent access on that appliance to move laterally to Bitget’s production wallet job server and deploy malicious packages.
Those accounts describe related forensic findings, but they should not be flattened into a more detailed story than the reporting supports. The article does not identify the products or the vulnerability, and it does not explain how the different dates fit into a complete minute-by-minute intrusion timeline. The evidence reported is enough to show a path from compromised appliances to the wallet job server; it is not a license to fill gaps with assumptions.
What the reporting says happened next
BleepingComputer reported that attackers also placed malware on the production wallet job server and on a custom withdrawal tool. The report says that tool was used to launch the cryptocurrency theft after midnight on September 25. SlowMist described the transfers as beginning at 02:31 UTC+8 and ending at 05:23, spanning nearly three hours and multiple blockchains.
Bitget said the incident involved unauthorized transfers from hot and warm wallets. The company suspended withdrawals after detecting those transfers. CEO Gracy Chen said multiple assets were affected, including ETH, XRP, BNB, AVAX, USDT, USDC, and other tokens, across Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC, and Base.
The report identifies a total of $387.5 million stolen. Chen attributed the attack to North Korean hackers, citing IP behavior patterns and on-chain analysis, and said a compromised critical backend system was used to spoof transaction data and trigger the exchange’s authorization process. Those attribution and mechanism claims are Chen’s statements as reported by BleepingComputer; they should be read as such, rather than as independent conclusions established in the article.
Bitget later launched a Recovery Bounty Program offering 5% to people who help recover or freeze stolen funds, according to the report. BleepingComputer said a spokesperson was not immediately available to provide further information about the vulnerability or the compromised third-party products. Those unknowns matter: the public account does not name the products or provide a vendor patch timeline.
The third-party breach lesson
The practical significance is not that outsourcing security is a mistake. It’s that a vendor appliance may hold privileged access, process sensitive credentials, or sit on a route to critical internal systems. Its security posture therefore belongs in an organization’s own threat model. A purchase order and a vendor’s reputation don’t remove that exposure.
The Bitget account gives defenders specific questions to ask of their own architecture. Which appliances can reach production workloads? Which identities and secrets can those systems access? Are administrative interfaces exposed only where necessary? Can a security appliance initiate connections to a wallet or transaction-processing environment, and if so, under what tightly defined conditions? These are general defensive questions prompted by the reported access path, not details about controls Bitget did or did not have.
A useful design goal is to make compromise of one management or security component insufficient to reach high-impact systems. Network segmentation can limit which destinations an appliance can contact. Separate privileged identities and narrowly scoped credentials can reduce the consequences of a compromised service. Secrets should not be broadly available to processes that do not need them, and access to sensitive values should be monitored. These are recommendations, not claims about the configuration in this incident.
Incident response: preserve evidence and contain carefully
The available report highlights the value—and limits—of logs. SlowMist cited activity identified in available logs, including hidden scripts and database access. For responders more generally, retaining logs from security appliances, identity systems, network controls, and downstream servers can help establish what happened and when. Centralized, access-controlled storage can make evidence harder for an intruder to alter. That is general incident-response guidance; the report does not describe Bitget’s logging controls.
When a suspected third-party device is involved, responders should coordinate with the vendor while preserving forensic evidence. They can scope affected identities and systems, investigate unusual service processes and outbound connections, and restrict connectivity that is not required for operations. Any containment decision needs to balance the risk of continued access against the operational consequences of disabling a security product. The right sequence depends on the environment; the source does not say what response steps Bitget took beyond suspending withdrawals.
For organizations handling valuable transactions, response plans should also identify who can pause sensitive operations, who validates a restart, and how transaction integrity is checked. That’s not a claim about Bitget’s internal process. It is a planning question raised by an incident in which, according to Chen, attackers used a compromised backend system to spoof transaction data and trigger authorization.
Keep the facts and the analysis distinct
The public account establishes a reported route: zero-day exploitation of two third-party security appliances, privileged access and a web shell on one appliance, movement to a production wallet job server, and malicious packages on that server and a custom withdrawal tool. It also reports unauthorized transfers from hot and warm wallets and a theft spanning multiple chains.
It does not name the affected products or the vulnerability, nor does it provide enough detail to independently reconstruct every step. Good incident analysis respects that boundary. The strongest takeaway is still clear: systems intended to protect an environment can themselves become stepping stones, so their privileges, reachable destinations, and evidence trails deserve the same scrutiny as other critical infrastructure.