Loading vulnerability…
CVE-2026-0091 is a local privilege escalation vulnerability in the Android launcher process caused by an over-privileged shell user in multiple code locations. The flaw allows an attacker to execute code in the launcher process because the shell user is granted excessive privileges beyond what is necessary. Successful exploitation does not require user interaction and does not require additional execution privileges beyond local code execution capability on the device.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos.
This repository is a standalone Android exploit PoC project, not tied to a common exploit framework. It is an Android Studio/Gradle application containing two meaningful Java classes under `top.canyie.transitionplayer` plus several local stub classes mirroring hidden Android framework APIs (`android.window.*`, `android.app.IApplicationThread`, etc.) so the project can compile against non-SDK interfaces. Core exploit flow: 1. `Main.java` is the primary entrypoint. It is intended to be launched manually on-device using `adb shell app_process ... top.canyie.transitionplayer.Main`, not through the normal Android app lifecycle. 2. `Main` determines the installed APK path via reflection (`getDexLocation`), constructs a synthetic `ApplicationInfo`/`ActivityInfo`, and prepares an `Intent` targeting `top.canyie.transitionplayer.ShellCodeReceiver`. 3. It registers a custom `ITransitionPlayer` with `WindowOrganizer.registerTransitionPlayer()` and waits for a transition event. 4. When the user launches an arbitrary app from the launcher, `requestStartTransition()` is invoked. The exploit extracts a `RemoteTransition` from the request and then obtains an `IApplicationThread` binder via `remoteTransition.getAppThread()`. 5. Using that leaked application-thread handle, the exploit calls one of several `scheduleReceiver(...)` overloads for Android-version compatibility, causing the target process to load the attacker APK path and execute the attacker-controlled `ShellCodeReceiver`. Payload behavior in `ShellCodeReceiver.java`: - Determines the current process name (`Process.myProcessName()` or `/proc/self/cmdline`). - Logs execution context including UID, PID, and process name. - Executes the local command `id` and logs the result. - Uses `ActivityThread.currentApplication()` to obtain an application context in the compromised process. - Creates a notification channel and posts a notification proving code execution in that process. - Attempts a stronger privileged action: creating and committing a `FabricatedOverlay` through `OverlayManager`, setting `android:integer/config_multiuserMaximumUsers` to `100`. The README states this should succeed on vulnerable systems and can be verified with `adb shell cmd overlay lookup ...`. Repository structure: - `README.md`: exploit description, test instructions, and links to the Android June 2026 fix. - `app/src/main/java/top/canyie/transitionplayer/Main.java`: exploit trigger/orchestrator. - `app/src/main/java/top/canyie/transitionplayer/ShellCodeReceiver.java`: payload executed in target process. - `app/src/main/java/android/...`: stub hidden-framework interfaces/classes required for compilation. - Standard Gradle/Android project files and resources. Overall purpose: this is a local Android privilege/context-confusion exploit PoC demonstrating that a leaked `IApplicationThread` handle from the transition animation mechanism can be abused to schedule execution of attacker-controlled code in another process, with the included demonstration culminating in fabricated overlay injection.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
No public activity tracked yet. Mallory keeps watching.
No public activity observed for this vulnerability.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.