Last week, a security researcher disclosed a shocking case: a wallet update on December 24th contained a backdoor code, leading to the leakage of user privacy data (including seed phrases), resulting in user losses exceeding $2 million.

At first glance, this incident seems fresh, but upon closer reflection, it actually reflects an old problem of wallet products—users have no real control over security boundaries.

**Where is the real risk in plugin wallets**

Many people tend to blame users when discussing such incidents: "Did they import the seed phrase? Did they operate carelessly?" But from a product design perspective, the problem isn't there. The key risk lies in the automatic update mechanism itself.

There is an unavoidable reality with plugin wallets:

Every automatic update essentially grants full authorization over your entire assets.

As long as the code in the update package is tampered with—possibly due to internal issues, but more commonly through supply chain attacks (compromising CI/CD pipelines, build environments, or distribution channels)—malicious logic can execute without the user noticing. And users are completely unaware.

Even more painfully: this risk isn't limited to hot wallets. Even if you just use plugins to connect hardware wallets, the risk remains. Because the plugin controls:

- The transaction details you see
- The recipient address you confirm
- All information displayed before and after signing

Hardware wallets can guarantee that "private keys never leave the chip," but they can't guarantee that you're signing the transaction you think you are. If a plugin is malicious, it can make you sign one thing, but the chain executes another.

**Why has this become a systemic issue**

The root of the problem lies in centralized update permissions. Once users install a plugin, they entrust the security entirely to the development team. The team might be reliable, but if any part of their infrastructure—such as release processes, employee computers, or build environments—is compromised, it can lead to large-scale asset losses.

And the user side is completely passive—you can't see what has been updated or refuse a specific update version.

This is why the entire Web3 community is beginning to reevaluate wallet architecture design. Some projects are exploring key separation-based, user-verifiable update mechanisms, or even local-first architectures—the goal is to give users actual control over the security of their assets, rather than blindly trusting.