On November 2, a third-party application named “SKR Claim” briefly intruded into the core trust entry of the Solana dApp Store. It was not listed through normal procedures, but was submitted and passed the review threshold by unauthorized access to the Solana dApp Publishing Portal, immediately appearing on the interface that users almost click on every day. More dangerously, the attackers not only pushed this application to the App Spotlight recommendation position but also simultaneously tampered with the Quests task interface, embedding “SKR Claim” directly into the task entry, making it look like an officially endorsed activity tool within the store. During this exposure window of less than an hour, the application interface induced users to enter their seed phrases, handing over the highest permissions that should only exist in cold wallets and key managers to an unknown program. According to public information, Solana Mobile quickly removed the application from the dApp Store after discovering the anomaly and confirmed the disclosure of the event via the X platform, while announcing that it was actively removing this application from devices that had already installed “SKR Claim” to block this high-risk phishing path stemming from the compromised internal entry.
One Hour Window: Malicious Application Seizing Recommendation Position
The story began with what seemed like a normal publishing action. The attackers gained unauthorized access to the internal channel leading to the Solana dApp Publishing Portal, bypassing the thresholds meant to block unfamiliar developers and submitted “SKR Claim” as a legitimate application into the Solana dApp Store. Launching was just the first step; more crucial was the rewriting of the entry: the same batch of unauthorized operations extended to the App Spotlight recommendation area and the Quests task interface, pushing the malicious application to a prominent position where users commonly click, as if it always belonged to this ecosystem’s “official selection.”
According to public information, “SKR Claim” stayed in these recommended positions for about an hour. During this window, any user who habitually trusts the official store displays, downloading directly from the Spotlight and task entry without mental preparation, could be exposed to the high-risk induction demanding their seed phrases. On November 2, Solana Mobile confirmed the discovery of the anomaly and initiated an emergency removal process, removing the application from the dApp Store while also disclosing the event via the X platform, warning users to be cautious of any applications requesting seed phrases, and attempting to pull back the compromised recommendation position within that hour to its rightful safety boundaries.
Trust Entry Misused: Official Store Becomes Phishing Ground
Traditional on-chain phishing mostly occurs “off-chain”: strange links, spoofed websites, fake tweets, where users can at least rely on domain names and UI details to determine whether to click. But this time, “SKR Claim” did not enter through some suspicious external link; it appeared in users' phones openly along the official distribution path of the Solana dApp Store, directly moving the attack surface into the “inner circle” that should be regarded as safe. According to Solana Mobile, after unauthorized access to the dApp Publishing Portal, the attackers further tampered with the App Spotlight recommendation area and the Quests task interface, stuffing this malicious application into the most conspicuous position, granting it exposure and endorsement that should only have been reserved for officially trusted content.
The Spotlight recommendation positions essentially represent “editor's picks,” implying in most users’ minds that they have already been screened by the official. This makes it a lower-risk entry that users feel comfortable directly clicking on; Quests serves as a task panel guiding users to complete specific interactions, where users are accustomed to following prompts step by step. When both of these highly trusted interfaces simultaneously show prompts like “Enter seed phrase to complete task/claim benefits,” many people no longer view it as a risky action, but rather as part of the process. However, seed phrases are the master keys to wallets; entering them in a malicious application amounts to handing over control of the entire wallet to attackers, rather than merely signing a traceable, revocable on-chain transaction. This request for seed phrases originating from the official store entry upgrades what was previously a relatively marginal phishing scenario into a subversive test of the “trusted entry” itself, exposing users’ weak understanding of the power structures behind the interfaces.
Loss of Publishing Permissions: Recommendation Positions and Task Interfaces Tampered
According to a single source, the crux of this incident lies not just in one malicious application being submitted to the store but in the same unauthorized entry being able to push “SKR Claim” into the dApp Publishing Portal and directly rewrite the App Spotlight recommendation area and the Quests task interface. In other words, once the publishing portal is breached, the attackers gain not only “listing rights” but also “display rights” and “operations rights,” allowing them to place their phishing applications in the main recommendation position and task entry simultaneously. This multifunctional entry exposes clear security gaps at the institutional level: the application submission process, recommendation position configuration, and task system operation seem to be bundled under the same permissions; as long as this permission set is bypassed, the entire store front will be hijacked.
From a design perspective, such risks could be mitigated through finer-grained permission separation, for instance, by dividing application submissions, recommendation position configurations, and task interface management into different roles and channels, introducing multiple reviews, time delays, or independent approvals for changes to the main page recommendation area and task system, along with monitoring for abnormal behaviors—such as significant configuration changes within a short timeframe, recommendation content associated with unverified publishers, or high-risk signals like requests for seed phrases appearing in interface copy. Current publicly available information does not specify whether Solana Mobile has fixed the publishing portal vulnerability or adjusted the permission design, which also means whether the permission architecture and behavior monitoring can be reinforced will directly determine the actual trust boundary users have in the safety of this “official entry” in the future.
Emergency Removal and Device Cleanup: Response Speed and Blind Spots
From the time the malicious application appeared in the recommendation position to its removal took about an hour; according to a single source, this indicates that Solana Mobile indeed acted promptly to close the “entry” upon detecting the anomaly, simultaneously disclosing the incident through the X platform and removing “SKR Claim” from the dApp Store, which reflects a competent or even quick handling of the front-end exposure risk. However, the disappearance of the application from the store does not mean that the risk on the terminal side immediately drops to zero. The official also stated that this malicious application is being removed from devices that had it installed, but public information has not specified whether this process relies on remote policy, system-level updates, or user-side client updates and interaction confirmations, nor has it provided an expected completion time or coverage, thus introducing significant uncertainty to the “cleanup” on the device side.
More critically, throughout this entire emergency response narrative, what is missing is the core data needed to quantify the risk: how many users installed “SKR Claim” during this hour, how many actually entered their seed phrases and exposed their asset permissions, has not been publicly disclosed. There are no numbers on affected users, confirmed asset losses, or details of the attacker’s pathways or techniques; the outside world can only engage in risk imagination at the abstract level of “possibly someone was phished,” without being able to determine whether this was a small-scale incident quelled swiftly or a systemic oversight whose scale has yet to be revealed.
Looking at Future Mobile Wallet Security from This Incident
For the newly emerging Solana mobile ecosystem, the malicious application incident that occurred on November 2, personally acknowledged and handled by Solana Mobile, directly impacts the boundary of the dApp Store as a "trusted entry": once the recommendation positions and task interface are tampered with, what users see is no longer a simple list but an enticing space with the illusion of “official endorsement.” What is truly worth ongoing observation is the trend of three variables: first, whether Solana Mobile can maintain sufficient transparency regarding the causes of the vulnerability, permission design, and removal progress in the follow-up period, rather than letting this disclosure remain at the “discovery-removal” brief level; second, whether the overall security architecture of the dApp Publishing Portal and dApp Store will undergo structural upgrades such as permission layering, submission processes, and multiple reviews, rather than merely blocking the entry一次性; third, whether user education can evolve from post-incident reminders to a daily mechanism, making the industry consensus of “never input full seed phrases into any application or webpage” into perceivable design and repeated prompts on mobile. More broadly, this incident highlights the entire Web3 mobile application ecosystem: as long as the official distribution channels remain the first stop for new users, their security design must assume that “recommendation positions may also be compromised,” and seed phrase protection should be regarded as the highest priority of all interaction processes, which will ultimately determine whether users dare to entrust their wallets to any icon on their phones.
Join our community, let's discuss, and become stronger together!
Exclusive Hyperliquid benefits for AiCoin: https://app.hyperliquid.xyz/join/AICOIN88
Exclusive Aster benefits for AiCoin: https://www.asterdex.com/zh-CN/referral/9C50e2
On-chain Telegram community: https://t.me/AiCoinWhaleData
On-chain community: https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin on-chain Twitter: https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到[email protected]，本平台相关工作人员将会进行核查。
