Why didn't the two small test transfers trigger a risk-control alert?
Most exchange risk-control systems are built around amount or frequency thresholds — only transactions above the threshold get flagged or routed to manual review. The attacker clearly understood this mechanism and deliberately kept the test transfers below it, effectively using a "legitimate-looking small withdrawal" to probe the system's response. Once it was confirmed that no alert fired, the attacker scaled up within 30 minutes.
This also reveals a structural weakness in risk-control logic that relies purely on amount thresholds — it assumes attackers won't patiently test the system first. This incident shows that an attacker with internal system access has every incentive to reconnoiter before striking.
Does "Cold Storage was entirely unaffected" mean Bitget's hot/cold separation architecture worked as intended?
To some extent, yes. The core logic of hot/cold separation is to keep the bulk of assets that don't need frequent movement in a fully offline environment attackers can't reach through a network intrusion, while only a smaller portion sits in hot or warm wallets to handle day-to-day withdrawal demand and absorb that risk. In this incident, even though the attacker gained administrative access to internal systems, that access couldn't cross over into fully offline cold storage — which is exactly the outcome hot/cold separation is designed to achieve.
That said, this isn't grounds for complacency: the $388 million in hot and warm wallets was a real loss for users regardless. Hot/cold separation reduces the scale of the worst case — it doesn't reduce the risk to zero.
Since user private keys weren't exposed, does that mean individual users don't need to do anything?
As far as protecting your own wallet's Private Key goes, no extra action is needed, since the problem wasn't on the user side. But if you hold assets on Bitget, it's practical to keep an eye on the exchange's follow-up investigation reports and any compensation plan, and to watch whether the exchange adjusts its withdrawal review process going forward (such as adding an independent second layer of review).
More broadly, this incident is also a reminder: regardless of which exchange you use, understanding that exchange's cold-to-Hot Wallet ratio and whether it publishes proof-of-reserves is more useful than simply assuming "this exchange is big, so it must be safe."
If the flaw was in a third-party security product, who's actually responsible?
From a user's perspective, the answer to this question doesn't really matter — whether the root cause was a vendor's product vulnerability or a gap in the exchange's own integration process, the fact that user assets were put at risk doesn't change, and the exchange remains the party users directly trusted with their funds. The chain of responsibility ultimately comes back to the exchange.
From an industry governance standpoint, though, this incident does highlight an increasingly common problem: large exchanges are heavily dependent on infrastructure provided by external security vendors, and those vendors' own audit standards and speed of zero-day disclosure are hard for outsiders to directly examine. This is part of why regulators and industry self-regulatory bodies have begun pushing exchanges to disclose more about their supply-chain risk management.
On September 24, 2026, cryptocurrency exchange Bitget confirmed a major security incident resulting in losses of roughly $388 million. What makes this case particularly notable is that the attacker didn't breach a system Bitget built itself — they exploited a zero-day vulnerability in a third-party security product the exchange relied on.
According to Bitget CEO Gracy Chen, the attacker exploited a zero-day vulnerability in an unnamed third-party security product to gain access to an internal management system. Rather than going straight after external wallets, the attacker inserted forged withdrawal commands into wallet-related backend services — commands that, from the system's perspective, looked indistinguishable from legitimate internal operations. Using stolen high-level credentials, the attacker disguised the activity as routine administrative operations while simultaneously erasing traces of the intrusion, making the breach harder to fully reconstruct after the fact.
The attack timeline shows a clearly staged operation. At 18:31 UTC on September 24, the attacker executed two small test transfers, deliberately kept below Bitget's risk-control threshold, triggering no alerts. About 30 minutes later, larger transfers began — and these successfully bypassed the risk controls that should have flagged anomalous withdrawals. The stolen funds were then spread across addresses on multiple blockchains, including Ethereum/EVM networks, the XRP Ledger, Zcash, and Tron — a rapid cross-chain dispersal technique that has become a common money-laundering precursor in large exchange hacks in recent years.
Importantly, the incident affected only Bitget's hot and warm wallets — those kept online or semi-online to handle day-to-day withdrawal demand. Cold storage was entirely unaffected, and Bitget emphasized that no individual user's private keys were stolen or leaked in this incident. The attacker gained system-level administrative access, not direct access to individual users' keys. This distinction matters: it points to a problem in the exchange's internal architecture and third-party supply chain, rather than any mistake on the part of individual users.
Bitget suspects the attack is linked to a North Korean hacking group, potentially TraderTraitor — a group that has been involved in multiple large cryptocurrency thefts in the past — based partly on fund-flow patterns and techniques identified by blockchain analytics firm TRM Labs. In the aftermath, Bitget restricted access to the affected systems, revoked potentially compromised credentials, added an independent second layer of withdrawal review, and isolated the affected systems while waiting for the third-party vendor to patch the vulnerability in its security product.
If you hold assets on a centralized exchange, this incident is a reminder that whether the exchange's own code has bugs is only part of the risk picture. Which third-party security vendors an exchange relies on, and whether those vendors' products have independent audit records, is an equally real factor affecting the safety of your funds — one you can't easily see directly. Concrete things worth checking include whether an exchange has publicly disclosed its incident response process, whether withdrawals go through an independent second layer of review rather than a single system's say-so, and the exchange's cold-to-Hot Wallet allocation ratio — in this incident, intact cold storage is exactly what layered defense is supposed to deliver.