The Anomaly
On a live stream, the CEO of a mid-tier centralized exchange said two things that cannot both be entirely true. First: no private keys were leaked. Second: funds were moved using the exchange's signing machine. Read those again. Keys untouched. Assets gone. That pairing is not a contradiction to dismiss. It is the entire incident compressed into a single sentence. The signing machine did exactly what it was built to do: it signed. The problem is that it signed something it should never have seen.
This is the shape of a signing-workflow hijack. Not a cryptographic break. Not a stolen seed phrase. A forgery delivered to an honest signer. Over a decade I have audited ERC-20 swap functions, replicated timestamp manipulation inside governance contracts, and reverse-engineered yield mechanics after a multi-billion-dollar collapse. The pattern here is familiar. The attacker did not defeat the math. They defeated the process wrapped around the math.
And they did it through a third-party tool the exchange only admitted to using after the fact.
Context: What a CEX Signing Stack Actually Is
Before we dissect the breach, we need to be precise about the machine that failed. People say "exchange wallet" as if it were one thing. It is not. A centralized exchange custodies user funds through a layered signing architecture, and every layer is a potential pivot point.
The public-facing layer is the front end: dashboards, withdrawal pages, multi-signature interfaces. Below that sits the backend service layer, which constructs transaction payloads, applies business rules, and queues them for approval. Then comes the signing tier: hardware security modules (HSMs), air-gapped signing servers, or a multi-sig quorum of keys. Finally, the broadcast layer pushes signed transactions to the chain.
The design intent of a signing machine is elegant. The private key never leaves the device. The machine receives a transaction payload, validates it against policy, and produces a signature. The key is the crown jewel; the signing machine is the vault door. Nobody steals the crown if they can walk in through the door holding a forged requisition form.
That is the first principle we must internalize. A signing machine protects the key. It does not, by default, protect the meaning of what it signs. Those are two different security properties, and conflating them is the industry's most expensive habit.
Now layer supply chain on top. Exchanges rarely build every component themselves. They lean on third-party tooling for monitoring, multi-sig coordination, front-end rendering, and transaction simulation. Each dependency is a trust edge. An attacker who cannot reach the vault directly will reach a vendor that the vault trusts. The CEO's own framing admitted as much: an intrusion into a third-party tool, propagated into the wallet backend, terminating at the signing machine. Three hops. One purpose.
A few weeks earlier, the same architecture had been targeted at another major exchange — an attack that combined signing-authorization tampering with a poisoned multi-sig interface. Two incidents, one grammar. This is not a Bitget story. It is a class story.
Core: The Three-Stage Penetration Chain
Let me reconstruct the mechanism as the evidence supports it, and mark the boundary where inference begins.
Stage One — Upstream Poisoning
The entry point is a third-party tool the exchange admits it used regularly. Not a wallet. Not a chain. A vendor component. That is the signature of a supply chain attack: you do not breach the target; you breach what the target trusts. The tool's identity was never disclosed, which is itself the most consequential omission in the entire disclosure. Supplier identity matters because trust in vendor tooling is often shared across many exchanges. If one tool is contaminated and multiple platforms depend on it, the compromise is not an incident. It is an epidemic.
Stage Two — Backend Propagation
From the tool, the intrusion reached the wallet service backend. This is the coordination layer where transaction payloads are assembled and routed. Whoever controls the payload construction controls the instructions that will eventually be signed. No key is needed to reach this layer, only network access and sufficient dwell time to understand the data flow. From an attacker's cost-benefit view, this is where the leverage lives.
Stage Three — Signing Workflow Hijack
Here is the crux. The compromised service, per the disclosure, "forged transaction information and used the signing machine to transfer funds," while separately insisting no keys were leaked. Both claims can be true simultaneously. The signing machine was fed a payload that misrepresented its true intent. The machine then did its job flawlessly and signed it.
This is blind signing, or transaction forgery. The cryptographic signature is valid. The authorization is fraudulent. The signature and the intent have been decoupled — and almost every wallet pipeline in this industry decouples them by design.
I have seen this failure mode from the inside. In 2024 I went line by line through a restaking protocol's slasher contract and found a race condition in the slashing-reward distribution logic. The penalty could be under-enforced because the sequence of state reads and writes was not atomic. The contract executed exactly as written. It never saw the coordinate that the operator assumed. That is the same disease: the machine is honest; the input it trusts is not.
The Bitget chain is that disease operating one layer lower, on real money.
Why This Is Harder Than a Key Theft
A stolen key is a breach with a clear perimeter. You rotate, you move funds, you trace the outflow. A signing-workflow hijack is worse in three ways.
First, every signature is cryptographically authentic. On-chain, nothing looks anomalous. There is no invalid signature to reject, no failed checksum to flag. The transaction is legal in the consensus sense. The stack is honest, the operator is not.
Second, attribution is a nightmare. The forgery originated in a vendor that may serve other consumers, transited a backend whose logs may be incomplete, and terminated in a device whose only output is a valid signature. Reconstructing intent requires the full chain of custody from tool to payload to signature request. If any link did not log its inputs, the trail is cold.
Third, the remediation is architectural, not procedural. You cannot patch a workflow you have not catalogued. And most exchanges cannot fully catalogue their own signing dependency graph, because it was assembled incrementally by different teams over years.
Reproducibility and the Discipline of Evidence
When I handled the Compound v1 governance interface in 2020, I did not write an opinion. I wrote a Hardhat script that reproduced a timestamp-manipulation flaw, walked a miner's delay through the voting window, and demonstrated how inclusion timing could flip an outcome. The point was never to be clever. The point was that trust should rest on executable evidence, not statements.
The same discipline applies here. We should treat "no private key was leaked" as a claim, not a fact. The claim is plausible given the architecture. It is also exactly the claim an operator would make if the alternative were a bank run. Compile the silence, let the logs speak — and right now the logs are mostly silent because the vendor, the loss figure, and the affected-user set are all undisclosed.
The Disclosure Asymmetry
Notice the structure of what was revealed. Disclosed: attack type is likely supply chain, no key leak, internal-actor probability low. Withheld: vendor identity, loss magnitude, user scope, final attack path. Every released fact points toward "containable." Every withheld fact is the kind that triggers fear. This is not an accident. It is an editorial choice, and it maps cleanly onto a pattern I have catalogued for years: governance is a myth; the bypass reveals the truth. The public statements are the governance layer. The missing vendor name is the bypass. Watch the bypass.
Contrarian: The Blind Signing Blind Spot Nobody Wants to Name
Here is the part the industry will not say out loud, because saying it implicates everyone.
If the forgery worked, then at least one human or automated reviewer approved a transaction whose contents did not match its true effect. That is not a Bitget failure. That is a default industry practice. Most multi-sig operators approve payloads they cannot fully decode, on interfaces they did not build, from vendors they did not audit. The green confirm button is a belief system, not a control.
We have spent a decade hardening the key and hardening the chain. We have spent almost nothing hardening the human-machine handshake that sits between them. Audits check contracts; they rarely check workflow integrity. Penetration tests probe perimeters; they rarely probe the semantic gap between a displayed transaction and a signed transaction. Root access is just a permission slip — and so is a prompt that says "confirm transfer."
There is a second uncomfortable point. The comparison to the earlier large-exchange breach is doing double duty. It helps comprehension. It also anchors the event to the memory of massive loss. Analysts should separate "same technique" from "same damage." Conflating them is how FUD compounds faster than facts, and the current information vacuum guarantees the market will fill the gap with its own worst assumptions.
My own view, formed across several of these incidents: the attacker here is not a script kiddie. Supply chain poisoning plus signing-workflow forgery is a high-cost, high-sophistication campaign. That profile looks less like opportunism and more like a persistent, organized adversary with patience, budget, and a repeatable playbook. Forks are not disasters, they are diagnoses — and this incident is diagnosing a systemic weakness in how centralized custody verifies meaning.
The Information Vacuum as the Real Risk
What worries me most is not the disclosed loss. It is the undisclosed remainder. Until root cause is confirmed, the operator cannot honestly claim the path is closed. A window may still be open. An access token may still be live. The "preliminary assessment" label is a risk alert that has not been lifted.
The market, meanwhile, prices information, not architecture. An event stuck in the uncertainty phase gets an uncertainty discount. Add the indirect link between a CEX's security reputation and its native token — trust drives fund retention, retention drives revenue — and you have a feedback loop that runs on sentiment, not supply mechanics. No tokenomics model describes this. Trust is the asset; its loosening is the drawdown.
I keep returning to a line I first wrote while tracking transient metadata in early NFTs: immutable metadata does not lie, but humans rewrite the record around it. Here the record is the vendor list, the loss figure, the user scope — all mutable, all human-controlled, all currently opaque.
Takeaway: What I Am Watching, and What I Expect to Break Next
I am not going to summarize. I am going to forecast.
Within one to three months, expect independent security firms to publish root-cause analyses that will either confirm or quietly contradict the official narrative. Watch for the vendor name to surface — whether by disclosure or by accident. If a single contaminated tool served more than one exchange, expect a second, related disclosure from an unrelated platform. That is the single most important signal on the board.
Watch the withdrawal flows and proof-of-reserves cadence. Continuous net outflow is the market's version of a failed signature. Watch whether the fix is architectural — payload verification, signing-content attestation, vendor diversification — or merely procedural. A procedural fix means the same attack returns under a new vendor.
The next breach of this type will not bother with your private keys at all. It will find the seam between what your screen shows and what your device signs, and it will live there. Heads buried in the hex, eyes on the horizon. The cryptography was never the weak point. It still isn't. The trust channel between a person and a machine is, and nobody has patched it yet.
Extended Notes: Reading the Attack Through an Audit Lens
A few closing observations, because the details matter more than the verdict.
Consider the three-stage chain as a maintainability problem, not just a security problem. Systems accreted over years tend to have hidden trust edges — a monitoring tool that reads wallet state, a notification service that formats transaction previews, a simulation engine that estimates gas. Each is invisible to the user and each is a candidate entry point. I have watched teams describe their custody stack as "two HSMs and a firewall" while quietly depending on nine third-party services nobody had mapped. The attack surface is always larger than the diagram.
Consider also the economics of the attack. Forging a signing request yields the highest possible return per unit of effort, because you inherit the target's own authorization. You do not need to move funds yourself; you make the victim do it. This is why I expect the technique to proliferate rather than fade. It is cheap on the attacker's side and catastrophic on the defender's side, and the asymmetry favors whoever is willing to spend months poisoning an upstream dependency.
Finally, consider what "no private key leak" actually buys an exchange in 2026. Regulators increasingly distinguish between key compromise and workflow compromise, because the two demand different disclosures. A key leak triggers one set of obligations; a workflow forgery triggers another. If the industry cannot clearly tell the difference, disclosure quality will remain poor, and the market will keep pricing uncertainty rather than facts. That gap — between what the machine did and what the operator said — is where the next chapter of this story will be written, and I intend to keep reading the logs until they agree.