Solana Mobile Security Alert Follows Fake Claim App
The Solana Mobile security alert concerns a malicious third-party application called “SKR Claim,” which asked users to enter their wallet seed phrases.
In its statement, reproduced by a public social-media mirror, Solana Mobile said unauthorized access to the dApp Publishing Portal preceded changes to the App Spotlight and Quests interface. The application appeared in Spotlight for approximately one hour before its removal.
The company said it identified and patched a bug that allowed links to applications that were not fully published. It also said removal from devices where the app had been installed was underway—not necessarily completed.
What Was Compromised—and What Remains Unclear?
The disclosed problem concerns access to the publishing portal and the way an incompletely published app could be promoted. The available statement does not provide a complete explanation of how the attacker first obtained portal access.
Crypto Briefing reported that Solana Mobile said device security, Seed Vault and onchain systems were not compromised. That assurance concerns those systems; it does not protect a recovery phrase a user voluntarily entered into the malicious application.
Issue | Status in the reviewed disclosures |
|---|---|
Malicious application | Identified as “SKR Claim” |
Requested information | Wallet seed phrases |
Store exposure | Approximately one hour in Spotlight |
Linking vulnerability | Patched, according to Solana Mobile |
Installed copies | Removal was underway |
Victim count and financial losses | Not established in the reviewed statement |
These details describe the disclosed incident, not an independent forensic audit.
Why a Seed-Phrase Request Is So Dangerous
A recovery phrase can recreate control of a wallet on another device. Anyone who obtains it may be able to move existing assets and steal funds sent to the same wallet later.
Phantom’s official compromised-wallet guidance says a recovery phrase entered into a malicious website or application should be treated as permanently compromised. Deleting the application or disconnecting it does not erase information the attacker already possesses.
The store placement matters because users may interpret a featured listing as evidence that a claim is legitimate. Bitnxt’s earlier airdrop guide and scam checks provides related background on verifying opportunities before interacting with them. Its dated claim opportunities should not be treated as current recommendations.
What Users Who Interacted With the App Should Do
The appropriate response depends on what happened.
If a seed phrase was entered: treat the associated wallet as compromised. Using a trusted, clean device and authentic wallet software, create a new wallet with a fresh recovery phrase and follow the wallet provider’s recovery guidance for any remaining assets. Importing the old phrase into another app does not create a secure replacement.
If the app was installed but no phrase was entered: remove it, apply official updates and review wallet activity. Installation alone does not establish that funds were stolen, but users should follow further instructions from Solana Mobile.
If funds disappear immediately after deposits: do not keep adding money to the affected wallet. Phantom warns that automated sweeper bots can drain incoming assets after an attacker gains control.
Solana Mobile’s own scam-prevention guidance identifies requests to “verify” or “recover” a wallet by entering a seed phrase as warning signs.
Bitnxt’s Take: Featured Placement Cannot Replace Verification
Our assessment is that this incident exposes a problem beyond an individual fake app: a compromised distribution interface can make a malicious request appear trustworthy.
Secure key storage and secure app distribution address different risks. Hardware protection cannot undo the disclosure of a recovery phrase outside its protected environment.
Bitnxt’s earlier reporting on the Coinbase–Amplitude data incident examined another situation where the affected system had to be distinguished from the wider platform. The same discipline applies here: a publishing-portal incident should not automatically be described as a Solana blockchain breach.
The next useful disclosure would explain the access failure, confirm completion of device-level removal and clarify whether users lost funds. Until then, a patched store bug and a secured individual wallet should be treated as separate recovery milestones.
