Solana Mobile Removes Fake SKR Claim App After Store Breach

Solana Mobile says a malicious application impersonating an SKR token claim was promoted inside its official decentralized-app store for approximately one hour after an attacker gained unauthorized access to an application-publishing portal. The app asked users to reveal wallet recovery phrases—the secret words that can give an attacker control over their cryptocurrency.

Editorial illustration of fake SKR Claim app on Solana Mobile

In a November 1 statement from the official Solana Mobile account, the company said that someone altered the App Spotlight and Quests interfaces through unauthorized access to the dApp Publishing Portal. A third-party application named “SKR Claim” was then made visible in a curated store location despite not completing the normal publishing process. Solana Mobile says the app was removed and that it has patched the linking flaw behind the exposure.

The incident is notable because the phishing lure did not arrive solely through an unsolicited message or suspicious website. It appeared in a distribution environment users might have assumed was vetted. Store placement can increase apparent credibility even when the underlying application is malicious.

One hour in a trusted channel was enough to create risk

Solana Mobile’s account says the fake listing remained in App Spotlight for about an hour before removal. The company was also working to delete the application from devices on which it had been installed. Its statement did not provide a verified count of installations, disclosed recovery phrases or confirmed asset losses.

Those missing figures are important. A one-hour exposure window is not proof that funds were stolen, and the number of people who may have seen a listing is different from the number who installed or interacted with an app. Until more information is released, the incident should not be quantified as a network-wide compromise or assigned an invented dollar loss.

According to the company’s explanation, the breach concerned the publishing portal and store interfaces. That is distinct from an exploit of the Solana blockchain’s consensus rules. Users should avoid interpreting an application-store security failure as evidence that Solana’s underlying transaction system was compromised.

Solana Mobile said the repaired flaw had allowed links to apps that were not fully published. A secure publishing workflow should enforce review and authorization checks before a listing becomes reachable through curated areas, not merely before it appears in a normal search result. The reported mechanism raises questions about permission boundaries, audit logs and whether store-curation capabilities were sufficiently separated from submission access.

What SKR holders and Seeker users should do

The critical difference is whether a user exposed a recovery phrase. Someone who saw a fraudulent listing but never entered secrets is not automatically compromised simply because it appeared in a store. Anyone who typed a wallet’s seed phrase into the app, however, should consider that secret exposed and move remaining assets to a fresh wallet generated with a new recovery phrase using a trusted wallet interface. Deleting the phishing app cannot undo the disclosure.

For a wallet holding multiple tokens or connected to decentralized services, users should review the full set of balances and accounts associated with the compromised recovery phrase. A new password for the same wallet is not a substitute for a new seed phrase if the words themselves were disclosed.

Solana Mobile stressed that its staff will not ask users to submit seed phrases, transfer cryptocurrency or connect wallets to other sites to claim airdrops. That warning applies regardless of whether an offer arrives through social media, a search advertisement or an apparently official store screen.

The company says it has removed the malicious application from the store and begun removing installations from devices. The next independently meaningful updates would be an accounting of affected users, any confirmed losses, the access path into the publishing portal and the controls introduced to stop a repeat.

The broader lesson is a distribution-security one: users need to assess what an app asks for, not just where they discovered it. A store listing can be legitimate while an individual application request is unsafe—and no real airdrop claim requires handing over a wallet’s recovery phrase.

How do you rate this article?