Cryptocurrency exchange Bitget has disclosed that attackers who drained approximately $387.5 million from its systems last week gained entry by exploiting an unknown vulnerability in third-party security software the exchange had deployed internally.
According to BleepingComputer's reporting, the breach did not stem from a flaw in Bitget's own core systems. Instead, the intruders reportedly leveraged a zero-day in security products supplied by a third-party vendor — software that typically sits in privileged positions inside enterprise networks, with broad access to endpoints and sensitive data by design.
Bitget said it will publish a more detailed technical post-mortem as the investigation continues. As of the exchange's disclosure, BleepingComputer has not identified the affected vendor or product.
How the intrusion reportedly unfolded
The attack surface here is not a conventional bug in a trading platform. Security tooling is deployed across an organisation to inspect traffic, manage endpoints, and monitor for threats, which means the software holds a level of trust — and access — that most other third-party components never see. A zero-day in such a product can be a shortcut past perimeter defences that were never designed to question the tools meant to enforce them.
Bitget's reported loss is large enough to force the incident into the open, but the exchange's case is best read as one instance of a much wider exposure: when a trusted security layer is compromised, the failure is systemic rather than confined to one vendor relationship.
Why security tools are an under-scrutinised attack surface
Third-party risk programmes tend to focus on vendors that touch customer data or provide business-critical services. Security products themselves often receive less scrutiny, because they are assumed to be protective by default — an assumption that is increasingly difficult to justify.
Supply-chain intrusions have repeatedly shown that software deployed widely inside enterprise environments, from build tools to monitoring agents to security agents themselves, can become an effective route into otherwise well-defended networks. In Bitget's case, the entry point was the very category of software most organisations rely on to detect intrusions. An uncompromised security vendor and a trusted security vendor are not the same thing, and trust decisions made when a product was adopted may no longer hold once the vendor's own security posture has been questioned by an attacker.
What remains unknown
Not yet confirmed: whether user funds were affected, whether withdrawals were frozen, or how long attackers had access before detection. Because the vendor and product remain unnamed, any other deployment of the affected software is potentially exposed with no public advisory to act on — a risk that cannot be quantified until Bitget or the vendor discloses more.
What security teams should consider now
Several practical steps follow from this incident, and they are not specific to cryptocurrency firms:
- Re-examine privileged vendor software. Inventory security agents, management consoles, and monitoring tools that hold elevated access, and treat them as part of your trust boundary rather than outside it.
- Demand transparency from security vendors. Ask about patching timelines, disclosure practices, and how quickly customers are notified when a flaw is found in the vendor's own product.
- Segment what security tools can reach. If a security agent can access everything, an attacker who compromises it can reach everything too.
- Monitor patch status actively. The window between disclosure and remediation is where exposure concentrates; waiting for routine cycles is not sufficient for privileged components.
Bitget's commitment to publish further technical detail will be worth watching. The specifics of how the zero-day was exploited, and whether the vendor has since released a fix, will shape how other organisations reassess their own exposure. Until that post-mortem lands, and until the affected product is publicly identified and patched, the full extent of the risk to other deployments remains unknown.
Editor's note: The third-party security product involved in this breach has not been publicly identified in BleepingComputer's reporting at the time of publication. Patch status for the affected software is unconfirmed. This article will be updated as the vendor, product, and remediation details become available. The $387.5 million figure reflects Bitget's disclosure and has not been independently verified here.
加密貨幣交易所 Bitget 透露，上週有入侵者從其系統中提取約 3.875 億美元，而入侵者是利用該交易所內部部署的第三方保安軟件中的未知漏洞，取得系統存取權限。
根據 BleepingComputer 的報道，這次入侵並非源於 Bitget 自身核心系統的缺陷。相反，入侵者據報利用了第三方供應商提供的保安產品中的零日漏洞——這類軟件通常在企業網絡中佔有特權位置，按設計即可廣泛存取端點及敏感數據。
Bitget 表示，隨着調查持續，將會發布更詳細的技術事後檢討報告。在交易所作出披露時，BleepingComputer 尚未確認涉事供應商或產品的名稱。
事件據報的入侵經過
這裡的攻擊面並非交易平台的常見漏洞。保安工具遍布組織，用於檢查流量、管理端點及監控威脅，因此這類軟件擁有大部分其他第三方元件無法企及的信任及存取權限。此類產品中的零日漏洞，可以繞過原本並非用來質疑保安工具本身的邊界防禦。
Bitget 報告的損失規模足以迫使事件曝光，但該交易所的個案最好視為更大規模風險的一個例子：當受信任的保安層被攻破，失敗是系統性的，而非局限於單一供應商關係。
為何保安工具是未受充分審視的攻擊面
第三方風險管理計劃往往聚焦於接觸客戶數據或提供關鍵業務服務的供應商。保安產品本身常被忽略審視，因為它們被預設為具保護作用——但這一假設已越來越難以成立。
供應鏈入侵一再顯示，廣泛部署於企業環境的軟件，從編譯工具、監控代理程式到保安代理程式本身，都可以成為進入原本防禦森嚴網絡的有效途徑。在 Bitget 個案中，入侵點正是大多數組織用來偵測入侵的軟件類別。未被攻破的保安供應商與受信任的保安供應商並非同一回事，產品採用時作出的信任決定，未必能在供應商自身的保安狀況被入侵者質疑後仍然成立。
目前尚不清楚的事項
尚未確認的事項包括：用戶資金是否受影響、提現是否被凍結，以及入侵者在被偵測前獲得存取權限的時間長度。由於涉事供應商及產品均未具名，其他任何部署相同軟件的環境都可能面臨風險，卻沒有公開公告可供採取行動——在 Bitget 或供應商披露更多資料前，風險規模無法量化。
保安團隊現階段應注意的事項
從這次事件衍生出若干實際步驟，而且並不局限於加密貨幣公司：
- 重新審視具特權的供應商軟件。 盤點持有高權限的保安代理程式、管理控制台及監控工具，將其視為信任邊界的一部分，而非外部範圍。
- 要求保安供應商提高透明度。 查詢修補時間表、漏洞披露流程，以及供應商自身產品出現漏洞時通知客戶的速度。
- 分隔保安工具可觸及的範圍。 若保安代理程式可存取所有內容，入侵者一旦攻破它，同樣可以觸及所有內容。
- 主動監控修補狀態。 披露與補救之間的窗口正是風險最集中的時刻；對具特權的元件而言，等待例行更新周期並不足夠。
Bitget 承諾發布更多技術細節，值得持續關注。零日漏洞的具體利用方式，以及供應商是否已發布修補程式，將影響其他組織如何重新評估自身風險。在事後檢討報告出爐、涉事產品被公開指明並完成修補前，其他部署所面臨的完整風險仍屬未知。
編按：BleepingComputer 的報道在本刊出版時尚未公開指涉事件中的第三方保安產品。相關軟件的修補狀態未經確認。待涉事供應商、產品及補救細節公開後，本文將會更新。3.875 億美元的數字反映 Bitget 的披露，本刊未能獨立核實。