On 24 September 2026 at 18:31 UTC, unauthorised transfers began leaving Bitget’s hot and warm wallets. By 19:05 the exchange’s reconciliation system had flagged the discrepancy and blocked withdrawals; by 21:44 withdrawal services were shut down entirely. In the 2 hours and 52 minutes between the first transfer and the last, approximately $388 million moved across 12 wallet addresses (Bitget official incident page, updated 30 Sep 2026). The detection, once money moved, was fast — 34 minutes from first transfer to automated flag. That is not where this case went wrong.

Where it went wrong was 25 days earlier. On 31 August 2026, SlowMist observed the earliest malicious activity of the campaign on a node belonging to a third-party product it names only as “Product A.” A zero-day in a service running on that node let the attacker execute a hidden script under the service process, run a command to read an environment variable containing a database password, and connect to the database (SlowMist progress report via Incrypted, 30 Sep 2026). Similar hidden-script activity then appeared on two further Product A nodes, on 23 and 25 September, before any assets moved.

On the morning of 25 September the attacker reached the management platform of a second product, “Product B,” using an internal employee account — and was treated as an administrator. Three command-injection attempts into task parameters followed, then server configuration changes and the download of compiled malicious programs (SlowMist via Incrypted, 30 Sep 2026). Mandiant reported that a web shell was deployed onto security appliance B and a command-and-control connection established, after which the actor moved laterally to Bitget’s production wallet job server and deployed malicious packages (Mandiant via The Hacker News, 1 Oct 2026).

The final step was purpose-built. A bespoke tool, highly tailored to the wallet system’s withdrawal logic, spoofed risk-control parameters, generated withdrawal requests and triggered the corresponding procedure. The attacker also attempted to modify withdrawal records directly in the wallet database (SlowMist via Incrypted, 30 Sep 2026). Bitget’s CEO Gracy Chen described the tradecraft plainly: “Along the way, they used legitimate credentials. They disguised their activity as routine administrative operations while removing traces of their actions” (The Hacker News, 28 Sep 2026).

Neither investigator has named the two products. SlowMist’s own report withholds the identity of Product A and Product B, the attacker’s identity, the definitive initial compromise vector, and how the attacker moved between the involved systems (SlowMist via Incrypted, 30 Sep 2026). There is no CVE, no vendor advisory, and no PSIRT bulletin. That is the part of this case that should worry every organisation running a security appliance: if you are a customer of either product, you cannot tell, and you have not been told.

1. What Happened

1. On 31 August 2026, SlowMist observed the earliest malicious activity linked to the incident on a node of a third-party product designated “Product A,” where a zero-day in a running service allowed execution of a hidden script under the service process (SlowMist progress report via Incrypted, 30 Sep 2026).
2. That script ran a command to read an environment variable containing a database password and then connected to the database (SlowMist via Incrypted, 30 Sep 2026).
3. Similar hidden-script activity was observed on two further Product A nodes on 23 and 25 September 2026, before asset outflows began (SlowMist via Incrypted, 30 Sep 2026).
4. On the morning of 25 September the attacker accessed the management platform of a second product, “Product B,” using an internal employee account, attempted three command injections into task parameters to write malicious files, then modified server configuration and downloaded compiled malicious programs (SlowMist via Incrypted, 30 Sep 2026).
5. Mandiant reported that the threat actor deployed a web shell onto security appliance B, established a command-and-control connection, then moved laterally to Bitget’s production wallet job server and deployed malicious packages (Mandiant via The Hacker News, 1 Oct 2026).
6. A bespoke tool tailored to the wallet system’s withdrawal logic spoofed risk-control parameters and generated fraudulent withdrawal requests; the attacker additionally attempted to modify withdrawal records directly in the wallet database (SlowMist via Incrypted, 30 Sep 2026).
7. Bitget’s own timeline records unauthorised transfers beginning 24 September at 18:31 UTC, detection by its reconciliation system at 19:05, emergency response at 19:14, transfers to cold wallets from 20:40, and withdrawal services shut down at 21:44; root cause was identified 25 September at 08:43 and law enforcement notified at 13:42 (Bitget official incident page, updated 30 Sep 2026).
8. Mandiant found no evidence that private keys were leaked and confirmed cold wallets were unaffected; Bitget states private-key compromise has been ruled out and user account balances remain unaffected (The Crypto Times, 30 Sep 2026; Bitget official incident page, updated 30 Sep 2026).
9. Bitget states it has disabled the affected functionality pending completion of a fix, and is strengthening controls around third-party product deployment, internal access, withdrawal verification and abnormal-activity monitoring (Bitget official incident page, updated 30 Sep 2026).

2. Business Impact

• [CONFIRMED] Approximately $388 million taken from hot and warm wallets across 12 wallet addresses — Bitget’s own current figure (Bitget official incident page, updated 30 Sep 2026). Reporting through the week carried $387.5 million, revised upward from an initial estimate of $351.6 million stated on 26 September (Infosecurity Magazine, 28 Sep 2026).
• [CONFIRMED] The entire on-chain outflow ran 2 hours 52 minutes — first transfer 24 September 18:31 UTC, last 21:23 UTC, with the largest wave of roughly $185 million at 19:16 UTC (SlowMist via The Crypto Times, 30 Sep 2026; window corroborated by Bitget’s own timeline).
• [CONFIRMED] Roughly 25 days elapsed between the earliest observed appliance compromise on 31 August and the theft on 24 September — dwell time entirely inside third-party security products (SlowMist via The Crypto Times, 30 Sep 2026).
• [CONFIRMED] Detection of the theft itself took 34 minutes: first unauthorised transfer 18:31 UTC, reconciliation-system discrepancy flagged and withdrawals blocked 19:05 UTC. The 25 days of preceding appliance activity generated no reported alert (Bitget official incident page, updated 30 Sep 2026).
• [CONFIRMED] Bitget’s User Protection Fund, stated at over $464 million at the time of the incident, covers the loss; user account balances, cold wallets and the separate non-custodial Bitget Wallet product were unaffected (Bitget’s first incident notice via Infosecurity Magazine, 28 Sep 2026; Bitget official incident page, updated 30 Sep 2026).
• [CONFIRMED] Withdrawals were shut down on 24 September at 21:44 UTC and restored in stages: BTC 28 September 08:00 UTC, ETH 29 September, USDT 30 September, all remaining tokens, fiat and P2P 2 October 08:00 UTC — eight days of degraded service (Bitget official incident page, updated 30 Sep 2026; Infosecurity Magazine, 28 Sep 2026).
• [CONFIRMED] Approximately $1.1 million in assets has been frozen by Circle, Tether and NEAR Intents (The Hacker News, 1 Oct 2026).
• [ESTIMATED] Attribution is unresolved and the sources disagree. Bitget’s own page states it “will not speculate on attribution without verified investigative findings” (Bitget official incident page, updated 30 Sep 2026), while reporting states Bitget cited on-chain analysis and IP behaviour patterns indicating North Korean threat actors (The Hacker News, 1 Oct 2026). TRM Labs identified wallet overlaps pointing to the DPRK-linked group TraderTraitor but had not made a firm attribution (The Hacker News, 28 Sep 2026). SlowMist’s report lists attacker identity among its undetermined findings. [UNRESOLVED]
• [ESTIMATED] Exposure of other organisations running the same two products: Scale not publicly disclosed. The products are identified only as “Product A” and “Product B”; no vendor, CVE or advisory has been published, so no other customer can assess its own exposure (SlowMist via Incrypted, 30 Sep 2026). [UNRESOLVED]

3. Likely Root Cause

• A zero-day vulnerability in a service running on a node of a third-party product (“Product A”) permitted execution of a hidden script under the service process.

Source: SlowMist progress report via Incrypted, 30 Sep 2026

• A database password was readable from that service process’s environment variables, converting a single code-execution primitive directly into database access.

Source: SlowMist progress report via Incrypted, 30 Sep 2026

• An internal employee account was accepted by the management platform of a second product (“Product B”) as legitimate administrative access; how that account was compromised is not stated by any source. [UNRESOLVED]

Source: SlowMist progress report via Incrypted, 30 Sep 2026

• The Product B management platform accepted attacker-supplied task parameters to the point where command injection and malicious file writes were attempted, and permitted server configuration changes and download of compiled programs.

Source: SlowMist progress report via Incrypted, 30 Sep 2026

• A security appliance was able to host a web shell and establish an outbound command-and-control connection, then reach the production wallet job server.

Source: Mandiant via The Hacker News, 1 Oct 2026. SlowMist separately states it could not determine how the attacker moved between the involved systems — the lateral path is asserted by Mandiant, not jointly confirmed. [UNRESOLVED]

• Withdrawal risk-control parameters were enforced where the attacker already had control, so a tool tailored to the withdrawal logic could spoof them and generate authorised-looking requests.

Source: SlowMist progress report via Incrypted, 30 Sep 2026; The Hacker News, 1 Oct 2026

• Withdrawal records in the wallet database were directly writable, making the audit trail a target rather than evidence.

Source: SlowMist progress report via Incrypted, 30 Sep 2026

• The appliance estate sat inside the production trust boundary with sufficient network reach to pivot to a wallet job server, and carried no detection coverage that distinguished appliance-resident attacker activity from vendor maintenance.

Assessed from the SlowMist and Mandiant accounts and from Bitget’s own commitment to strengthen controls around third-party product deployment, internal access, withdrawal verification and abnormal-activity monitoring — not stated as a finding by any source.

4. Control Failures

• [CF-1] 🔗 Third Party: Two third-party security products operated inside the production trust boundary with no compensating monitoring and no contractual notification right. The vendors remain unnamed, so neither Bitget’s peers nor any other customer of those products can assess their own exposure.
• [CF-2] ⚙️ Technology: A database password sat in a readable environment variable of an appliance service process, and the appliance was able to establish an outbound C2 channel — so one code-execution bug became database access, and a web shell became a persistent command path.
• [CF-3] 🪪 Identity: An internal employee account was sufficient to administer a security vendor’s management platform, and credentials obtained from the appliance estate were honoured by backend wallet services as high-level internal credentials.
• [CF-4] 📋 Process: Withdrawal risk controls were enforced inside the same system the attacker controlled and their parameters were spoofable; withdrawal records in the wallet database were directly writable, so the integrity evidence was modifiable by the actor it would have incriminated.
• [CF-5] 👥 People: For 25 days across at least three appliance nodes, attacker activity was indistinguishable to the humans watching from routine administrative and vendor-maintenance work, and nothing was escalated until money moved on-chain.

5. Recommendations

5A — Organisational & Technical Controls

Audience: security and IT teams.

↳ CF-1 — Put every security appliance in the ICT asset register as a production asset, and buy a notification clause

DORA Art. 8(1)–(2) and Art. 8(4) (identification and classification of ICT assets and dependencies); DORA Art. 28(1)(a) and Art. 30(2)(a),(f) (ICT third-party policy; contractual provisions on security and provider support); EU CRA Art. 14 tempo used as a procurement term

Classify appliances, their management planes and their service accounts as in-scope ICT assets supporting a critical or important function — not as “security tooling” outside the register. Then mirror the CRA reporting tempo into the contract as a buyer-side right: 24-hour early warning, 72-hour notification, 14-day final report on any actively exploited vulnerability, a named notification recipient on both sides, and an explicit right to technical detail and indicators rather than a severity rating. Require the vendor to state in writing whether the product is CRA in-scope, whether it is CE-marked for cyber, and which CSIRT it reports to. Bitget’s case is the argument: 25 days in, still no vendor name.

↳ CF-2 — Remove static secrets from appliance service environments and default-deny their egress

NIST SP 800-53 Rev. 5 IA-5(7) (no embedded unencrypted static authenticators), SC-7(5) (deny-by-default boundary protection), SC-28; ISO/IEC 27001:2022 Annex A 8.24 (use of cryptography), A 8.9 (configuration management); CIS Controls v8.1 4.8, 12.2

Replace the environment-variable database password with short-lived dynamic credentials brokered at connection time — 15-minute leases, automatic revocation, no static fallback — and remove the static credential rather than rotating it. Audit every appliance for secrets in service environments, unit files, cron entries and configuration backups. Then put the management interfaces behind a default-deny egress policy that allowlists only the vendor’s update and licensing endpoints by FQDN, logs every denied connection, and blocks DNS exfiltration paths: a web shell on an appliance that cannot reach the internet is an inert file.

↳ CF-3 — Phishing-resistant MFA on vendor consoles, and scope appliance credentials so they cannot move money

NIST SP 800-53 Rev. 5 IA-2(1), AC-6(9) (auditing use of privileged functions), AC-2(11); ISO/IEC 27001:2022 Annex A 8.2 (privileged access rights), A 5.17 (authentication information); CIS Controls v8.1 5.4, 6.3, 6.5; DORA Art. 9(4)(c)

Require FIDO2/WebAuthn hardware keys on every third-party management console, with SMS and TOTP fallback removed rather than discouraged, and separate administrative identities from day-to-day accounts so a single staff credential cannot administer a security appliance. Scope the appliance’s own service credentials by capability: a credential held on a monitoring appliance must not be accepted by a wallet service as authorisation to issue a withdrawal command. Review every backend service that trusts a credential class rather than a specific principal, and set a maximum four-hour just-in-time window for any standing appliance administrative role.

↳ CF-4 — Move withdrawal risk enforcement outside the wallet host and make the records append-only

MiCA Reg. (EU) 2023/1114 Art. 75 (safekeeping of clients’ crypto-assets and funds) and Art. 68 (systems and security access protocols); DORA Art. 9(4)(d); NIST SP 800-53 Rev. 5 AU-9 (protection of audit information), AU-10 (non-repudiation); ISO/IEC 27001:2022 Annex A 8.15 (logging), A 8.16 (monitoring), A 5.28 (collection of evidence)

Enforce withdrawal limits and risk parameters on an independent approval service the wallet job server can call but cannot read, write or reconfigure, with the parameter set signed at a separate trust root and verified on every evaluation — so spoofing the parameters requires compromising two systems, not one. Require dual authorisation above a defined threshold, with the second approver on a different authentication path. Make withdrawal records append-only, either write-once storage or cryptographic chaining with periodic published checkpoints, and replicate them to a host the production wallet environment cannot write to, so an attempt to alter them is an alert rather than a successful cover-up. Deliver the user-facing rules below (5B) as a standing briefing.

↳ CF-5 — Alert on appliance behaviour, not on what the appliance chooses to tell you

NIST SP 800-53 Rev. 5 SI-4(4) (inbound and outbound communications traffic), AU-6 (audit review, analysis and reporting), SI-4(2); ISO/IEC 27001:2022 Annex A 8.16 (monitoring activities), A 8.15 (logging); CIS Controls v8.1 8.2, 8.5, 8.11, 13.1, 13.3; DORA Art. 10(1)–(2) (detection mechanisms and multiple layers of control)

Ship appliance syslog, authentication events and process-execution telemetry off the appliance into the SIEM, and write detections for the specific behaviours in this case: a new child process under an appliance service account, a process reading its own environment block, an outbound connection initiated from a management interface, a configuration write outside a change window, and any administrative login to a vendor console from an unexpected network. Treat an appliance’s own health dashboard as an untrusted source — it was green throughout. Then measure and report mean time to detect for the appliance estate as a separate metric from the production estate, because this case shows the two numbers were 25 days and 34 minutes.

6. Regulatory Relevance

MiCA — Regulation (EU) 2023/1114

Art. 68 (systems and security access protocols); Art. 75 (safekeeping of clients’ crypto-assets and funds)

This, not DORA on its own, is the operative regime for an EU crypto-asset service provider in Bitget’s position. It is directly live for this case rather than hypothetical: Bitget EU filed an application for authorisation as a crypto-asset service provider with Austria’s Financial Market Authority on 17 June 2026, and that application remains under review and unapproved (Bitget EU MiCAR notice, official; crypto.news, 17 Jun 2026). An incident of this shape lands while an authorisation decision is in train, and Art. 75 safekeeping obligations and Art. 68 systems-and-access requirements are precisely what a supervisor assesses. [KB UPDATE NEEDED] MiCA — Regulation (EU) 2023/1114 on markets in crypto-assets; scope covers crypto-asset service providers, issuers of asset-referenced tokens and e-money tokens offering services in the EU; relevant to custody and safekeeping of client assets, operational resilience, systems and security access protocols, and complaints handling. Not currently in regulations-reference.md. Article numbers carried from secondary analysis — confirm against the OJ text before relying on them in a client deliverable.

DORA — Regulation (EU) 2022/2554

Art. 2(1)(s) (scope gate: crypto-asset service providers authorised under MiCA are financial entities); then Art. 8(1)–(2),(4) (ICT asset identification), Art. 9(4)(c)–(d) (access management and cryptographic controls), Art. 10(1)–(2) (detection), Art. 17–18 (incident management and classification), Art. 19(1),(4) (initial, intermediate and final reporting), Art. 28(1)(a), Art. 29 (concentration risk), Art. 30(2)(a),(f) (contractual provisions)

Cited conditionally and deliberately, not by default. DORA does not apply to Bitget as it stands — it is not an authorised EU financial entity. The scope gate is Art. 2(1)(s): once a CASP is authorised under MiCA it becomes a DORA financial entity, and the whole ICT risk, incident-reporting and third-party regime attaches on top of MiCA rather than instead of it. For any SEG client that is already an authorised CASP or a financial entity running an appliance estate like this one, Art. 28–30 is the clause set that turns “the vendor will not tell us what happened” from a frustration into a documented contractual deficiency. Art. 2(1)(s) carried from secondary legal analysis — confirm against the OJ text.

EU Cyber Resilience Act — Regulation (EU) 2024/2847

Art. 14 (reporting of actively exploited vulnerabilities: 24-hour early warning, 72-hour notification, 14-day final report, via the CRA Single Reporting Platform to the CSIRT of the manufacturer’s main establishment with simultaneous availability to ENISA); Annex I Part II §1–2 (vulnerability handling and coordinated disclosure policy) and §8 (security updates disseminated without delay and free of charge)

The sharpest and most uncomfortable mapping in this case, and it points at the vendor rather than the victim. CRA reporting obligations have been live since 11 September 2026. If either Product A or Product B is placed on the EU market, the Product A zero-day was actively exploited on 23 and 25 September — after that date — and the Art. 14 clock applies to its manufacturer. Two material caveats, stated rather than buried: the products are unnamed, so whether either is EU-market in scope is unverifiable [UNRESOLVED]; and per regulations-reference.md §0, the Art. 14 article number is carried from secondary sources and the substance, dates and mechanics are confirmed against the European Commission’s reporting page while the number itself awaits OJ-text confirmation. Penalties for breach of the reporting duty reach €15 million or 2.5% of worldwide annual turnover.

ISO/IEC 27001:2022

Annex A 5.19–5.22 (information security in supplier relationships, addressing security within supplier agreements, managing ICT supply chain, monitoring and review of supplier services); A 8.24 (use of cryptography); A 8.15 (logging); A 8.16 (monitoring activities); A 8.9 (configuration management); A 5.28 (collection of evidence); A 8.2 (privileged access rights)

The intersection worth flagging: A 5.22 requires regular monitoring and review of supplier service delivery, and A 8.16 requires monitoring of networks, systems and applications for anomalous behaviour. Read together they describe exactly the control that was absent — a supplier’s product, inside the trust boundary, monitored by nobody. A 5.28 is engaged independently by the attempt to modify withdrawal records: evidence integrity is a control objective, not a by-product of logging.

CIS Controls v8.1

Safeguards 4.8 (uninstall or disable unnecessary services), 5.4 (restrict administrator privileges to dedicated accounts), 6.3 and 6.5 (MFA for externally-exposed and administrative access), 8.2, 8.5 and 8.11 (collect, standardise and review audit logs), 12.2 (secure network architecture), 13.1 and 13.3 (centralised security event alerting and network intrusion detection)

Safeguards 8.2, 8.5 and 8.11 and 6.3 sit in Implementation Group 1 — the baseline expected of every organisation regardless of size or sector. A 25-day dwell time inside appliance nodes with no alerting is therefore not a capability gap at an under-resourced entity; at an exchange of this scale it is an ownership gap, and the IG1 designation is the sharpest way to say so to a board.

Deliberately not applied — and why

• GDPR — excluded. No source states that personal data was accessed; Bitget states user account balances were unaffected and private-key compromise ruled out, and no breach notification or data-subject impact has been reported. Citing Art. 32 or Art. 33 here would be speculation dressed as mapping. Reassess if Bitget or a supervisory authority discloses personal-data impact.
• NIS2 — excluded on the entity side. A crypto-asset service provider is not an independently listed NIS2 sector, and for financial entities DORA operates as the sector-specific regime. NIS2 may reach the two unnamed product vendors as ICT service management providers, but with the vendors unidentified that mapping cannot be made honestly.
• EU AI Act, ISO/IEC 42001, NIST AI RMF — excluded. There is no AI system in this case, on either side. Per regulations-reference.md §1.4, the AI Act reaches providers and deployers, not attackers, and this attack involved neither.
• PCI DSS — excluded. No cardholder data is in scope.
• SOX §404 ITGC and SEC cybersecurity disclosure rules — excluded. Bitget is not a US-listed registrant, so neither the ICFR nor the Form 8-K four-business-day obligation attaches, notwithstanding that the attempted modification of withdrawal records is textbook audit-trail-integrity territory.
• CISA BOD 22-01 / KEV — not applicable. No CVE has been published for either product, so there is no KEV entry and no due date to benchmark against. Per regulations-reference.md §3.16, BOD 22-01 binds only US federal civilian agencies and must never be described as a legal obligation for a European entity.

7. How SEG Can Help

↳ CF-1 — 💡 Third-Party Risk Assessment

SEG inventories the security and management products inside your production trust boundary — the category most third-party risk programmes skip because the vendor is itself a security vendor — and rewrites the contractual terms that failed here: CRA-mirrored 24h/72h/14-day notification rights, a named recipient, an enforceable right to technical detail and indicators, and a stated patch SLA. We assess the appliance estate’s blast radius, not just the vendor’s questionnaire answers.

↳ CF-2 / CF-3 — 💡 SaaS Configuration Review

SEG audits appliance and management-plane configuration for the two specific defects in this case: static secrets readable from service environments, unit files, cron entries and configuration backups; and management interfaces with unrestricted outbound network access. We verify phishing-resistant MFA is actually enforced on every vendor console with fallback paths removed, and that appliance-held service credentials cannot authorise business transactions.

↳ CF-4 — 💡 vCISO

SEG designs the segregation this case lacked: risk enforcement on a service the production host cannot reconfigure, signed parameter sets, dual authorisation above threshold, and append-only transaction records replicated beyond the reach of the production environment. For clients that are authorised CASPs or financial entities, we map the resulting control set to MiCA Art. 68 and Art. 75 and to DORA Art. 9 and Art. 28–30 so the design is defensible to a supervisor, not just to an auditor.

↳ CF-5 — 💡 Penetration Testing

SEG tests the path this attacker took, in order: code execution on an appliance service, secrets recovery from its process environment, outbound C2 establishment from a management interface, and lateral movement from the appliance estate into a production application tier. We then confirm whether each step generated a usable detection — because the finding that matters is not that the path exists, it is that 25 days of it produced no alert.

↳ CF-5 — 💡 Security Awareness Training

SEG delivers the 5B rules above as a standing briefing for everyone holding a supplier console login, built around the behaviours that would have shortened this intrusion: refusing an unprompted sign-in approval, never leaving a credential where software can read it, and escalating administrative activity that looks routine but is not. The 5B block in this edition is a ready-to-forward one-pager for your staff.

📖 Sources

• Bitget — Bitget Security Incident: What Happened, Timeline, Impact and Response (official) — Updated September 30, 2026
• The Hacker News — Bitget Confirms Third-Party Zero-Day Behind $387.5 Million Cryptocurrency Theft (Mandiant and SlowMist findings) — October 1, 2026
• Incrypted — SlowMist Revealed Details of the Attack on Bitget’s Hot Wallets (SlowMist progress report) — September 30, 2026
• The Crypto Times — Bitget $387.5M Hack: SlowMist and Mandiant Say Zero-Day Attack Began Weeks Before Theft — September 30, 2026
• The Hacker News — Bitget Says Attacker Exploited Third-Party Security Product Flaw to Steal $388M (Gracy Chen statements; TRM Labs) — September 28, 2026
• Infosecurity Magazine — Bitget Restarts Bitcoin Withdrawals Following $387.5m Wallet Breach — September 28, 2026
• Bitget — Bitget EU MiCAR authorisation application notice (official) — Retrieved October 4, 2026
• news — Bitget EU files MiCAR application with Austria’s FMA — June 17, 2026