Bitget says its private keys were never compromised. The signer did exactly what it was asked to do

The keys held. Everything the keys were protecting left anyway

Two sentences published by Bitget within 24 hours of each other describe the whole incident, and they do not contradict one another.

The first, at 22:30 UTC on 24 September 2026: "At 18:31 UTC on September 24, 2026, Bitget's security systems detected unauthorized transfers from some of our hot wallets." The second, the following morning: "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. Private key compromise has been ruled out."

Read those together and the shape is clear. Nothing that holds a key was broken into. The system that decides what a key should sign was fed data it believed, and the authorisation process then did precisely what it was built to do. Bitget's own figure for what left is 351.6 million dollars, across Ethereum, the XRP Ledger, Arbitrum, Avalanche, Optimism, BSC and Base.

What that does not establish. It does not establish how the backend system was reached: Bitget says the intrusion method is still under investigation and has declined to speculate, which is the right answer at this stage and an unsatisfying one. It does not establish that key custody controls are worthless, because key custody worked exactly as designed here and stopped exactly the thing it was designed to stop. It does not establish user losses, because Bitget states the full amount falls within its User Protection Fund. And it does not establish who did it, whatever the headlines say.

Two loss figures in one day, against one fund

The written security notice puts the loss at approximately 351.6 million dollars. At a town hall on 25 September, reported by The Record, chief executive Gracy Chen gave the initial estimate as 387.5 million dollars. Both figures come from the same company on the same day. Neither is presented as final.

The difference is 35.9 million dollars, which is 10.2 per cent more than the written figure. That matters only because of what it is measured against. Bitget states its User Protection Fund holds over 464 million dollars, and states that the full amount of the loss falls within that cover.

The same protection fund measured against the two loss figures Bitget published on 25 September 2026. Arithmetic is ours, from Bitget's stated figures.

Loss figure and where it comes from	Share of the 464 million fund	Fund remaining
351.6 million, written security notice	75.8 per cent	112.4 million
387.5 million, town hall estimate	83.5 per cent	76.5 million
Difference between the two	7.7 percentage points	35.9 million

A solvency claim is being measured against a number that moved by 35.9 million dollars inside a day and is still labelled an estimate. The claim may well hold. The point is that it is a claim about a subtraction, and only one of the two terms is fixed.

This is not an accusation of concealment. Loss figures move in the first 48 hours of every incident of this kind, as tracing catches transfers that on-chain analysts saw before the exchange reconciled them: blockchain security firms watched more than 175 million dollars leave before the larger movements. A company publishing quickly and revising is behaving better than one publishing late and precisely. But a reader should hold the ratio, not the reassurance.

What a three-tier wallet architecture actually protects

Bitget describes a three-tier wallet architecture and says the breach touched only part of the hot and warm layers, with cold wallets fully secure. That is a real control and it did real work. It is also a control over where key material lives, and this attack did not go near key material.

Split the path an outgoing transfer takes into two halves. One half is custody: who holds the signing key, in what hardware, behind which approvals, in which tier. The other half is instruction: what the signing system is told to sign, by which upstream service, on the basis of what data. Custody controls answer the question "can an attacker steal the key". They do not answer the question "can an attacker make the legitimate key sign something".

The tiers themselves are worth stating plainly, because the language does a lot of quiet work. A hot wallet is one whose keys are available to an online service so that withdrawals can be processed without a human in the loop. A warm wallet sits behind more approvals and is used less often. A cold wallet is offline and requires a deliberate, usually physical, process to move anything. The tiering limits how much is reachable at machine speed, and that limit held: Bitget says the breach touched only a portion of the hot and warm layers.

What tiering does not do is check whether a given instruction should exist. A hot wallet is hot precisely so that it can act on instructions automatically. Once the composer of those instructions is untrusted, the design goal of the tier and the failure mode of the incident are the same property.

The failure class has a name and it is older than cryptocurrency. MITRE calls it the confused deputy, CWE-441: a privileged component is tricked into using its authority on behalf of somebody else. The deputy here is the authorisation process. It was not bypassed, it was not disabled, and it did not fail an integrity check. It was asked, by something it trusted, to approve transfers, and it approved them.

That is why "private key compromise has been ruled out" is simultaneously true, materially important and no comfort at all. It rules out the scenario where the attacker walks away with an asset that keeps working after the incident closes, which is a genuinely worse outcome and worth stating. It says nothing about the loss.

What the attribution claim actually says

Chen has said the attack is, on the basis of IP behaviour patterns and on-chain analysis, highly consistent with known patterns of North Korean hacker organisations. Read that carefully, because it is a carefully built sentence and it is not what most coverage has made of it.

"Highly consistent with known patterns" is a similarity claim. It says the observed behaviour resembles behaviour previously attributed to a set of actors. It does not say the actors are the same, and it is not evidence of the same kind as, for example, a seized server or an indictment. Similarity claims in this space are weak by construction, because the behaviours being matched are cheap to copy and the infrastructure is frequently rented.

What Bitget has stated, and what it has not, as of 25 September 2026.

Question	On the record	Not stated
How much left	Approximately 351.6 million, and 387.5 million at a town hall	Which figure is final
What was compromised	A critical backend system in the wallet infrastructure	How that system was reached
What was not compromised	Private keys, cold wallets, Bitget Wallet	Whether the backend held any credentials
Who did it	Highly consistent with known North Korean patterns	Any actor named with evidence
When withdrawals resume	Being prepared in parallel	Any timeline, deliberately

Bitget has engaged Mandiant and SlowMist, notified law enforcement, and says several chain foundations have frozen attacker addresses. It has also offered a recovery bounty of 5 per cent for voluntarily freezing attacker funds and 5 per cent for funds recovered, which is a commercial instrument rather than a security control and is worth naming as one.

One further piece of company conduct deserves credit rather than cynicism. Asked when withdrawals resume, Bitget said it would not commit to a window it cannot guarantee. Most incident communications fail in exactly the opposite direction.

What to take from it if you do not run an exchange

Almost nobody reading this operates a crypto exchange. Nearly everybody reading this operates something with the same shape: a privileged back end that composes instructions, and a signing, approving or executing component downstream that trusts them. Payment runs. Payroll files. Certificate issuance. Automated change deployment. Any agentic system where a model composes an action and a tool executes it. The custody question and the instruction question come apart in all of them.

The last one is not a soft point. The difference between an incident that ends and an incident that becomes a run on the institution is often whether the first public statement contained a number, a time and an honest gap.

The question this leaves

Security spending on this class of system overwhelmingly goes to custody. Hardware modules, threshold signing, quorum approvals, tiered wallets, ceremonies. All of it is real engineering and none of it is theatre. All of it answers a question about theft of the key.

Bitget's own account is that none of that was defeated. The attacker did not need it. They needed one upstream service that the approval path believed, and the approval path did the rest with keys that remain, as of today, uncompromised.

So the question for your own architecture: if an attacker owned the system that tells your most privileged component what to do, and obtained no keys and no credentials at all, what could they cause, and which control stops it?