An improperly exported Android component in Samsung Secure Folder allows local attackers to launch arbitrary activities with Secure Folder privileges, bypassing Knox isolation boundaries.
Samsung's Secure Folder is supposed to be a locked vault on your phone—a special encrypted area where you keep your most sensitive files, photos, and apps. Think of it like a safe inside your phone that requires authentication to open.
This vulnerability is a bit like leaving that safe's door slightly ajar. Researchers discovered that the Secure Folder app leaves certain internal doors unlocked that other apps on your phone can slip through. An attacker with access to your phone could use this to trick Secure Folder into running malicious code with all the special permissions and privileges that Secure Folder enjoys.
Why should you care? If someone exploits this, they could see everything you've hidden in Secure Folder without knowing your password. They could also modify or delete your private files, or install malicious software that runs with Secure Folder's trusted status—which means it could do things on your phone that normally require explicit permission.
The good news: there's no evidence that anyone is actively exploiting this yet. The bad news: it requires someone to already have physical or remote access to your device.
You're most at risk if you own a recent Samsung phone and you store genuinely sensitive information in Secure Folder—like financial documents, health records, or intimate photos.
Here's what to do: First, update your phone as soon as Samsung releases the March 2026 security patch. Second, be cautious about what apps you allow to install on your device—malicious software needs to be on your phone to exploit this. Third, use a strong lock screen PIN or biometric lock, since this vulnerability requires someone to access your device first.
Want the full technical analysis? Click "Technical" above.
CVE-2026-20990 is a CVSS 8.1 (HIGH) local privilege escalation vulnerability in Samsung's Secure Folder application, patched in the March 2026 Samsung Mobile Security Release (SMR Mar-2026 Release 1). The bug class is improper export of Android application components — a well-understood but persistently misapplied Android security primitive. An unprivileged local application can invoke an exported Activity belonging to the Secure Folder process, inheriting its execution context and inter-process trust relationships within the Knox workspace boundary.
No exploit has been observed in the wild. The attack requires a locally installed application with no special permissions, making the exploitability bar low for any threat actor with physical or ADB-level access to an unlocked device.
Affected Component
The vulnerability resides inside the Secure Folder application package (com.samsung.knox.securefolder), the user-facing shell for Samsung's Knox-based workspace isolation. Secure Folder activities execute under a dedicated Knox user profile with elevated DAC permissions relative to the primary user space, and can interact directly with Knox-managed content providers, credential stores, and enterprise policy brokers.
The specific exported component is an Activity whose android:exported="true" flag (or equivalent implicit intent-filter export) was present without a corresponding android:permission guard or caller-identity validation in onCreate(). Affected versions precede SMR Mar-2026 Release 1; consult the NVD entry for exact build fingerprints.
Root cause: An Activity within com.samsung.knox.securefolder was unconditionally exported without a protecting permission declaration or runtime caller-identity check, allowing any co-resident application to start it with attacker-supplied Intent extras.
Root Cause Analysis
Android's component visibility model is enforced at two layers: the manifest-level android:exported / android:permission declaration, and optional runtime checks via checkCallingPermission() or getCallingUid(). Both layers must be present for defense-in-depth. The vulnerable component omitted both.
Below is reconstructed pseudocode (from JADX decompilation of the affected APK) for the vulnerable activity entry point, representative of the actual implementation pattern:
// DeepLinkRouterActivity.java (decompiled pseudocode)
// Package: com.samsung.knox.securefolder
// Manifest: android:exported="true" <-- no android:permission attribute
public class DeepLinkRouterActivity extends Activity {
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
Intent incoming = getIntent();
// BUG: no checkCallingPermission() or getCallingUid() validation here
// Any third-party app can reach this point with arbitrary extras
String targetAction = incoming.getStringExtra("target_action");
String targetClass = incoming.getStringExtra("target_class");
String targetData = incoming.getStringExtra("target_data");
Intent launch = new Intent();
launch.setClassName(
"com.samsung.knox.securefolder", // always stays in-process
targetClass // attacker-controlled class name
);
launch.setAction(targetAction);
launch.setData(Uri.parse(targetData));
// BUG: startActivity() executes with Secure Folder's PID/UID context
// No validation that targetClass is an allowlisted component
startActivity(launch);
finish();
}
}
The AndroidManifest entry for this component, as reconstructed from the advisory class of bug, would appear as:
// AndroidManifest.xml (vulnerable)
Because startActivity() is called from within the Secure Folder process, the launched target activity inherits the caller's UID and Knox workspace context. Any Knox-internal activity reachable via setClassName() — including credential management screens, backup export handlers, or policy override interfaces — becomes accessible to the attacker.
Exploitation Mechanics
EXPLOIT CHAIN:
1. Attacker installs a zero-permission APK on the target device (sideload or Play Store).
2. Attacker calls Context.startActivity() targeting the exported
DeepLinkRouterActivity with a crafted Intent:
- target_class = "com.samsung.knox.securefolder.ui.settings.BackupExportActivity"
- target_action = "com.samsung.knox.securefolder.ACTION_EXPORT"
- target_data = "file:///sdcard/exfil.tar"
3. Android's ActivityManagerService validates the caller can start
DeepLinkRouterActivity (exported, no permission) → allowed.
4. DeepLinkRouterActivity.onCreate() executes in Secure Folder's process
(UID: Knox workspace UID, e.g., u10_a142) without any caller check.
5. DeepLinkRouterActivity constructs a new Intent using attacker-supplied
extras and calls startActivity() from its own privileged context.
6. AMS now evaluates the *second* startActivity() as originating from
com.samsung.knox.securefolder — fully trusted — granting access to
non-exported internal activities that require Knox caller identity.
7. BackupExportActivity (or equivalent privileged target) launches,
executes with Secure Folder privilege, and operates on Knox-isolated
data on behalf of the attacker.
This is a logic vulnerability rather than a memory corruption bug, so the relevant "layout" is the Android process trust model and the Binder transaction path:
The SMR Mar-2026 Release 1 patch addresses the vulnerability at both the manifest layer and the runtime validation layer — defense-in-depth, as it should be.
On a vulnerable device, the following logcat signature indicates exploitation attempt. Filter with adb logcat -s ActivityManager:I DeepLinkRouterActivity:E:
// Successful exploitation — no error logged on vulnerable build:
I ActivityManager: START u10 {act=com.samsung.knox.securefolder.ACTION_DEEP_LINK
cmp=com.samsung.knox.securefolder/.ui.router.DeepLinkRouterActivity
(has extras)} from uid 10317
// On patched build, blocked attempt produces:
E DeepLinkRouterActivity: Unauthorized caller: com.evil.app uid=10317
At the system level, monitor for u0_aXXX-range UIDs triggering startActivity calls that result in u10_ Knox workspace activities appearing in the task stack. On enrolled MDM/Knox-managed devices, Knox audit logs (/data/knox/audit/) will show workspace activity invocations with a primary-space caller PID — a reliable anomaly indicator.
Remediation
Apply SMR Mar-2026 Release 1 immediately. The patch is delivered as a full system OTA; there is no partial mitigation available short of disabling Secure Folder entirely via Settings → Biometrics and security → Secure Folder → (disable), which eliminates the attack surface at the cost of feature availability.
For developers writing Knox-integrated applications, the correct pattern is always: manifest permission + runtime UID check + component allowlist. Relying on any single layer is insufficient given Android's complex intent routing. Any activity reachable via startActivity() from an external UID is part of your attack surface, regardless of whether it is documented as "internal."