东八区时间本周内，安全公司慢雾的CISO 23pds 披露了一起发生在 Linux Snap Store 上的新型供应链攻击事件：攻击者并未正面突破钱包程序本身，而是悄悄接管了开发者的过期域名，通过被用户高度信任的 官方更新通道 下发恶意版本。对普通用户而言，这些更新看起来与往常无异，却在后台悄然盯上了他们的加密资产。尤其是 Exodus、Ledger Live、Trust Wallet 等知名钱包被伪装成“安全更新”的入口，让“只装官方商店软件就安全”的传统认知，与用户的资产安全，在这一刻发生了激烈碰撞。

过期域名复活：攻击者如何反向接管更新链路

在这起事件中，攻击者并没有一开始就从代码入手，而是选择了周期更长、却往往被忽视的域名这一环节。钱包开发团队在项目运行多年后，若在域名到期续费上出现疏忽，就会留下一个短暂却致命的空窗期。攻击者会长期监控这些与 Snap 包维护者身份 绑定的开发者域名，一旦发现到期而无人续费，便立即完成抢注。相比于传统意义上的“撞库”或漏洞利用，这种方式更像是耐心守株待兔，等待维护者犯一个看似微小的运营错误。

当攻击者成功抢注域名后，真正危险的部分才刚刚开始。因为在许多生态里，开发者身份验证、更新配置以及发布管线，往往与特定域名深度绑定。域名一旦被第三方控制，对方就有机会重置或接管开发者在相关服务中的身份，将与该身份绑定的 Snap 包及其更新元数据 纳入自己的掌控。这样，攻击者可以在不惊动用户的情况下，调整更新配置、替换软件包内容，让原本应由官方维护者管理的更新链路，转而为恶意代码服务。

这种“域名复活”的玩法，本质是一种 信任链劫持。它并非利用某个单点的技术漏洞，而是将矛头对准了开发者日常维护中最容易被淡化的环节：域名寿命管理与身份绑定关系。一旦开发者对域名续费、密钥轮换、包维护人变更等问题掉以轻心，就给了攻击者将长期信任资产一锅端走的机会。表面上看，是一个过期域名被陌生人抢走；本质上，则是背后整条更新信任链被悄悄改写。

从官方商店下手：信任通道变成攻击入口

相比来路不明的安装包，大部分用户对操作系统 官方应用商店 和自动更新机制，有着接近“无条件”的信任。这正是此次攻击让人不寒而栗的地方。恶意版本并不是通过外挂脚本或钓鱼网站分发，而是沿着原本的官方渠道下发给用户。攻击者接管开发者身份后，可以继续沿用或伪造原有的发布配置，让更新过程在用户看来一切正常：系统提示有新版本，点击更新，下载、安装、启动，没有任何异常弹窗或证书告警。

在慢雾披露的事件中，被伪装的目标包括 Exodus、Ledger Live、Trust Wallet 等多款知名钱包。这些名字本身就代表着一定的品牌信任度，而当它们又出现在 Snap Store 这样被视为“比第三方来源更安全”的官方商店里时，用户几乎不会产生怀疑。更新界面通常只显示版本号或简短变更说明，很少有人会去逐字审查，更不会想到背后发布者身份可能已经被掉包。在这种双重信任的叠加之下，“安全更新”反而成为恶意代码的完美伪装。

这一切让传统的安全习惯显得苍白无力。许多用户一直坚信，只要 不装未知来源软件、只从官方仓库安装 就足够安全；而此次事件展示的是，当供应链本身被渗透时，安全与否已经不再取决于下载来源的“官方标签”，而是取决于这条官方链路背后的身份体系是否还可信。官方商店的品牌信用，被攻击者当成了社工工具，用户多年来建立的安全直觉，在供应链攻击面前失灵。

杀毒全线失灵：助记词被悄悄送走

更让人难以防范的是，恶意代码并非以粗糙明显的方式打包进应用，而是隐藏在看似正常的钱包功能逻辑中。与那些会大幅修改界面、弹出奇怪窗口的木马不同，这类恶意版本会尽可能维持与原版相同的交互体验与界面布局，只在关键的助记词输入、私钥导入等环节悄悄插入一段额外逻辑。对于依赖特征库的静态查杀或简单的特征扫描来说，只要攻击者避免使用已知恶意代码片段，传统杀毒产品就很难在第一时间给出明确的拦截判断。

在供应链层面，恶意版本还能通过原有或伪装的签名验证与正常更新流程，顺利通过多数安全审计。系统看到的是一个“来自受信任源的已签名更新”，缺乏进一步验证机制的审核流程很容易放行。很多自动化合规检查只关注签名是否有效、发布源是否列入信任清单，却没有针对功能层面的异常行为给出持续监控，这使得攻击者可以利用“签名即安全”的思维惯性，钻过制度的空隙。

对终端用户而言，风险场景则更具冲击力：在一次再普通不过的钱包初始化过程中，用户照着提示，在窗口中输入助记词、设置密码、确认地址，一切都在熟悉的流程里完成。但在代码内部，这些原本只应该保留在本地的敏感信息，正被恶意逻辑复制、打包，并在后台通过网络悄然发出。用户看到的是同步完成、余额正常显示，对方看到的则是一串可以随时用来“接管资产”的种子。整个过程没有红色感叹号，没有系统弹窗，有的只是一次看似毫无疑问的版本更新。

慢雾预警之后：Linux信仰与安全神话的坍塌

在事件曝光后，慢雾CISO 23pds 明确提醒，“Linux用户需警惕通过官方渠道分发的恶意更新”。这句话击中了许多技术用户的心理预期：长期以来，Linux 社区习惯将自己视为比普通桌面系统更安全的一极，认为开源代码透明、官方仓库集中管理，可以天然抵御大部分恶意软件威胁。此次 Snap Store 供应链被利用的案例，却告诉大家，开源与官方仓库提供的是 可审计性，而非自动生效的安全保障。

“开源更安全”的说法，在理想状态下成立：代码公开意味着任何人都可以审查、复现与验证。但在现实中，真正有能力、有动力深度审计复杂应用的安全团队并不多，日常更新节奏又极快，导致大量变更很难做到逐行审查。即便 Snap 这样集中化的应用商店能一定程度上统一分发渠道，却并不能阻止开发者身份被域名劫持、更新通道被篡改。一旦信任锚点出现裂缝，所谓“官方仓库等于安全”的逻辑就会崩塌。

对 Linux 生态而言，这起事件带来的冲击不仅指向单个钱包，而是指向整套 开发者信誉与包维护责任 体系。开发者需要为自己的域名、密钥、发布管线建立更严格的生命周期管理，不能再把这些视为“运维小事”；平台方也必须重新审视对“受信任出版者”的审计标准与持续验证机制；用户则不得不面对一个现实：即使在开源世界，信任也不再是一次性授予，而是需要持续验证的关系。过去那种“安装前看一眼来源，然后永久放心使用”的模式，在供应链攻击不断进化的当下已经站不住脚。

加密资产用户如何自救与重建信任

对加密资产用户而言，这起 Snap 供应链攻击是一次被动的安全教育。尤其是那些在 Linux 环境下使用桌面钱包的用户，需要迅速调整安全习惯。在安装或更新钱包时，除了依赖 Snap Store 这类官方渠道，更要主动增加几道人工核验工序，例如：交叉比对项目官网与仓库中公布的最新版本信息，确认指向的包名、维护者账号与发布渠道是否一致；对于涉及助记词导入的关键版本，尽量查找是否已有安全社区、审计团队或知名钱包项目给出针对性提醒，而不是在系统提示更新后立刻无脑点击。

钱包开发团队同样需要将防御重心前移，把 域名、签名与发布渠道 视为产品安全的一部分，而不是附属基础设施。具体而言，一是要对与身份绑定的关键域名设置更严格的续费与监控策略，避免出现“到期无人知”的空档；二是建立系统化的密钥轮换与权限分级机制，降低单点泄露或被接管的风险；三是与平台方协作，为 Snap 等分发渠道引入更多元的发布者验证与异常行为监控，而非仅仅依赖一次性身份认证。

从更长远的角度看，随着供应链攻击的常态化，加密应用的分发与信任体系也必然面临重构。一方面，去中心化的校验机制——例如多源哈希对比、社区自动化构建与复现验证——有望在热门项目中变得更加普及；另一方面，更细粒度的权限控制与沙箱隔离，将成为桌面钱包等高敏感应用的标配，减少单个恶意更新对整机和资产造成的破坏范围。未来，单一平台的“官方标签”不再足以成为安全背书，用户、开发者与安全社区之间，将需要建立一套更为复杂但也更稳固的多方信任网络，在不再可靠的旧神话坍塌之后，重新搭起保护资产的防线。

加入我们的社区，一起来讨论，一起变得更强吧！
官方电报（Telegram）社群：https://t.me/aicoincn
AiCoin中文推特：https://x.com/AiCoinzh

OKX 福利群：https://aicoin.com/link/chat?cid=l61eM4owQ
币安福利群：https://aicoin.com/link/chat?cid=ynr7d1P6Z

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