Bitget says it found the root cause on 25 September. It described it three days later and names no product

A suspect first, then a cause, then the cause described three days later

Bitget's own timeline says its security team identified the root cause of the theft at 08:43 UTC on 25 September 2026, 14 hours 12 minutes after the first unauthorised transfer at 18:31 UTC the day before. The first written statement we can find that says what that cause was is chief executive Gracy Chen's recap post on X at 10:17 UTC on 28 September: the attacker "exploited vulnerabilities from third-party products". That is 73 hours 34 minutes later, or 70 hours 47 minutes if the disclosure came when that day's livestream began at 07:30 UTC. Call it three days.

Set two other timestamps beside those. Chen's post saying the attack was consistent with techniques used by "DPRK-linked hacker groups" (North Korea) went out at 05:43 UTC on 25 September, about three hours before Bitget says it found the cause. Her post saying a critical backend system had been compromised, and that the method of intrusion was still under active investigation, went out at 00:43 UTC the same morning. The public order was a suspect, then a location, then, three days after the stated finding, a class of entry point. And the full incident report that a 24 September notice on X said "will be published within 24 hours" had not appeared by the morning of 29 September, more than three and a half days past that mark.

What that does not establish. It does not establish that Bitget held anything back: telling a vendor before telling the world is ordinary practice for a flaw that may still be unfixed, and Bitget says it notified the vendor. It does not establish which product, which vendor, or whether a CVE exists. No source we read names any of them, and this briefing names none. It does not establish that the accounts of 25 and 28 September conflict: on the record they describe different steps of one chain, and the 25 September post said in terms that the intrusion method was not yet known. And it does not establish who did it. The attribution is the victim's suspicion, resting on indicators Bitget has not published.

Our earlier briefing, Bitget says its private keys were never compromised, covered the mechanism as it stood on 25 September and is not repeated here. This piece asks how the account of the entry point has changed, how much of that is information and how much is wording, and what a reader would need in order to test it. Three details in the earlier briefing need correcting, and they are listed before the checklist.

What Bitget said about how, in the order it said it

The table lists each dated Bitget statement we found about how the attacker got in, in UTC, with what each one left open. The chart under it draws the same statements to scale, so that the silences show as distance.

Bitget statements in the order made, times in UTC. Read from Bitget's X posts, support centre articles, explainer and incident pages. The 08:43 entry comes from Bitget's own later timeline, not from a statement made that morning.

When, and where	What it said about the entry	Not stated
24 Sept 21:30 (X, CEO); 21:39 (support centre)	Nothing. "We will not speculate on the attack vector until the investigation is complete." The X version says the full incident report "will be published within 24 hours"; the support centre copy, as fetched on 29 September, omits that line.	Any entry point. In the support centre copy, any report date.
25 Sept 00:43 (X, CEO)	The attacker "compromised a critical backend system within our wallet infrastructure", used it to spoof transaction data and triggered the authorisation process. "The specific method of system intrusion remains under active investigation."	How the backend system was reached.
25 Sept 05:43 (X, CEO, summarising a livestream)	Nothing on entry. Based on IP behavioural patterns and on-chain signatures, the attack is "consistent with techniques used by DPRK-linked hacker groups" (North Korea).	The indicators themselves.
25 Sept 08:43 (Bitget's later timeline, not a statement made at the time)	The security team "identifies the root cause of the incident".	What the root cause was.
25 Sept 14:03 (X) and 14:05 (support centre)	"The underlying vulnerability has been identified and remediated." Attack path and methods identified. Loss revised to $387.5 million.	Whose vulnerability. Any product.
26 Sept 03:55 (support centre)	Repeats that the vulnerability involved "has been identified and remediated" and sets the withdrawal schedule.	Whose vulnerability.
28 Sept 07:30 livestream; 10:17 recap post (X, CEO)	"The attacker exploited vulnerabilities from third-party products to steal internal credentials", then used them to send fraudulent withdrawal commands that bypassed risk controls. The Block reports she called it a zero-day.	Which products, how many, which vendors.
Explainer page dated 27 Sept; text changed after 28 Sept (archived 28 Sept 19:36)	The attacker "may have exploited a vulnerability in a third-party security product to potentially obtain high-level internal credentials". Called a preliminary finding.	Product, vendor, CVE. The certainty is hedged.
29 Sept 00:00 (incident page, last updated)	A third-party security product "contained a zero-day vulnerability" the attackers exploited. Bitget "has confirmed the full attack chain". A formal report "will be released soon".	Product, vendor, CVE, report date.

Two things stand out in the drawing. The word "vulnerability" was public at 14:05 UTC on 25 September, 5 hours 22 minutes after the stated root cause, and Bitget was already calling it remediated. What it had not said, for another two and a half to three days, was whose vulnerability it was. And the longest stretch on the chart is the quiet one: from 03:55 UTC on 26 September to the start of the livestream is 51 hours 35 minutes, in which we found no Bitget statement about the entry point.

One chain told in instalments, with the load-bearing words moving

It is tempting to call this a changed story. On the record it is a story told in instalments. The 25 September account says what was compromised: a critical backend system in the wallet infrastructure, used to spoof transaction data. The 28 September account says how the attacker reached it: a flaw in a third-party product yielded high-privilege internal credentials, which opened an internal management system and then wallet-related backend servers, from which forged withdrawal commands were written straight into the wallet system. The first post said the method of intrusion was under investigation. A later answer to that question is not a reversal.

What did move is the wording around the terms that carry the weight. The table sets Bitget's earlier and later phrasing side by side, and every cell is Bitget's own or a labelled report of it.

Earlier and later Bitget wording on six points. Sources: Bitget X posts, support centre articles, explainer page, incident page, and the livestream as translated by ChainCatcher. Quotations are short and exact; the Chinese-language reading is ours.

Point	Earlier wording	Later wording
When it started	24 Sept notice on X: security systems "detected" unauthorized transfers at 18:31 UTC.	Bitget's later timeline: first transfers at 18:31, discrepancy detected at 19:05, 34 minutes on. THN and the livestream say the first two transfers were very small.
How sure	Explainer: "may have exploited", "potentially", "appears to have", a "preliminary investigation".	Incident page, last updated 29 Sept: "has confirmed the full attack chain", "exploited a zero-day". Neither page publishes evidence.
One product or several	Explainer and incident page: "a vulnerability in a third-party security product".	CEO recap: "vulnerabilities from third-party products". The translated livestream says vulnerabilities, products and vendors, all plural.
Fixed or not	"Remediated" on 25 and 26 Sept and in the 28 Sept recap; the incident page FAQ says the vulnerabilities "have been patched".	The same recap: vendor notified, functionality disabled "pending a fix" (the explainer says "pending completion of a fix"). Whether the vendor has issued one is not stated.
When the report comes	24 Sept: "within 24 hours" (X). 25 Sept: "once confirmed".	28 Sept: "within a week" (livestream, as translated) or "this week" (THN). 29 Sept: "soon".
How firm the attribution	25 Sept, English post: "consistent with techniques used by" DPRK-linked groups. The Chinese-language post, 40 seconds later, reads in our translation "highly consistent".	28 Sept: the indicators are "still being assessed" (Chen to Cointelegraph). The explainer says Bitget "will not speculate on attribution".

None of these is a contradiction on its own. Together they show an account whose certainty has outrun its published evidence. The explainer treats the entry point as a preliminary finding. The incident page treats the full chain as confirmed. Both were live on Bitget's site on the morning of 29 September, neither publishes technical detail, and the formal report that would is the one thing still outstanding.

The approval path has two halves, and the 28 September account says one was never asked

One difference between the two accounts is not wording. On 25 September the attacker "triggered our authorization process". On the incident page the forged commands were written directly into the wallet system and bypassed the risk verification that runs "before withdrawal records were generated". Those are two controls. The diagram in our earlier briefing marked the authorisation step as triggered, not bypassed. That reading holds for the signing side. It covered only half of the approval path: on Bitget's wording the risk check was not fooled, it was skipped.

Bitget's timeline says the risk system automatically blocked withdrawal requests across the platform at 19:05 UTC. The livestream, as translated by ChainCatcher, says a first phase of 17 large transfers worth about $360 million ran from 18:58 to 20:09 UTC, and a second phase of seven transfers worth about $28 million ran from 20:55 to 21:23 UTC. Arkham's independent post-mortem puts the whole drain between 18:31 and 21:23 UTC. The two phases sum to about $388 million, which is the headline figure within rounding, and the second phase is 7.2 per cent of it. Bitget shut down its signing services at 21:44 UTC: 2 hours 39 minutes after detection and 21 minutes after the last transfer either source reports.

It is an inference, and Bitget does not say it, that a block on user requests would not have stopped forged writes entering below the step it acts on. If that holds, the loss curve is the evidence for the mechanism, and the lesson is not about security products at all. A control on the request path does not bind a writer who enters below it.

A third-party security product is a label, not a control

Every phrase in Bitget's new account is comfortable, and comfortable is not the same as informative. "Third-party" says the fault was elsewhere. "Security product" says the thing was on the defenders' side. "Zero-day" says nobody could have known. "Remediated" says it is over.

Labels in Bitget's account and what each does and does not tell a reader. Sources: Bitget explainer and incident page; THN, 28 September, for the zero-day definition; ChainCatcher's translation of the livestream.

The label	What it tells you	What it does not
Third-party	The flaw was in software Bitget did not write.	That the exposure sat outside Bitget's control. Bitget chose the product, deployed it and gave it standing access, and its own remedial list covers third-party product deployment and assessment.
Security product	A tool bought to defend.	That it is a small attack surface. Defensive tools often hold privileged access to what they guard, so a flaw can hand that access on. Here the stolen credentials were described as high-privilege and were read as normal logins.
Zero-day	The maker had no fix when it was exploited, as THN defines the term.	How severe it is, how widely it is exploited, or that a CVE exists. Nor whether it is unpatched today.
Remediated, patched	Bitget acted.	That a fix exists. Bitget's own words are that it disabled functionality pending one.
Supply chain (incident page FAQ)	Suggests the vendor's build or update was compromised.	That it was. The mechanism described is exploitation of a vulnerability in a product Bitget runs. No source says the vendor was breached.
Confirmed the full attack chain	A finished investigation.	Any published evidence. The independent report, with Mandiant and SlowMist, is still to come.

Bitget's own list of fixes concedes part of the point. It says it is strengthening "controls around third-party product deployment, internal access, withdrawal verification and abnormal-activity monitoring", and in the livestream, as translated, its chief executive said that although there were flaws in the third-party products, "as a trading platform, we also have responsibilities". That is a fair thing to say. It also means that the third-party label describes where the bug lived and not where the risk decision was made.

Separate the method from the accusation. This account comes from Bitget alone. THN's 28 September report says so: "This account of the attack comes from Bitget." A vendor flaw and a state-linked actor are both outside an exchange's own control, the exchange has said its Protection Fund covers the loss, and its chief executive said, in the livestream as translated, that whether to hold the vendor accountable, and how, was for its legal team. The post that carried the root cause also launched fee rewards for retail and professional users. None of that says the account is wrong. It is the reason an account is not a finding. No vendor statement, advisory or CVE appeared in any source we read, and we found no independent confirmation of the product, the flaw or the sequence.

The figure that moved is the one Bitget explained

The loss figure moved from $351.6 million to $387.5 million and settled at about $388 million. The first gap is 35.9 million dollars, 10.2 per cent of the first figure, and Bitget explained it in the same post that carried the new number: the revised figure adds assets on Zcash and TRON "that were not included in the initial estimate" and "does not reflect further unauthorized transfers". The two figures were 16 hours 33 minutes apart, on different UTC days. By the analyst window and the translated livestream the last transfer had left by 21:23 UTC, seven minutes before the first notice went out, so the first figure was incomplete accounting of money already gone rather than a snapshot of a drain in progress. That reading is inference. It fits Bitget's stated reason.

Loss figures for the Bitget incident as published, with source, time in UTC and Bitget's stated reason. Arithmetic is ours and labelled derived.

Figure	Where and when	Bitget's reason, and what is not stated
$351.6 million	X notice 24 Sept 21:30 UTC; support centre 21:39. "Approximately", an "estimated" figure.	An initial estimate. Seven chains named in the CEO's 25 Sept posts.
$387.5 million	@bitget on X 25 Sept 14:03 UTC; update article 14:05.	"A more complete accounting", adding Zcash and TRON assets "not included in the initial estimate". Not further transfers.
About $388 million	Explainer (27 to 28 Sept); incident page 29 Sept, headed "final verified figures", 12 wallet addresses.	Within 0.13 per cent of 387.5 (derived). Eleven blockchains and 13 assets are now listed. The explainer says it may still be updated.
About $390.06 million	THN, in an update to its 25 Sept article, attributed to a Bitget post on X.	Not found in any Bitget source we read, which give 387.5 that day. Treat as unverified.

Two things are still open. Per-asset amounts: Bitget's pages list the assets, never the sums. The breakdown that circulated, from Arkham through The Register, is XRP $153 million, ETH $66.2 million, USDT $34.8 million, USDC $12.9 million and Tether Gold $12.8 million. That is $279.7 million against an analyst total of about $350 million at the time, and TRM Labs put the XRP leg nearer $158 million. These are analysts' early numbers, not Bitget's. Recovery: Bitget says some assets were frozen and will report a total only after verifying it. The only figure in circulation is $339,100 of stablecoins frozen by Circle and Tether, taken by THN on 25 September from a dashboard published by CoinDesk. That is 0.09 per cent of $388 million (derived). Asked about recovering 30 per cent, Bitget's head of Greater China said, as translated, that the company was "not that optimistic".

The Protection Fund arithmetic, which depends on which loss figure is used, is in the earlier briefing and is not repeated.

The attribution is a suspicion from the victim, and the analysts answer a different question

Bitget's wording on who was behind it has a range. The English post of 25 September says the attack is "consistent with techniques used by" DPRK-linked groups. TRM Labs and Elliptic, reporting the chief executive's remarks, quote "very likely" and "likely a North Korean group". On 28 September, according to Cointelegraph, Chen said what was shared earlier was "based on preliminary indicators" that were "still being assessed", and The Block reports she said it was "still the same group of people that we suspect". Bitget's own explainer says it will not speculate on attribution. Those are several phrasings of one suspicion, none of them a finding.

The analysts are independent of Bitget's intrusion evidence but not entirely of its statement. Elliptic assesses the theft as highly likely to be DPRK-linked, on infrastructure overlap in the laundering, the laundering method, and off-chain indicators "as indicated by Chen", and it notes the exchange's own technical basis has not been published. TRM says it has "not definitively attributed" the theft, that the overlaps with earlier North Korea-attributed laundering point to the group it calls TraderTraitor, and that another actor "remains technically possible". Laundering overlap says who handled the money afterwards. It does not say who got in. And an entry point that is a flaw in a security product is consistent with many actors.

What the record fixes and what it leaves open

What Bitget has stated and what it has not, as of 29 September 2026, from its X posts, support centre articles, explainer and incident page.

Question	Fixed on the record	Not stated
Which product or vendor	A third-party security product; vendor notified.	Any name. No vendor statement or advisory found.
Whether a CVE exists	Called a zero-day.	Any identifier. A zero-day may not have one yet.
Whether it is fixed	Affected functionality disabled; "remediated" and, on one page, "patched".	Whether the vendor has released a fix.
How credentials were obtained	By exploiting the flaw; used as normal logins.	The technical steps, and how long the attacker was inside before 18:31 UTC.
Whether the two accounts conflict	No. Layered: the 25 Sept post reserved the method.	Whether authorisation triggered and risk verification bypassed are one control or two.
Loss per asset	The asset list; about $388 million; 12 wallet addresses.	Any per-asset amount from Bitget.
Recovery	Some assets frozen.	Any total, frozen or recovered.
Who did it	A suspicion; indicators "still being assessed".	The indicators, or any named actor.
When the report arrives	Promised: 24 hours, then once confirmed, then within a week.	A date.

What to do if a security tool of yours holds the keys to something

Nothing here depends on knowing the product. The account that has been given, if it holds, describes a general failure: a privileged defensive tool was the way in, its credentials looked normal, and the controls sat where the attacker did not need to go. The list below is in the order worth doing.

The question this leaves

Bitget has said a great deal and shown very little. It has given times to the minute, a chain of steps, the word zero-day, and a promise of a report. It has not named the product, the vendor or the flaw, and its own pages and posts differ on whether the flaw is one or several and whether it is patched or merely switched off. None of that means the account is false. It means the account cannot yet be checked by anyone outside the company, and it is being repeated as if it had been.

The reader's version of the problem is simpler and closer to home. Somewhere in your estate is a tool that exists to protect a system and holds keys to it. If that tool were the way in, and the intruder logged in as an administrator would, which of your controls would still be standing, and which would simply never have run?