Writing
Four withdrawal-path incidents, five questions the public record leaves open
The public records on DMM Bitcoin (May 2024), WazirX (July 2024), Bybit (February 2025) and Bitget (September 2026) differ in almost every detail. Different attackers’ routes, different custody set-ups, different disclosure. Yet the same five questions are left open by each. This note lists them, shows what each record says and does not say, and explains why they matter to anyone running a withdrawal path.
It draws only on the four source-by-source notes we published, each of which names the primary sources it read. If a source has since been revised or a later report published, the table below is out of date. Nothing here is a claim about any company’s current controls.
The five questions, by incident
Status key: Stated (a source states it), Partly (one source states it or it is stated in general terms), Not stated (none of the sources read says), Disputed (sources differ).
| Question | DMM Bitcoin | WazirX | Bybit | Bitget |
|---|---|---|---|---|
| 1. What did the people approving see? | Not stated | Partly: WazirX says its signing hardware did not display the token or destination, so signers relied on the provider’s website; what they saw is not stated | Partly: one forensic source says the interface showed legitimate details; others do not say | Not stated: whether any human approval step existed on the affected path is not said |
| 2. What checked that what executed equalled what was approved? | Not stated: who approved or signed the altered request, and how | Partly: a provider-enforced whitelist is described by WazirX; no independent examination is published | Not stated: who approved, on which devices, under which procedure | Not stated: how forged commands were validated, by which component, and which risk checks were bypassed |
| 3. Where did the compromise sit, and did anyone independent examine it? | Disputed: police and the wallet-software company name different mechanisms | Disputed: exchange and custody provider place it in different locations; no forensic report published | Partly: the forensic firm calls a full investigation of the interface provider’s infrastructure the biggest gap | Partly: two forensic firms, both preliminary; vendors unnamed |
| 4. What changed afterwards? | Not stated in detail: measures said to be implemented, not described | Partly: general lessons and mitigations listed | Not stated: nothing found from either company | Partly: vulnerability said to be remediated, no detail |
| 5. What should have limited the outflow, and why did it not? | Not addressed in the pages we read | Partly: whitelist exists; WazirX says the malicious transaction did not go to a whitelisted address | Not addressed in the pages we read | Partly: forged commands are said to have bypassed risk checks; which checks and why is not said |
1. What did the people approving see?
In DMM Bitcoin the public record names a tampered transaction request but not what the approver or signer saw. In WazirX the exchange says its signers relied on the provider’s website because the hardware did not display the destination or token, and the provider says its platform was not compromised. In Bybit one forensic firm says the interface displayed legitimate details while different data was signed; the other sources we read do not say. In Bitget the record describes forged withdrawal commands written into the wallet system; it does not say whether a person was meant to approve them.
Why it matters (our analysis). Where a person or device approves a request, what they are shown is the control. If the screen is controlled by the same party or path that builds the request, the approval cannot detect a change in it. In three of the four, the record says nothing firm about what was shown.
2. What checked that what executed equalled what was approved?
None of the four publishes who or what compared the executed transaction with the approved request, and where. WazirX describes a whitelist enforced by the custody provider; Bitget says forged commands bypassed risk checks without naming them.
Why it matters (our analysis). The last point where content can change, and the party that verifies it independently of whoever built it, is the heart of a withdrawal path. If the record cannot answer it, a reader cannot judge whether the same weakness exists in their own set-up.
3. Where did the compromise sit, and did anyone independent examine it?
The accounts disagree or stop short. DMM: the police and Ginco describe different mechanisms for compromising the employee, and Ginco says it cannot publish DMM’s own environment. WazirX: the exchange suspects the custody provider’s interface; the provider says its platform is secure and points to a customer-level compromise; neither publishes the forensic report. Bybit: the forensic firm names a full investigation of the interface provider’s infrastructure as the biggest gap. Bitget: both forensic reports are labelled preliminary or in progress, and the products are unnamed.
Why it matters (our analysis). When a vendor sits on the path, the parties best placed to explain a failure are the exchange and the vendor, and each has reasons to describe it differently. Without an independent examination of both sides, the public lesson is "a vendor was involved", which is too coarse to act on.
4. What changed afterwards?
DMM: Ginco says recurrence-prevention measures were implemented, and does not describe them. Bybit: we found nothing from either company on what changed. WazirX: the exchange lists general lessons and mitigations. Bitget: the exchange says the vulnerability was identified and remediated, without detail.
Why it matters (our analysis). The value of a post-mortem to other operators is in the fix. A fix described only as "measures" cannot be compared with one’s own set-up.
5. What should have limited the outflow, and why did it not?
Bitget says forged commands bypassed risk checks and then deleted traces; which checks, and why they did not hold, is not said. WazirX says a whitelist was in place and that the malicious transaction did not go to a whitelisted address. For DMM Bitcoin and Bybit, the pages we read do not address outflow limits or holds.
Why it matters (our analysis). Limits and holds that sit outside the application that creates the withdrawal are the last line when everything before it fails. The record rarely says whether they existed or how they were set.
What to take from this
These are the questions a review asks from the inside, with evidence, because the public record cannot answer them. They are also the questions in our withdrawal-path checklist and vendor access checklist, and the rules behind them are in the invariant catalogue. If you want them answered for your own exchange from evidence, see withdrawal-path review: scope and method.
Sources
The four notes: DMM Bitcoin, WazirX, Bybit, Bitget. Each lists its primary sources, with dates.
If you represent a company named here and see an error, or can point us to a source we could not read, write to research@deebug.io and we will correct it.