Author: Sacha Kozma, Yichen Chai (Bugscale SA)
Published: 30 April 2026
Source: https://bugscale.ch/blog/here-we-go-again-a-five-bug-chain-to-arbitrary-apk-install-on-samsung-s25/
Summary
Researchers at Bugscale SA discovered and chained five vulnerabilities in the Samsung Galaxy Store application (version 4.6.02.7) to achieve silent, arbitrary APK installation on Samsung Galaxy S25 devices — and any Samsung phone running the same Store version. An unprivileged malicious app with no special permissions can trigger the attack chain by simply being launched, requiring zero user interaction. Samsung acknowledged the report, rated it high severity, issued patches through its security bulletin, and awarded a $50,000 bounty. CVE identifiers had not been publicly disclosed in the source at time of publication.
Technical Details
The exploit chain combines five distinct weaknesses in the Galaxy Store application:
Bug 1 — Broken Shell APK Signature Verification (Cloud Games)
Galaxy Store’s Cloud Games “Instant Play v2” feature installs small Shell APKs — shortcut packages — silently when a game deeplink containing &directinstall=01&ua=01 is triggered. Before installation the Store performs its own signature check in com.samsung.android.game.cloudgame.sdk.uu.f.validate, which is flawed in two compounding ways:
- Wrong v3-to-v2 fallback: The Store’s custom signature verifier falls back from v3 to v2 if the v3 signer does not match the expected developer key, rather than rejecting the APK outright. The Android system installer, by contrast, accepts a valid v3 signature regardless of the Store’s expected signer. This divergence allows an attacker to present a self-signed v3 block (accepted by the OS) alongside a transplanted v2 block (accepted by the Store’s flawed fallback logic).
- Broken v2 digest validation: When checking the v2 signing block, the Store verifies the cryptographic signature over the digest embedded in the block, but never verifies that the APK’s actual content hashes to that digest. This means a valid v2 signing block extracted from a legitimate Shell APK can be spliced verbatim into an attacker-controlled APK — the Store accepts the transplanted block as valid even though the APK contents differ entirely.
Combined, an attacker can craft a payload APK signed with their own v3 key and carrying a copied v2 block from a legitimate Shell APK. The Store accepts it via the broken v2 fallback path; the Android installer accepts it via the attacker’s valid v3 signature. The payload APK must only share the expected package name (e.g. net.wargaming.wot.blitz.flexion for World of Tanks), which is trivially set at build time. The Shell APK storage path is deterministic and predictable: /data/data/com.sec.android.app.samsungapps/files/samsungapps-<productID>-<fileSize>-<version>.apk.
Bug 2 — Unprotected Exported Broadcast Receiver (SmartSwitchReceiver)
The Galaxy Store exports a broadcast receiver com.sec.android.app.samsungapps.smartswitch.SmartSwitchReceiver (via android:exported="true") intended for use by Samsung’s Smart Switch migration app. Critically, no android:permission attribute restricts who can send broadcasts to it, meaning any installed application — with zero privileges — can invoke its restore or backup logic. This is an access-control omission that exposes a privileged file-write capability to untrusted callers.
Bug 3 — Path Traversal in SmartSwitchReceiver Restore Flow
The REQUEST_RESTORE_GALAXYSTORE broadcast action instructs the Store to fetch files from attacker-supplied content provider URIs and write them under its internal files/temp/ directory. The destination path is computed by replacing the root document ID prefix with the temp folder path, then passing the result directly to new File(...) without any sanitization. By encoding /../ sequences in document IDs (e.g. data%2F..%2Ftarget.apk), an attacker can traverse outside the temp directory and write a file to any location within Galaxy Store’s data directory — including the deterministic Shell APK path identified in Bug 1.
Bug 4 — Predictable PRNG in Restore Authentication
Before executing the restore, SmartSwitchReceiver runs a challenge-response authentication: it generates a random integer, broadcasts it to Smart Switch, and expects the same integer back within 60 seconds. The integer is drawn from a static RandomUtil instance (a subclass of java.util.Random) seeded with System.currentTimeMillis() at Galaxy Store startup. Because the seed space is narrow (millisecond-precision wall-clock time at a known approximate startup moment), and the 60-second response window allows many guesses, an attacker can brute-force the seed: they generate candidate integers from new Random(seed) across a ±200 ms window around the observed startup time, calling nextInt() twenty times per seed to account for prior PRNG consumption elsewhere in the app, and send all candidate values back to the receiver. In practice the correct seed is found within a few hundred milliseconds.
Bug 5 — NullPointerException DoS in IapReceiver (Crash-on-Demand)
The Store’s exported com.samsung.android.iap.receiver.IapReceiver calls intent.getData().getSchemeSpecificPart() without first checking whether getData() returns null. Sending any broadcast to this receiver that omits the data URI triggers an uncaught NullPointerException and crashes the Galaxy Store process. This crash primitive is used to restart the Store at a controlled moment, enabling the attacker to bound the PRNG seed search space for the Bug 4 brute-force.
Full Exploit Flow
- The malicious app crashes Galaxy Store via the
IapReceiverNullPointerException, then relaunches it. - It sends a
REQUEST_RESTORE_GALAXYSTOREbroadcast with a URI pointing to the crafted payload APK hosted in the attacker app’s own content provider, using path traversal to target the deterministic Shell APK path. - It brute-forces the authentication challenge by replaying candidate random integers across the expected seed range.
- Galaxy Store fetches and writes the payload APK to the Shell APK path.
- The attacker app triggers the Cloud Games deeplink, causing Galaxy Store to “install” the already-placed payload APK without re-downloading it.
- Galaxy Store’s broken signature check accepts the APK; the Android installer installs it via the valid v3 signature.
Impact
The full chain allows any installed application — holding no declared permissions and requiring no user interaction beyond launch — to silently install an arbitrary APK on the victim device. The installed APK does not need to be available in the Galaxy Store or any other marketplace. The attack was demonstrated on a Samsung Galaxy S25 running Galaxy Store version 4.6.02.7, but the researchers note it applies to any Samsung handset running this Store version. Samsung rated the bug chain high severity and awarded a total bounty of $50,000.
Mitigation
Samsung acknowledged the vulnerabilities and has published patches in its official security bulletin. Users should ensure their Galaxy Store application is updated to a version beyond 4.6.02.7 by applying any pending Samsung software updates. Specific CVE identifiers and the exact bulletin reference were not disclosed in the source article at time of publication. No public workarounds exist for unpatched devices beyond restricting installation of untrusted third-party applications.