Blog
An Exploit Inside an App Store App: What FomoPeek Means for "App Store Only" Policies

Spencer
Parker

TL;DR
FomoPeek billed itself as a read-only crypto monitoring tool. Two versions distributed through Apple's App Store in September carried a hidden iOS exploitation toolkit (SlowMist).
Once the toolkit succeeded, it could escape the app sandbox and "read and decrypt Keychain items, and pull files belonging to other apps" (Crowdfund Insider).
The attacker's main address received 579,984.34 USDT, about $580,000 (SlowMist).
It's one case, not yet a trend. It still shows that an allow-list of App Store apps can't tell you what is actually running on a device.
Why "App Store only" became the default rule
"Only install apps from the App Store" is one of the most widely used iPhone mobile security rules, and for good reason. iVerify's 2026 Advanced Mobile Threat Report calls App Store review "one of the strongest parts of Apple's security model."
The rule is also easy to explain and easy to enforce, which is why most iPhone users follow it without thinking, and most enterprise mobile policies treat it as sufficient. Most MDMs can block apps by bundle ID and a security team can maintain a list of approved titles for fully managed devices, but both controls rest on the same assumption, that an app which made it onto the store behaves the way its listing says and Apple have scanned the code and removed any app which breaks it’s strict App Store rules. For at least eight days in September, FomoPeek broke that assumption. And there are no controls for unmanaged BYOD devices….
Case study: FomoPeek
FomoPeek was a crypto "whale-watching" app distributed through Apple's App Store. SlowMist, working with OKX's security team, found that two versions carried a kernel exploitation toolkit and a command-and-control module unrelated to the app's advertised function (SlowMist).
The app presented itself as a "read-only on-chain monitoring and alerting tool." It didn't ask users to connect a wallet or enter a seed phrase, which made it look low-risk to the exact audience it targeted.
Version | Date (2026) | What SlowMist found |
1.3 | Sep 17 | Both malicious frameworks removed |
1.2 | Sep 12 | Same malicious code as 1.1 |
1.1 | Sep 9 | Malicious modules introduced |
1.0 | Aug 29 | No malicious modules |
What the toolkit could do
The toolkit held eight exploitation strategies, chosen by device model and iOS version. Together they declared coverage of iOS 12.0 through 18.7.2 and iOS 26.0 through 26.1. One of them, which SlowMist's analysis names DarkSwordStrategy, covered iOS 16.7 through 18.7.2 and 26.0 through 26.1, putting a strain of this year's leaked exploit code inside an App Store app.
Once an exploit succeeded, the toolkit could escape the app sandbox and "read and decrypt Keychain items, and pull files belonging to other apps" (Crowdfund Insider). Its server sent a collection list of 19 targets, almost all wallet apps plus Apple Notes, where a saved recovery phrase hands over the wallet itself.
The loss
SlowMist traced 579,984.34 USDT, about $580,000, to the attacker's primary crypto wallet, which became active on September 15, two days before version 1.3 removed the toolkit. Because updating or uninstalling doesn't undo data that has already left the device, SlowMist advises anyone who ran 1.1 or 1.2 to treat their old seed phrases and private keys as compromised.
What it breaks in mobile security policy
FomoPeek shows that an app's store listing and its runtime behavior can come apart, and an inventory-based policy only sees the listing.
The threat report puts the problem plainly: "Victims only installed an app from the official store, and nothing in its listing signaled an exploit." Every control built on the app's identity would have passed it, because the malicious code arrived as an ordinary version update to an app already on the store. That leads the report to one conclusion: "An allow-list of App Store apps is no substitute for seeing what is actually running on the device."
The stakes also go beyond crypto. FomoPeek's operators wanted wallets, but a sandbox escape that reads the Keychain reads everything stored there, and on a phone used for work that includes the credentials for corporate email, single sign-on, chat, and VPN. iVerify's guidance for that situation is direct: "if a device used for work is compromised, treat every credential stored on it as compromised too."
Timing makes the gap harder to close. The malicious builds were live for eight days before a clean update replaced them, so a team that audits its app inventory monthly could have looked at FomoPeek after September 17 and found nothing wrong with the current version.
The Android parallel
Android attackers lean on the same trust in familiar apps and built-in scanners, usually through sideloading rather than the store itself.
Cellik, a remote access trojan iVerify analyzed, lets an operator pick a legitimate app from the Google Play catalog and wrap the RAT inside it with a one-click builder, so the result looks like a popular app. Its seller claims this lets Cellik slip past Play Protect, a claim iVerify didn't verify. Octagon, which rents for $1,400 a month and spreads as a sideloaded APK, shows the scanner side of the problem: while it ran, Google Play Protect reported "No harmful apps found."
Neither write-up shows these kits being distributed through Google Play. What both show is that a recognizable app name and a clean scanner result aren't the same as knowing what's running on the phone.
What to do instead of trusting the store alone
In practice, most iPhones can only install apps from the App Store anyway, so the work is adding the visibility the store can't provide on its own.
Detect on-device behavior, not just app inventory. An allow-list tells you which apps are installed. On-device detection looks for the side effects of exploitation, such as a sandbox escape, which shows up no matter what the app is called.
Close the patch gap. FomoPeek's toolkit declared coverage up to iOS 18.7.2 and 26.1. Phones on current iOS were outside every range it listed. Requiring a minimum OS version for corporate access keeps most of the fleet out of reach.
Treat a compromise as a credential incident. If a work phone ran a malicious build, rotate the credentials stored on it and revoke its sessions, since uninstalling the app doesn't recall data that has already left.
FAQ
Is the App Store safe?
It is one of the strongest controls in Apple's security model, and installing only from the App Store remains good policy. FomoPeek shows it isn't a guarantee. Two versions of an App Store app carried a working exploitation toolkit in September 2026.
Can App Store apps contain malware?
Yes. FomoPeek is a documented 2026 case. Versions 1.1 and 1.2 carried a hidden toolkit that could escape the iOS sandbox and read Keychain data, according to SlowMist's analysis.
Does Apple's review catch exploits?
App Store review catches a great deal, but no review process sees everything an app does after it's installed. That's why on-device detection matters alongside the store's controls.
What should I do if an employee installed FomoPeek 1.1 or 1.2?
Treat the phone as compromised. Rotate the credentials stored on it, revoke active sessions, and follow SlowMist's guidance to move any crypto assets to a new wallet created on a clean device.
Subscribe to our blog to receive the latest research and industry trends delivered straight to your inbox. Our blog content covers sophisticated mobile threats, unpatched vulnerabilities, smishing, and the latest industry news to keep you informed and secure.



