This week, the CISO of the security company Slow Mist, 23pds, disclosed a new type of supply chain attack that occurred on the Linux Snap Store: the attackers did not directly breach the wallet application itself but quietly took over the developer's expired domain name, distributing malicious versions through the highly trusted official update channel. For ordinary users, these updates appeared to be no different from usual, yet in the background, they quietly targeted their crypto assets. Notably, well-known wallets like Exodus, Ledger Live, and Trust Wallet were disguised as "security updates," leading to a fierce collision between the traditional belief that "installing software from the official store is safe" and the security of users' assets.

Reviving Expired Domains: How Attackers Reverse Takeover the Update Chain

In this incident, the attackers did not start with the code but chose the often-overlooked domain name aspect, which has a longer cycle. If the wallet development team neglects to renew the domain after years of project operation, it leaves a brief but fatal window of opportunity. Attackers monitor these developer domain names tied to Snap package maintainers for a long time, and once they find an expired domain that has not been renewed, they immediately register it. Compared to traditional "credential stuffing" or exploiting vulnerabilities, this method is more like patiently waiting for the maintainer to make a seemingly minor operational mistake.

Once the attackers successfully register the domain, the real danger begins. In many ecosystems, developer identity verification, update configuration, and release pipelines are often deeply tied to specific domain names. Once a domain is controlled by a third party, they have the opportunity to reset or take over the developer's identity in related services, bringing the Snap packages and their update metadata under their control. This way, attackers can adjust update configurations and replace package contents without alerting users, turning the update chain that should be managed by official maintainers to serve malicious code.

This "domain revival" tactic is essentially a form of trust chain hijacking. It does not exploit a single technical vulnerability but targets the aspect of developer maintenance that is most easily overlooked: domain lifecycle management and identity binding. Once developers become careless about domain renewals, key rotations, and package maintainer changes, they give attackers the opportunity to take away long-trusted assets. On the surface, it appears as if an expired domain has been taken by a stranger; fundamentally, the entire update trust chain behind it has been quietly rewritten.

Targeting the Official Store: Trust Channels Turned Attack Vectors

Compared to unknown installation packages, most users have an almost "unconditional" trust in the operating system's official application stores and automatic update mechanisms. This is precisely what makes this attack chilling. The malicious version was not distributed through external scripts or phishing websites but was delivered to users through the original official channels. After taking over the developer's identity, attackers can continue to use or forge the original release configuration, making the update process appear normal to users: the system prompts that a new version is available, users click to update, download, install, and launch without any abnormal pop-ups or certificate warnings.

In the incident disclosed by Slow Mist, the disguised targets included well-known wallets like Exodus, Ledger Live, and Trust Wallet. These names themselves represent a certain level of brand trust, and when they appear in the Snap Store, which is considered "safer than third-party sources," users are unlikely to suspect anything. The update interface usually only displays version numbers or brief change notes, and few people will scrutinize them word by word, let alone consider that the identity of the publisher behind it may have been swapped. Under this double layer of trust, "security updates" instead become the perfect disguise for malicious code.

All of this renders traditional security habits ineffective. Many users have long believed that as long as they do not install software from unknown sources and only install from official repositories, they are safe enough; however, this incident demonstrates that when the supply chain itself is infiltrated, safety no longer depends on the "official label" of the download source but on whether the identity system behind this official chain is still trustworthy. The brand credit of the official store has been turned into a social engineering tool by attackers, and the security intuition that users have built over the years fails in the face of supply chain attacks.

Antivirus Solutions Fail: Mnemonics Quietly Sent Away

What is even harder to defend against is that the malicious code is not packaged into the application in a crude and obvious way but is hidden within seemingly normal wallet functionality. Unlike those trojans that significantly alter the interface or pop up strange windows, these malicious versions maintain the same interaction experience and interface layout as the original as much as possible, only quietly inserting additional logic during critical steps like mnemonic input and private key import. For static detection relying on signature databases or simple feature scans, as long as attackers avoid using known malicious code snippets, traditional antivirus products find it challenging to provide clear interception judgments in real-time.

At the supply chain level, malicious versions can also pass through most security audits by using original or forged signature verification and normal update processes. The system sees a "signed update from a trusted source," and the lack of further verification mechanisms in the review process makes it easy to pass. Many automated compliance checks only focus on whether the signature is valid and whether the release source is on the trust list, without providing continuous monitoring for abnormal behavior at the functional level, allowing attackers to exploit the inertia of the "signature equals safety" mindset to slip through the gaps in the system.

For end users, the risk scenario is even more impactful: during a seemingly ordinary wallet initialization process, users follow the prompts, input their mnemonics, set passwords, and confirm addresses, completing everything within a familiar process. However, internally, this sensitive information, which should only be retained locally, is being copied and packaged by malicious logic and quietly sent out over the network in the background. Users see a completed sync and normal balance display, while the attackers see a seed that can be used at any time to "take over assets." The entire process has no red exclamation marks, no system pop-ups, only a seemingly unquestionable version update.

After Slow Mist's Warning: The Collapse of Linux Faith and Security Myths

After the incident was exposed, Slow Mist's CISO 23pds clearly warned, "Linux users need to be vigilant about malicious updates distributed through official channels." This statement struck at the psychological expectations of many technical users: for a long time, the Linux community has considered itself to be a more secure alternative to ordinary desktop systems, believing that open-source code transparency and centralized management of official repositories can naturally fend off most malware threats. However, this case of the Snap Store supply chain being exploited tells everyone that open source and official repositories provide auditability, not automatic security guarantees.

The claim that "open source is safer" holds true in an ideal state: public code means anyone can review, reproduce, and verify it. However, in reality, there are not many security teams capable and motivated to conduct in-depth audits of complex applications, and the rapid pace of daily updates makes it difficult to review large numbers of changes line by line. Even if centralized application stores like Snap can somewhat unify distribution channels, they cannot prevent developer identities from being hijacked or update channels from being tampered with. Once cracks appear in the trust anchor, the logic that "official repositories equal safety" collapses.

For the Linux ecosystem, the impact of this incident points not only to a single wallet but to the entire developer reputation and package maintenance responsibility system. Developers need to establish stricter lifecycle management for their domain names, keys, and release pipelines, no longer viewing these as "minor operational matters"; platform providers must also reassess their audit standards and continuous verification mechanisms for "trusted publishers"; users must face a reality: even in the open-source world, trust is no longer a one-time grant but a relationship that requires continuous verification. The past model of "checking the source before installation and then using it with peace of mind" can no longer stand in the face of evolving supply chain attacks.

How Crypto Asset Users Can Self-Rescue and Rebuild Trust

For crypto asset users, this Snap supply chain attack serves as a passive security education. Especially for those using desktop wallets in a Linux environment, there is a need to quickly adjust security habits. When installing or updating wallets, in addition to relying on official channels like the Snap Store, users should actively add several manual verification steps, such as: cross-referencing the latest version information published on the project's official website and repository to confirm that the package name, maintainer account, and release channel are consistent; for key versions involving mnemonic imports, it is advisable to check whether there are targeted alerts from security communities, audit teams, or well-known wallet projects, rather than mindlessly clicking after the system prompts an update.

Wallet development teams also need to shift their defensive focus forward, viewing domain names, signatures, and release channels as part of product security rather than as ancillary infrastructure. Specifically, they should set stricter renewal and monitoring policies for key domain names tied to identities to avoid gaps where "expiration goes unnoticed"; establish systematic key rotation and permission tiering mechanisms to reduce the risk of single-point leaks or takeovers; and collaborate with platform providers to introduce more diverse publisher verification and abnormal behavior monitoring for distribution channels like Snap, rather than relying solely on one-time identity authentication.

From a longer-term perspective, as supply chain attacks become normalized, the distribution and trust systems of crypto applications will inevitably face reconstruction. On one hand, decentralized verification mechanisms—such as multi-source hash comparisons, community automated builds, and reproduction verification—are expected to become more prevalent in popular projects; on the other hand, finer-grained permission controls and sandbox isolation will become standard for high-sensitivity applications like desktop wallets, reducing the damage range of a single malicious update on the entire machine and assets. In the future, a single platform's "official label" will no longer suffice as a security endorsement; a more complex yet robust multi-party trust network will need to be established between users, developers, and the security community, rebuilding the protective line for assets after the collapse of unreliable old myths.

Join our community to discuss and become stronger together!
Official Telegram community: https://t.me/aicoincn
AiCoin Chinese Twitter: https://x.com/AiCoinzh

OKX Benefits Group: https://aicoin.com/link/chat?cid=l61eM4owQ
Binance Benefits Group: https://aicoin.com/link/chat?cid=ynr7d1P6Z

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。