From Ledger to Bitget: What Are the Overlooked 'Trust Blind Spots' in Crypto Security?

Beyond private keys, risks may also flow through device circulation, third-party services, and internal permissions, ultimately affecting user assets.

Written by: imToken

A hardware wallet with an intact factory chip, genuine firmware, and even passing the official Genuine Check can still have its assets stolen by hackers?

The recent Ledger security incident has exposed this seemingly impossible risk.

According to the investigation results disclosed by the Ledger security team, attackers implanted a malicious circuit inside the affected device, capable of intercepting the mnemonic phrases displayed on the screen and sending them to the attackers via mobile networks.

In other words, while the factory security chip was not compromised, the mnemonic phrase could have fallen into the hands of hackers the moment it was displayed on the screen for the first time.

Moreover, this is not the only recent security incident worth noting.

Since September, there have been a series of events reminding us that as Crypto products become increasingly complex, security is no longer just about protecting private keys and avoiding smart contract vulnerabilities.

The risks hidden in device circulation, third-party services, internal permissions, and user communications can also become the breakthrough points sought by attackers.

I. The New Alarm for 'Supply Chain Security' Sounded by Ledger

Let’s break down Ledger’s recent encounter.

When buying hardware wallets, people usually worry about two things: getting counterfeit products or receiving a device that has been pre-initialized by someone else.

In the past, the most common scam involved malicious intermediaries generating mnemonic phrases, printing them on scratch cards, and putting them back in the packaging, betting that novice users would not understand the rules and would directly deposit money.

Although this scam is dangerous, the defense logic is clear—find legitimate channels, check the device status, and ensure the device generates a new mnemonic phrase by itself, never using the one provided in the packaging.

However, the attack on Ledger has clearly escalated; hackers inserted an electronic module with a microcontroller, eSIM, and cellular communication capabilities inside the shell. When users first initialize the wallet, they must read the mnemonic phrase from the screen and write it down.

In other words, the implanted malicious circuit does not interfere with the mnemonic phrase generation process; it merely monitors the mnemonic phrase and transmits it directly. This is why the fact that “the private key was not directly extracted from the security chip” does not mean that the wallet recovery information is still safe.

What’s more troublesome is that even if the device passes the official Genuine Check, it may not be able to identify this additional hardware installation, as the genuine verification primarily confirms the identity of the security chip and the trustworthiness of the firmware.

Thus, this incident indeed exposes a serious “supply chain risk” that is often overlooked: the security of hardware wallets depends not only on the chip and firmware but also on the entire delivery process from the factory to the user.

After all, a device may need to pass through regional distributors, third-party warehouses, logistics, and retailers. Any participant who has actual contact with the device may become a risk point that requires additional assessment.

II. From Trezor to Bitget: How Attackers Bypass Core Security Defenses?

Understanding Ledger’s issue, we can look at the recent security incidents involving Bitget and Trezor and find that the underlying logic is surprisingly similar: attackers also bypassed the most robust front-line defenses and instead infiltrated through “third-party services.”

Let’s first look at Trezor.

In early September, some Trezor users received an email with the subject “Critical Security Alert: STM32 Entropy Vulnerability,” claiming that the hardware wallet had a serious security vulnerability that required immediate action.

Such emails can easily make users anxious, as no one wants their assets to be compromised due to hardware wallet security vulnerabilities.

This is precisely what attackers exploited by using the third-party email marketing platform Brevo that Trezor utilized, allowing malicious content to reach users’ inboxes through normal email sending infrastructure.

According to Brevo’s subsequent incident report, attackers exploited a flaw in its single sign-on system’s permission boundaries to gain unauthorized access to other customer accounts, ultimately affecting 138 customer accounts, some of which were used to send phishing emails or export contact data.

Trezor later confirmed that 347,149 marketing email contact addresses were exported in the incident, and the phishing emails attempted to lure users into downloading malicious applications and entering wallet backup information.

It is important to note that there is no evidence that Trezor’s hardware wallet or private key protection system was compromised; the attackers first obtained user information and abused the official communication channels.

However, for ordinary users who received the email, identifying the risk becomes more difficult because the email may come from a familiar official domain and can pass normal email authentication checks, yet the content has already been replaced with phishing information by the attackers.

If users actively fill in their mnemonic phrases as a result, what was originally just a third-party email service issue could further evolve into real asset loss.

Now let’s look at Bitget.

On September 24, unauthorized asset transfers occurred in some of Bitget’s hot and warm wallets, ultimately verifying an involvement of approximately $388 million.

According to the investigation results published by Bitget, attackers exploited a vulnerability in a third-party security product to obtain high-privilege credentials within the exchange, subsequently infiltrating the backend systems related to wallets, fabricating withdrawal instructions, and bypassing existing risk control checks, allowing abnormal transfers to enter the normal execution process.

Bitget stated that no private key leakage was found in this incident, and cold wallets were not affected, which sounds somewhat contradictory: if the private key was not stolen, why could the money still be transferred?

This is actually easy to understand.

For custodial platforms like exchanges, when users initiate a withdrawal, it is not always done by manually signing each transaction with a private key; instead, it requires a complete internal process involving account verification, risk control review, transaction generation, and wallet signing.

This is akin to a bank vault. Even if the vault key is kept very strictly, if someone can impersonate an internal high-privilege identity and fabricate an approved transfer instruction, the funds in the vault may still be incorrectly transferred out.

What Bitget exposed this time is how risks can further propagate to the asset execution system after upstream permissions and instruction checks fail, so “the private key was not leaked” and “funds will not be illegally transferred” are actually two different things.

As for the infrastructure security incident disclosed by MetaMask at the end of September, it presented another dimension of operational risk.

At that time, MetaMask took preventive measures by proactively withdrawing from some affected staking validators. According to the official investigation update on October 1, no signs of impact on MetaMask wallets or customer funds were found, and related staking operations do not replace customer management of withdrawal keys.

However, this does not mean that problems with infrastructure will not have other impacts. Non-custodial solutions primarily address asset control issues but do not automatically eliminate operational risks from external infrastructure.

Looking at these incidents together, the connections are actually very clear:

• Ledger exposes the physical tampering risk in hardware circulation, which may ultimately lead to the theft of mnemonic phrases;
• Trezor / Brevo exposes the risk of user information leakage and abuse of official communication channels, which does not mean that the wallet itself was compromised;
• Bitget exposes the risk of third-party product vulnerabilities propagating to internal high-privilege systems, which can directly affect fund execution;
• MetaMask reminds us that asset control and service operational risks are not the same concept.

Overall, today’s Crypto products are no longer isolated islands.

Wallets rely on external RPC nodes to read on-chain data, aggregate interfaces to pull market data; exchanges depend on external security monitoring, KYC verification, and risk control components; extending further, there are node operators, cloud vendors, customer service tickets, and email systems like Brevo.

These external services make products run more efficiently and improve user experience, but at the same time, each new external dependency introduces an additional layer of trust management:

What can third parties access, what permissions do they have, and if they fail, will the risks propagate to other core systems?

III. How Should Products and Users Defend?

Faced with increasingly complex risks from third-party dependencies and interlinked relationships, it is clearly unrealistic to expect product teams to revert to a primitive state of “not relying on any external services,” nor does it align with market rules.

The real test of security architecture is to minimize every possible risk exposure.

For example, why should a SaaS service provider that only sends marketing emails retain the contact data of all users long-term? Why can third-party security monitoring tools access core production environments without independent multi-level authorization? Especially concerning sensitive actions involving fund transfers, there must be strict permission isolation and independent cross-verification between internal systems, and “default trust” should never be allowed.

This is also what is commonly referred to in security architecture as “least privilege” and “separation of duties”: the email platform should only have the permissions necessary to send emails, security monitoring tools should not be allowed to execute fund transfers arbitrarily, and a large withdrawal should not be approved solely based on instructions from a single internal system.

The Ledger incident further reminds hardware wallet manufacturers that security management may even need to extend to the physical circulation of products.

From factory, storage, logistics to distributor delivery, how to establish traceable management processes, how to detect abnormal disassembly or replacement of devices, and how to locate affected batches and users after issues arise should not be regarded as mere channel management work.

Because for a hardware device that protects private keys, the delivery process itself is part of the security system.

Of course, for ordinary users, we cannot audit the software supply chain of wallets, nor can we investigate every storage and logistics link of hardware wallets one by one.

But this does not mean we can only passively bear risks; at least there are several things worth cultivating as habits in daily use.

First, try to minimize unnecessary transfers during the hardware wallet purchase process.

If conditions permit, prioritize ordering from the brand’s official website, with direct shipping from the factory or official warehouse, which usually reduces the chances of the device being accessed, disassembled, or swapped by third parties after leaving the factory’s control.

From a risk management perspective, the more independent entities that come into contact with the device, the more trust layers that need to be managed; additionally, upon receiving the device, check for packaging and appearance anomalies, use official software for verification, and strictly follow the initialization process.

Second, it is necessary to reassess whether 'official messages' are trustworthy.

The Trezor incident has already shown that even if emails are indeed sent through the official service platform, it does not mean that the links and operation requests within are necessarily safe.

Especially concerning sensitive operations such as wallet upgrades, account freezes, asset migrations, and vulnerability fixes, it is best not to click on links directly in the messages but to verify through the official website address saved by oneself or the already installed official app.

For non-custodial wallets like imToken, users also need to recognize official channels, download and install based on token.im, and when encountering abnormal information, prioritize verification through official entry points like “Help and Feedback” within the app.

Regardless of whether the other party claims to be official customer service, security team, or provides what seems to be very professional vulnerability explanations, users should never disclose their mnemonic phrases or private keys to them.

Finally, it is essential to distinguish the actual impact of different security incidents on oneself.

Email address leakage mainly means that one may face more targeted phishing in the future; clicking suspicious links requires further confirmation of whether malicious programs have been downloaded or run; if mnemonic phrases have already been entered, one should immediately treat it as a leakage of wallet control.

If suspicious transactions or authorizations have been signed, it is necessary to assess whether there are ongoing contract authorization risks based on specific on-chain operations.

As for third-party service failures or infrastructure anomalies, it is even more necessary to refer to the official disclosure of the impact scope to determine whether it involves one’s assets, service availability, or earnings.

One should not automatically assume that “wallet security incidents” mean that private keys have been compromised, nor should one hastily transfer assets to unfamiliar addresses due to so-called urgent security notifications.

After all, many times, what attackers truly expect is not to breach the most robust technical defenses but to induce users to complete the final step in panic.

Final Thoughts

In the past, a common phrase emphasized in the Crypto industry was “Not your keys, not your coins.”

This phrase remains important because the control of private keys determines whether users can truly master their assets.

However, as wallets, exchanges, and on-chain financial products gradually mature, we also need to realize that private key protection is only one part of the entire security system.

A truly secure hardware wallet may still be physically tampered with during the delivery process; a notification genuinely coming from the official email system may also be exploited by attackers; and a third-party tool originally intended to enhance security may even become an entry point to core funding systems.

These cases do not mean we should lose trust in all wallets and external services; on the contrary, they remind the entire industry that security needs to extend beyond individual products to encompass the entire process of supply chain, permission management, user communication, and emergency response.

After all, a truly mature Crypto security system must not only ensure that private keys are not easily leaked but also guarantee that even if an external link encounters issues, the entire mechanism can still effectively contain risks along the way, preventing them from crossing the final threshold of user assets.