- What: Bitget says attackers compromised a critical backend system in its wallet infrastructure, used it to spoof transaction data, and triggered its own authorization process to move $351.6 million out of hot and warm wallets.
- Impact: ETH, XRP, BNB, AVAX, USDT and USDC were taken across Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC and Base, and withdrawals are suspended while the review runs.
- Fix / mitigation: No patch applies: Bitget has brought in Mandiant and SlowMist, contacted chain foundations (some have frozen attacker addresses), and says no further unauthorized transfers are possible.
- Who's at risk: Any organization whose payment or signing approvals rely on transaction data from a backend system that an attacker could compromise, especially crypto custodians and exchanges.
At 18:31 UTC on September 24, 2026, Bitget's security systems flagged unauthorized transfers from what the exchange called "a limited number of hot wallets." By the next day the total was $351.6 million. Bitget's CEO, Gracy Chen, said the attack method was "highly consistent with known patterns of North Korean hacker organizations," based on IP behavior patterns and on-chain analysis.
The number is large. How it happened matters more. According to Chen, the attacker "compromised a critical backend system within our wallet infrastructure, used it to spoof transaction data, and triggered our authorization process to move funds out." No private key was reported stolen and no signer was reported bribed. The approval process ran as designed and approved transactions built from false data.
What Bitget has confirmed
Bitget has disclosed more than many victims do in the first 24 hours, though it has not said how the attacker first got in. According to the exchange's public statements, reported by The Hacker News:
- Losses total $351.6 million, drawn from hot and warm wallets. Bitget says cold wallets and "the overwhelming majority of platform assets" were not affected.
- Affected assets are ETH, XRP, BNB, AVAX, USDT and USDC, spread across Ethereum, XRP Ledger, Arbitrum, Avalanche, Optimism, BSC and Base.
- Customer balances remain accurate. Deposits and trading continue. Withdrawals are temporarily suspended pending a "comprehensive security review."
- Mandiant and SlowMist are running a third-party investigation.
- Bitget has contacted the foundations of every affected chain, and some have confirmed they froze attacker wallet addresses.
- Bitget Wallet, the self-custodial product, runs on separate infrastructure and was not affected.
- "The specific method of system intrusion remains under active investigation."
The approval process did not fail. It received forged inputs from a system it trusted and approved them. When the machine that describes a transaction can be compromised, the humans and policies that approve that description give you no protection.
The pattern around it
The Hacker News notes that the disclosure came about a week after SentinelOne attributed an attack on an India-based IT services company to TraderTraitor, a North Korea-linked group. TraderTraitor is best known for stealing $1.5 billion from Bybit and $292 million from KelpDAO's LayerZero bridge. Bitget has not named a specific group, and neither do we. Its own statement is limited to consistency with known North Korean patterns.
Even so, the pattern is clear. The most costly crypto thefts no longer rely on breaking cryptography. They go after the systems around the signing step: the backend that prepares transactions, the interface that displays them, and the vendors and IT providers that can reach both. The key stays safe while the attacker controls what it signs.
The RedEye take
Bitget handled several things well. It detected the theft and published a timestamp. It kept cold storage separate from the hot wallets, so most assets were outside the blast radius. It brought in outside responders quickly and worked with chain foundations to freeze funds. Other firms should copy that playbook.
The architecture still did what attackers wanted it to. A single compromised backend system was able to write the transaction data that the authorization process accepted as true, and that one component was enough to move $351.6 million. When an approval chain trusts upstream data it cannot verify independently, it only confirms that the data is internally consistent.
Most companies are not crypto exchanges, but the lesson applies well beyond crypto. Finance payment runs, ERP vendor-bank changes, CI/CD release approvals and privileged-access workflows are all approval chains that trust an upstream system to describe the action correctly. North Korean operators have shown repeatedly that they will spend months inside that upstream system for a single large payout. Ask of every high-value approval in your environment: where does the approver's view of the transaction come from, and what happens if that source lies?
What defenders should learn
- Verify destinations out of band. The signer or policy engine should check every destination address against an allowlist held on separate infrastructure with separate admin credentials. If the backend that builds a transaction can also edit the allowlist, you have one control, not two.
- Reconcile every outbound transfer with a source request. Each hot-wallet withdrawal should map to a ledger entry, a customer withdrawal ID or a treasury ticket that was created before signing. A signed transfer with no matching request should page someone right away, not show up in a daily report.
- Cap the blast radius per time window, not per transaction. Spoofed data can pass per-transaction checks many times in a row. Hard velocity limits on hot and warm wallets, enforced at the signer rather than in the backend, set the worst-case loss before the attack starts.
- Treat IT service providers as part of the wallet perimeter. The TraderTraitor activity SentinelOne reported targeted an IT services company. Map every vendor with network or admin reach into signing-adjacent systems and give that access the same review you give signers.
- Prepare the freeze playbook in advance. Bitget got some attacker addresses frozen by contacting chain foundations. Keep pre-built contact lists and evidence templates for every chain you operate on, because every hour of delay moves more funds out of reach.
Pick your largest routine outbound action, such as a wire, a withdrawal or a production release. Trace which system produces the data the approver sees. If one compromised host could change both the action and its description, your approval control has a single point of failure.
What we still do not know
Bitget has not disclosed the initial access vector, which backend system was compromised, how long the attacker was inside, or how much of the $351.6 million has been frozen. These answers will decide whether other exchanges are exposed to the same technique. Watch for the Mandiant and SlowMist findings. Until they are published, assume the entry point is unknown and review the whole path from request to signature.
Source: The Hacker News, "Bitget Says Suspected North Korean Hackers Stole $351.6M After Backend Compromise," Ravie Lakshmanan, September 25, 2026. https://thehackernews.com/2026/09/bitget-says-suspected-north-korean.html
Fix It Yourself
Everything above is what happened. This is what to run. The check commands change nothing.
Check whether you are exposed
List recent interactive logins on a wallet backend or signing host (Linux, read-only)
last -F -w | head -50Find SSH authorized_keys files changed in the last 30 days on this host
sudo find / -xdev -name authorized_keys -mtime -30 -exec ls -l {} \; 2>/dev/nullShow accounts with UID 0 and accounts with a usable login shell
awk -F: '$3==0 || $7 !~ /(nologin|false)$/ {print $1, $3, $7}' /etc/passwdClose it
No vendor patch exists for this incident; containment: lock and expire an account you cannot account for (set the name first)
SUSPECT_USER=replace_with_username; sudo usermod -L -e 1 "$SUSPECT_USER" && sudo chage -l "$SUSPECT_USER"Move an unexplained authorized_keys file aside for review instead of deleting it (set the path first)
KEYFILE=/home/replace_with_user/.ssh/authorized_keys; sudo mv "$KEYFILE" "$KEYFILE.quarantine-$(date +%F)"Prompts for the agent you already run
You run a signing, treasury or payment-approval service and want to find where it trusts upstream data
After a suspected compromise of a wallet backend or signing-adjacent host
What to alert on
Alert on any signed outbound transfer from a hot or warm wallet whose destination address is missing from the independently maintained withdrawal allowlist, or that has no matching withdrawal request ID in the ledger created before the signing timestamp. In practice, join the signing service's audit log (fields: tx_hash, destination_address, amount, request_id, signed_at) against the ledger's withdrawal_requests table on request_id and destination_address, and page on any row with a null match or a mismatched destination. Add a second alert on hot-wallet outflow volume per rolling hour that exceeds your normal ceiling, because spoofed transactions can pass per-transaction checks.
Questions about your exposure?
RedEye Security provides assessments for organizations that need to understand their real risk.
Talk to us