Bitget Says Suspected North Korean Hackers Stole $351.6M After Backend Compromise
- ID
- 28503
- Status
- summarized
- Published
- 25 Sep 2026, 6:35 PM
- Fetched
- 25 Sep 2026, 8:50 PM
- Provider
- The Hacker News
- Category
- security
- Original URL
- https://thehackernews.com/2026/09/bitget-says-suspected-north-korean.html
- Source URL
- https://feeds.feedburner.com/TheHackersNews
Summary
- Score
- 3.5
- Created
- 25 Sep 2026, 8:51 PM
- Tags
- Audience
- developersstartup_founders
What happened
Bitget says suspected North Korean threat actors moved $351.6 million out of its hot and warm wallets, detected at 18:31 UTC on September 24, 2026, and it has suspended withdrawals while Mandiant and SlowMist investigate. CEO Gracy Chen said the attacker compromised a critical backend system inside the exchange's wallet infrastructure, used it to spoof transaction data, and triggered the authorization process to move funds; affected assets include ETH, XRP, BNB, AVAX, USDT and USDC across Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC and Base. The write-up notes the method is 'highly consistent' with known North Korean patterns, and follows SentinelOne attributing the TraderTraitor group to an attack on an India-based IT services company, a group also linked to the $1.5B Bybit theft and $292M KelpDAO LayerZero bridge loss.
Why it matters
The concrete failure mode is not a smart-contract bug or a leaked key — it is an authorization pipeline that accepted transaction data produced by a compromised internal backend, so spoofed data passed as legitimate. If you run any system where one service both writes transaction details and feeds the approval/signing step, that design is the thing to check; the $351.6M figure and the multi-chain spread (eight chains, six assets) show the blast radius when the approval path trusts upstream data. Malaysian teams building exchange, payment or wallet-adjacent backends should note that freezing depended on the affected chains' foundations cooperating after the fact — recovery was not in Bitget's hands.
Discussion angle
Walk through the stated attack path — spoofed transaction data triggering the authorization process — and ask whether your own signing/approval service re-derives transaction details from an independent source or trusts whatever the requesting backend sends.