On September 24, 2026 at 18:31 UTC, Bitget — the world's sixth-largest crypto exchange by trading volume, handling roughly $1.1 billion a day — detected unauthorized transfers draining its hot and warm wallets. By the time the outflow was contained, approximately $351.6 million in crypto (widely reported as "$352 million") had left the platform across multiple chains, in assets including ETH, BNB, AVAX, USDT, and USDC. Cold storage was untouched. Deposits and trading stayed live; withdrawals were paused pending review.
What makes this incident worth a technical post-mortem — rather than just another line in the growing list of nine-figure exchange hacks — is what CEO Gracy Chen said didn't happen: nobody stole Bitget's private keys.
The Attack: Forging the Paperwork, Not Stealing the Keys
Chen's own description is the clearest technical summary available so far: "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."
She reached for a banking analogy that holds up well under scrutiny: this was "someone slipping forged withdrawal slips through a bank's own teller window. The vault keys stayed locked up."
Unpacked technically, that means the attacker didn't need to break Bitget's cryptography at all. Modern exchange wallet infrastructure typically separates two things: the cryptographic signing layer (private keys, HSMs, multisig signers — the actual "vault") and the authorization/orchestration layer that decides which transactions get presented to that signing layer for approval in the first place (the "teller window"). Chen's account — and the broader reporting on it — describes attackers compromising the second layer: a backend system responsible for constructing and validating transaction data before it reaches signing. By spoofing what that system reported as a legitimate, pre-approved transaction, the attacker got real signing infrastructure to sign fraudulent transfers, without the keys themselves ever being exposed, copied, or cracked.
Security researchers examining the incident describe it as exploiting "a logic flaw in the withdrawal-processing system" — the system was tricked into approving requests it should have rejected, rather than being bypassed outright. That distinction matters operationally: it's the difference between an attacker who now permanently owns your keys (and can keep draining funds indefinitely) and one who found a single flaw in a validation pipeline, which — once identified and patched — closes the door.
What's still unconfirmed: to Bitget's credit, this level of detail came from the CEO within roughly 24 hours of detection, which is fast by industry standards. But independent security researchers reviewing the incident have been explicit that "the precise initial-access vector, persistence mechanism, and control failures remain unknown" pending Bitget's full incident report. How the attacker first got into that backend system — a compromised employee credential, a supply-chain dependency, a misconfigured internal service — is the part of this story that isn't public yet, and it's the part that actually determines whether other exchanges running similar architecture are exposed to the same class of entry.
Who Did It — and Why That's Not a Side Note
Chen has pointed at North Korea, citing forensic detail rather than just suspicion: "IP addresses match VPN patterns tied to a known North Korean hacking group." Independent researchers reportedly traced a portion of the stolen funds to a wallet labeled "AFX EXPLOITER," previously linked to a smaller $24 million breach with the same North Korean fingerprints.
This attribution fits a pattern that's become the dominant threat model for the entire exchange industry: North Korean state-linked actors are estimated to have stolen roughly $2.02 billion in cryptocurrency during 2025 alone, a figure that includes the $1.5 billion Bybit hack from February 2025 — the largest crypto theft in history, and one the FBI formally attributed to North Korea.
That's not a coincidence worth glossing over. The Bitget and Bybit hacks, seventeen months apart, share a structural similarity that's more important than the dollar figures: both defeated the layer that decides what a signer is approving, not the cryptography that proves ownership.
The Bybit Precedent: Same Category of Attack, Different Mechanism
It's worth walking through exactly how Bybit's $1.5 billion hack worked, because the parallel to Bitget is instructive even though the specific technique differed. Bybit's cold wallet used Safe{Wallet}, a widely-used multisig platform. Attackers first compromised a Safe developer's machine and used that access to inject malicious JavaScript into the Safe UI — but only for Bybit's specific wallet address, so the tampering stayed invisible to everyone else. When a Bybit signer initiated a routine transaction, the injected script silently swapped the real transaction data for a malicious one, let the signer approve what looked like the legitimate transfer, then restored the original data in the signature response — so the signature the signer thought they gave for a normal transfer was actually valid for a completely different, attacker-crafted transaction.
That malicious transaction used a delegatecall — a function that lets one smart contract execute code using another contract's storage — to overwrite storage slot 0 of Bybit's wallet, redirecting the entire wallet's logic to attacker-controlled code. From there, the funds were gone.
NCC Group's technical review of the incident lays out the two root causes clearly: Safe's general-purpose, delegatecall-capable architecture gave far more power than Bybit's actual use case needed, and the EIP-712 signing standard — meant to make transaction data human-readable before signing — simply can't render nested smart contract calls, forcing signers into what the industry calls "blind signing": approving something you can't actually verify the substance of.
Bitget's attack didn't use a compromised UI or a delegatecall exploit — its mechanism was a backend authorization system being fed spoofed data rather than a signer's own screen being tampered with. But the underlying failure mode is the same: a human or automated approval step trusted data it had no independent way to verify, and an attacker who understood that trust boundary walked through it without ever needing the keys on the other side.
What Would Have Stopped This
Drawing on what's been published about both incidents, the countermeasures cluster into a few concrete categories — none of which are exotic, all of which cost real engineering discipline to actually implement.
Independent verification of what's being signed, not just what a UI or backend claims is being signed. Bybit's core lesson was that trusting a single system's rendering of a transaction — whether that's a UI or, in Bitget's case, an internal backend service — is a single point of failure. The fix is cryptographic and structural: validate the hash of a proposed transaction against its actual on-chain effect through an independently-sourced path, not just the path the compromised system itself provides. If the system that constructs a withdrawal request is also the only system that verifies its own legitimacy, a compromise of that one system is game over.
Anomaly detection and rate limiting on withdrawal volume, not just on individual transaction validity. A logic flaw that approves one fraudulent transaction is bad; a logic flaw that lets an attacker drain $350 million across dozens of transactions in under an hour is a monitoring failure layered on top of the original flaw. Velocity checks — flagging or auto-pausing when outflow volume or rate spikes far outside historical norms — are a second, independent layer that doesn't need to understand the specific exploit to catch its effect.
Minimizing what's reachable without cold-storage-grade controls. Both hacks specifically targeted hot and warm wallets — the funds kept liquid for operational speed — while cold storage in both cases stayed untouched. That's not luck; it's the entire point of the hot/cold split. The lesson isn't "eliminate hot wallets" (exchanges need liquidity to function), it's that the amount sitting in the reachable tier should be sized to what you can afford to lose to exactly this kind of internal-system compromise, not to trading convenience alone.
Reducing the blast radius of a single compromised backend component. Whatever internal system Bitget's attacker got into apparently had enough reach to get fraudulent transactions past authorization. Least-privilege design — where no single backend service can unilaterally push a transaction to signing without a second, independently-secured check — turns "one compromised system" into "would need to compromise two independently-secured systems," which is a categorically harder bar for an attacker to clear.
Third-party audits specifically of the withdrawal-authorization pipeline, published, not just held internally. General smart-contract or code audits are now standard across the industry; audits of the specific internal logic that decides "does this withdrawal get approved" are rarer, and this is exactly the component both hacks exploited.
Why This Isn't Just Crypto-Industry News
It's tempting to file this under "crypto exchanges have bad security" and move on. That reading misses the actual lesson. The failure in both Bitget and Bybit wasn't cryptographic weakness — it was a gap between what an authorization system is supposed to verify and what it actually can verify given how it was built. That gap exists in any system that moves money or approves high-value actions based on internal service-to-service trust: payment processing pipelines, fraud verification engines, and internal financial approval workflows all have the same shape of risk, whether or not blockchain is involved anywhere in the stack.
That's precisely the class of failure CyberFence's Fraud & Payment Verification engine is built around: making sure the systems that authorize money movement can't be fooled by spoofed or malformed data further up the pipeline, and that authorization decisions are independently verifiable rather than resting on a single component's say-so. The Bitget hack is a nine-figure, real-world case study in why that design principle isn't theoretical. The engine remains in private pilot as we test it against real cases before wider release.
Sources: CoinDesk and CNBC reporting on the Bitget incident and CEO statements, September 2026; Bitcoin Magazine and Cyber Security News coverage of the outflow; NCC Group, "Bybit Hack: In-Depth Technical Analysis"; Trending Topics and CoinCentral coverage of attribution. Bitget's own full incident report was not yet public at the time of writing — some technical details above, particularly the initial-access vector into Bitget's backend system, remain unconfirmed and should be treated as provisional pending that report.