11月2日，一款名为“SKR Claim”的第三方应用短暂闯入了Solana dApp Store的最核心信任入口。它并非按正常流程上架，而是通过未经授权访问Solana dApp Publishing Portal被提交并通过审核阈值，随即出现在用户几乎每天都会点开的界面上。更危险的是，攻击者不仅把这款应用推上了App Spotlight推荐位，还同步篡改了Quests任务界面，把“SKR Claim”直接嵌进任务入口，让它在商店内部看起来像一款被官方背书的活动工具。在这段不到一小时的曝光窗口里，应用界面诱导用户输入助记词，把本应只存在于冷钱包和密钥管理器里的最高权限交给一个来历不明的程序。据公开信息，Solana Mobile在发现异常后迅速将该应用从dApp Store下架，并通过X平台确认和披露事件，同时宣布正从已经安装“SKR Claim”的设备中主动移除这一应用，以阻断这次源自内部入口被攻破的高危钓鱼路径。
一小时窗口：恶意应用攻占推荐位
故事从一个看似普通的发布动作开始。攻击者在未经授权的情况下打通了通往 Solana dApp Publishing Portal 的内部通道，绕过本该阻拦陌生开发者的门槛，把“SKR Claim”以正常应用的身份提交进了 Solana dApp Store。上线只是第一步，更关键的是入口的改写：同一批未授权操作继续伸向 App Spotlight 推荐区域和 Quests 任务界面，恶意应用被推到用户日常最常点击的显著位置，仿佛它从一开始就属于这个生态的“官方精选”。
据公开信息，“SKR Claim”在这些推荐位上停留的时间大约为一小时。在这段窗口期里，任何习惯信任官方商店陈列、从 Spotlight 和任务入口直接下载安装的用户，都可能在没有心理防备的情况下被暴露在索要助记词的高危诱导面前。11 月 2 日，Solana Mobile 确认发现异常后启动紧急移除流程，一方面将应用从 dApp Store 下架，另一方面通过 X 平台对外披露事件，提醒用户警惕任何索要助记词的应用，并尝试把这一个小时被攻破的推荐位重新拉回到它应有的安全边界之内。
信任入口反被利用：官方商店成钓鱼场
传统的链上钓鱼，大多发生在“链外”：陌生链接、仿冒网站、假推文，用户至少还能依靠域名、UI 细节去判断是否点击。但这一次，“SKR Claim”并不是从某个可疑外链闯入，而是沿着 Solana dApp Store 的官方分发链路，堂而皇之出现在用户手机里，这是把攻击面直接搬进了本应被视为安全的“内圈”。据 Solana Mobile 披露，攻击者在未经授权访问 dApp Publishing Portal 后，进一步篡改了 App Spotlight 推荐区域和 Quests 任务界面，把这款恶意应用塞进最显眼的位置，让它获得了原本只留给官方可信内容的曝光与背书。
Spotlight 推荐位本质上是“编辑精选”，在多数用户心中意味着已经被官方筛过一遍，是可以降低警惕直接点开的入口；Quests 则是引导用户完成特定交互的任务面板，用户习惯于在这里跟随指引一步步操作。当这两个高度可信的界面同时出现“输入助记词以完成任务/领取权益”的提示时，很多人不再把它视作风险动作，而是视作流程的一部分。然而，助记词是钱包的总钥匙，一旦在恶意应用中输入，就等于把整个钱包的控制权直接交到攻击者手里，而不是仅仅签署一笔可追溯、可撤销的链上交易。这种从官方商店入口发起的索要助记词行为，把原本相对边缘的钓鱼场景，升级为对“可信入口”本身的颠覆测试，暴露出用户对界面背后权力结构认识的薄弱。
发布权限失守：推荐位与任务界面被篡改
据单一来源显示，这次事件的关键，并不只是有一个恶意应用被提交到商店，而是同一个未经授权的入口，既能把“SKR Claim”推送进 dApp Publishing Portal，也能直接改写 App Spotlight 推荐区和 Quests 任务界面。换句话说，一旦发布门户被攻破，攻击者就不仅获得了“上架权”，还拿到了“陈列权”与“运营权”，可以在首页推荐位和任务入口同时安放自己的钓鱼应用。这种多功能入口在制度层面暴露出明显安全缺口：应用提交流程、推荐位配置和任务系统运营，似乎都被捆绑在同一套权限下，只要这套权限被绕过，整个商店前台就会被一并劫持。
从设计角度看，这类风险本可以通过更细颗粒度的权限分离来削弱，例如将应用提交、推荐位配置、任务界面管理拆分为不同角色和通道，对首页推荐区和任务系统的改动引入多重审核、时间延迟或独立签批，并辅以针对异常行为的监测——如短时间内的配置大幅变更、未经验证发布者关联的推荐内容、界面文案中出现索要助记词等高危信号。目前公开信息并未说明 Solana Mobile 是否已经修复发布门户漏洞或调整权限设计，这也意味着权限架构和行为监测能否被重新加固，将直接决定用户未来对这个“官方入口”安全性的实际信任边界。
紧急下架与设备清理：响应速度与盲区
从恶意应用出现在推荐位到被下架的时间约一小时，据单一来源，这意味着 Solana Mobile 在发现异常后确实做到了第一时间关掉“入口”，并同步通过 X 平台披露事件、将“SKR Claim”从 dApp Store 移除，对前端暴露风险的处置速度是合格甚至偏快的。但应用从商店消失，并不等于风险在终端侧立刻归零。官方同时表示，这款恶意应用正在从已安装了该应用的设备中移除，但公开信息并未说明这一过程依托的是远程策略、系统级更新，还是依靠用户侧的客户端更新与交互确认，也没有给出预计完成时间和覆盖范围，设备端的“清理”因此带有明显的处置尾部不确定性。
更关键的是，在这一整套紧急响应叙述中，缺失的恰恰是量化风险的核心数据：到底有多少用户在这一个小时内实际安装了“SKR Claim”，又有多少人真的输入了助记词并暴露了资产权限，至今都没有公开说明。没有受影响用户数量、没有确认的资产损失，更没有攻击者链路或技术细节，外界只能在“可能有人被钓鱼”这一抽象层面上进行风险想象，而无法判断这是一场被迅速掐灭的小范围事故，还是一次规模尚未揭示的系统性疏漏。
从这次事故看未来移动钱包安全课
对于刚刚起步的 Solana 移动生态，这一次在 11 月 2 日发生、并由 Solana Mobile 亲自承认和下架处理的恶意应用事件，直接冲击的是 dApp Store 作为「可信入口」的边界：一旦推荐位和任务界面被篡改，用户看到的就不再是简单的列表，而是带有“官方背书”幻觉的诱导空间。真正值得持续观察的，是三个变量的走向：其一，Solana Mobile 在后续时间里能否就漏洞成因、权限设计和移除进展保持足够透明，而不是让这次披露停留在「发现-下架」的简讯层面；其二，dApp Publishing Portal 与 dApp Store 的整体安全架构是否会迎来权限分层、提交流程、多重审核等结构性的升级，而不仅是一次性封堵入口；其三，用户教育能否从事后提醒，上升为日常机制，让「不在任何应用或网页输入完整助记词」这条行业共识，在移动端变成可感知的设计和反复出现的提示。更广义上，这次事故敲打的是整个 Web3 移动应用生态：只要官方分发渠道仍然是新用户的第一站，它的安全设计就必须假定“推荐位也可能失守”，而助记词保护则要被视为所有交互流程的最高优先级，这将长期决定用户是否敢把自己的钱包托付给手机上的任何一个图标。
加入我们的社区，一起来讨论，一起变得更强吧！
AiCoin专属Hyperliquid福利：https://app.hyperliquid.xyz/join/AICOIN88
AiCoin专属Aster福利：https://www.asterdex.com/zh-CN/referral/9C50e2
链上电报（Telegram）社群：https://t.me/AiCoinWhaleData
链上社区：https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin链上推特：https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。
