What happened
At 18:31 UTC on 24 September 2026, Bitget detected unauthorised transfers from part of its hot and warm wallet infrastructure. Bitget currently estimates the affected funds at US$387.5 million; cold wallets were reported unaffected and private-key compromise was not observed. Withdrawals were suspended while deposits and trading continued, and restoration was subsequently staged by asset and network.
On 30 September 2026, Bitget published preliminary reports from Mandiant and SlowMist that materially changed the incident from an unexplained wallet theft into a third-party security-appliance compromise. Mandiant reported unauthorised privileged access to third-party security appliances A and B, a web shell on appliance B, a command-and-control connection, lateral movement to the production wallet job server and malicious package deployment.
SlowMist reported the earliest malicious activity in available logs on 31 August 2026, when a hidden script read an environment variable containing a database password. The published reports did not identify the appliance vendors, product names, CVE identifiers, web-shell filename, hashes, domains or command-and-control address. That omission prevents customers from mapping the attack directly to their own product inventories or detection platforms.
Bitget published attacker-controlled addresses: EVM 0x770b10b273fc44fe9197d6bf20f145c2e98463ee, XRP rwNhefsz1UQEusxhCvHip3RANinWi4CTck, ZEC t1WgMdtND8NF7NDUuYmq8MpMj1NTCXkMDVG and TRON TBWNguTTgezw9dVorX441C6nDrZpRxYwKD. Attribution posture: Mandiant’s published status report names no actor, so responsibility remains unresolved in this briefing. The cited source did not publish the specific indicators described as Security-appliance and malware identifiers.
Why this matters now
The material change is not the previously disclosed theft alone. The new reports place two third-party security appliances inside the attack path, with privileged access, a web shell, command-and-control and lateral movement into a production wallet server. Security products with trusted network placement can become privileged bridges rather than protective barriers.
The incident demonstrates why third-party assurance cannot stop at a supplier questionnaire or a patched-vulnerability statement. Enterprises need to understand appliance management access, embedded credentials, database reach, software-update trust, outbound connectivity and the ability to isolate a security control without disabling the protected business process.
Financial institutions, payment platforms, exchanges and any organisation running automated value-transfer or signing workflows should test whether fraudulent commands can be inserted alongside legitimate operations. Controls that validate infrastructure identity but not transaction intent can preserve availability while still processing attacker-generated actions.
The decision for security leaders
Treat security appliances as privileged production systems. Require the same identity isolation, egress controls, evidence retention, change governance and compromise monitoring applied to domain controllers, cloud control planes and signing infrastructure.
Commission an architecture review of transaction intent. Confirm that withdrawal, payment or signing systems independently validate destination, amount, authorisation context and risk signals rather than trusting commands solely because they originate from approved infrastructure.
Use the report’s unnamed-product limitation as an assurance trigger. Suppliers with comparable privileged placement should state whether their products are implicated, what telemetry proves that conclusion and which residual uncertainties remain.
Evidence of closure
- Architecture record identifies every security appliance with privileged production reach.
- Credential-rotation evidence covers all secrets accessible from equivalent appliances.
- Supplier assurance names affected products and documents residual uncertainty.
- Transaction-control tests reject unauthorised destination, amount and command-context changes.
The Security.io assessment
The new forensic reports justify inclusion because they replace a generic external-hack narrative with a concrete third-party control-path failure. That shifts the enterprise lesson from cryptocurrency custody alone to the wider governance of trusted security appliances connected to production systems.
The reports remain preliminary. The affected products, zero-day identifiers, web-shell artefacts and command-and-control infrastructure are unpublished, and Mandiant’s document says its investigation is ongoing. Assertions about other customers, affected vendors or broader exploitation would therefore be premature.
Bitget’s staged restoration and protection-fund statements address customer continuity, but they do not close the supplier-control question. Evidence-based closure requires named products, remediated access paths, rotated credentials, validated transaction controls and a documented finding on whether equivalent appliances remain trusted.
Questions for the morning meeting
- Which security appliances have persistent access to production transaction systems?
- Can each appliance’s credentials and lateral paths be independently revoked?
- What evidence supports every third-party product’s current assurance status?