Bitget Says Stolen Credentials Turned a Security Tool Flaw Into a $388 Million Wallet Breach

Cryptocurrency exchange Bitget says an attacker exploited a zero-day vulnerability in an unnamed third-party security product, gaining privileged access to internal systems and stealing approximately $388 million.

The intrusion did not rely on compromised wallet private keys, according to the exchange’s investigation so far. Instead, the attacker allegedly obtained high-level internal credentials and used Bitget’s legitimate administrative processes to submit fraudulent withdrawal instructions.

Funds were taken from parts of the exchange’s hot and warm wallet infrastructure. Offline cold wallets were not affected.

Stolen credentials opened the path to wallet services

Bitget CEO Gracy Chen described the third-party product vulnerability as a zero-day, meaning the exchange had no vendor-provided fix available when the attacker used it. Bitget has not identified the product, its developer, or the affected versions.

That lack of disclosure leaves several technical questions unanswered. It is not known what type of vulnerability was exploited, whether authentication was bypassed, or how the flaw exposed Bitget’s privileged credentials.

No CVE identifier has been announced. Consequently, there is also no confirmed information about the vulnerability’s status in the US Cybersecurity and Infrastructure Security Agency’s Known Exploited Vulnerabilities catalog.

The exploit reportedly provided access to an internal management system and high-level credentials. Those credentials then allowed the intruder to reach backend services involved in wallet transactions.

Bitget had previously said that a critical component in its wallet backend was compromised and manipulated to generate false transaction data and initiate approvals. The latest account explains the initial entry point: a vulnerability in software supplied by an outside security vendor.

However, the attacker still needed to navigate Bitget’s transaction workflow. Transfers required approval before signing, so access to a single wallet component was not necessarily enough to move funds.

Small test transfers preceded the main theft

The fraudulent withdrawals began on September 24. Rather than attempting an immediate large transfer, the attacker first tested the process with two small transactions at 18:31 UTC.

Both transfers remained below Bitget’s risk-control threshold and generated no alert. Larger withdrawals started roughly 30 minutes later.

Using valid internal credentials was central to the attack. The wallet-related backend accepted the withdrawal commands as legitimate and sent them into the normal approval process. Chen said the activity was constructed to look like routine administrative work, reducing the likelihood that automated controls or employees would recognize it as malicious.

The attacker also attempted to erase traces of the operation. The extent of that cleanup, and whether investigators have recovered the deleted evidence, is not known.

This attack path helps explain why wallet safeguards did not stop the transfers. The adversary did not have to forge an external login or directly steal cryptographic keys. Instead, the intruder operated through trusted internal identities and submitted commands in a format that Bitget’s systems expected to receive.

Controls based mainly on transaction size, credential validity, or superficially normal administrative behavior can struggle with that scenario. The first two transfers tested whether those controls would intervene before the attacker committed to moving larger amounts.

Hot and warm wallets absorbed the loss

The stolen assets came from portions of Bitget’s hot and warm wallets, which are more accessible than offline storage because they support operational liquidity and withdrawals.

Bitget says its cold wallets were not affected. The company also says it has found no evidence that wallet private keys were compromised, although the investigation remains underway.

That distinction matters for the scope of the incident. A stolen private key could allow an attacker to sign transactions independently of the exchange’s internal systems. In this case, the reported attack depended on access to Bitget’s backend infrastructure and its approval mechanisms.

The exchange says customer account balances remain intact. Its Protection Fund, a reserve intended to absorb security-related losses, will cover the missing assets.

Users are not being asked to reset credentials, move funds, or complete any other remediation step. There is currently no indication that individual customer accounts were the point of entry.

Bitcoin withdrawals reopened Monday. Withdrawals for other assets are scheduled to return in stages through October 2.

Systems isolated while the vendor works on the flaw

Bitget notified the unnamed product vendor and disabled the affected functionality. It has not said whether the supplier has produced a patch or other permanent fix.

Without the product name, version information, or vulnerability identifier, other organizations cannot determine whether they use the same affected technology. They also cannot independently verify whether an update is available.

Bitget has isolated the systems involved in the incident, revoked internal credentials, and issued replacements. It has also narrowed internal access, introduced independent checks for withdrawals, and increased monitoring for anomalous activity.

The exchange plans to reassess how it selects, evaluates, and deploys third-party security products. The incident illustrates a difficult supply-chain risk: software installed to protect sensitive infrastructure may itself become an avenue into that environment.

Independent withdrawal validation could reduce the risk from one compromised management layer, particularly if the second check uses separate credentials, telemetry, and trust boundaries. Bitget has not disclosed the architecture of its new controls.

Mandiant and SlowMist are assisting with the investigation. Bitget expects to release a formal incident report this week, which may clarify the exploited component, the credential access mechanism, and the sequence of approvals.

North Korean attribution remains unconfirmed

Bitget previously said North Korean hackers were likely responsible. Chen told The Hacker News that the exchange continues to suspect the same actor, but she declined to name a specific group before publication of the incident report.

TRM Labs identified overlaps between the stolen assets and wallets previously used to launder funds from North Korean thefts. The blockchain intelligence company said the activity pointed toward TraderTraitor, but it did not make a definitive attribution.

Transaction overlap alone does not establish who conducted the intrusion. Shared laundering infrastructure, intermediary services, and address reuse can support an assessment, but they do not necessarily prove that the same operators performed the original compromise.

The movement of funds through bridges and cross-chain swap services further complicates tracing. These services can change both the network and asset involved, making simple monitoring of direct transfers insufficient.

Recipient addresses and indirect exposure to monitor

Bitget published recipient addresses on September 25, along with a live tracking dashboard and a recovery portal. It asked exchanges, custodians, stablecoin issuers, bridges, and other infrastructure operators to flag related activity.

The disclosed addresses are:

• Ethereum and EVM networks: 0x770b10b273fc44fe9197d6bf20f145c2e98463ee
• XRP: rwNhefsz1UQEusxhCvHip3RANinWi4CTck
• Zcash: t1WgMdtND8NF7NDUuYmq8MpMj1NTCXkMDVG
• TRON: TBWNguTTgezw9dVorX441C6nDrZpRxYwKD

TRM advised cryptocurrency businesses not to limit screening to deposits sent directly from these addresses. Investigators expect stolen funds to arrive through multiple intermediary wallets after being routed across networks.

Compliance teams should therefore monitor tagged downstream addresses and indirect exposure, especially following bridge or cross-chain swap activity. A deposit several transactions removed from the original theft may be more likely than a direct transfer from a publicly identified recipient address.

For other potential users of the vulnerable security product, there is no product-specific action available yet. The vendor’s identity, affected releases, patch status, and technical indicators have not been disclosed.