Android is known for being secure, especially when it comes to locking your phone and keeping strangers out. But sometimes, a small mistake in the way the code works can open doors that should definitely stay shut. That’s what happened with the newly disclosed CVE-2025-26428 — a logic error in the LockTaskController.java file. This flaw makes it a lot easier for someone with your device in their hands to bypass your locked screen. In this post, I’ll break down what went wrong, how it can be abused, and what you should watch out for.

What is CVE-2025-26428?

At its core, CVE-2025-26428 is a lock screen bypass issue. It happens in Android’s LockTask mode, which is a feature used by apps to pin themselves on the screen (think of a kiosk mode where only one app is allowed to run). There is a critical logic error in the startLockTaskMode() method inside LockTaskController.java. This error can allow someone to sidestep the lock screen under certain conditions, leading to a serious escalation of privilege—all without needing root or tricky malware. All that’s needed is your device and a few taps.

This bug was made public in the Android Security Bulletin, June 2024

> https://source.android.com/docs/security/bulletin/2024-06-01

What Is LockTask Mode and Why Does It Matter?

LockTask mode is often turned on by kiosk apps, parent controls, or devices used by businesses for limited tasks. When an app is in LockTask mode, the idea is that nothing else should run — and definitely not the home screen or any system menus. But to keep things safe, if the device locks (for example, times out and you need to enter your PIN or pattern), it should always ask for your credentials before letting you back in.

The bug in CVE-2025-26428 centers around how this switch between LockTask mode and the lock screen happens.

The Error in Code: What Went Wrong?

Let's look at a simplified version of the code inside LockTaskController.java. Here’s how it’s supposed to guard your screen:

// LockTaskController.java - simplified example
void startLockTaskMode(Task task) {
    // ... other security checks ...
    if (deviceIsLocked()) {
        showLockScreen();
        return;
    }
    doLockTask(task); // Start the kiosk mode
}

However, the problem arises because the logic doesn’t correctly handle the sequence of user actions. In the vulnerable version, the state between checking for a lock and actually starting LockTask can fall out of sync — especially if the user acts fast or with particular timing.

Here’s the buggy logic (simplified)

void startLockTaskMode(Task task) {
    // ... other checks ...
    if (!deviceIsLocked()) {
        doLockTask(task); // Start kiosk
    } else {
        showLockScreen();
        // BUT: lockTask mode is NOT properly delayed until after authentication!
        doLockTask(task); // This runs even when it shouldn't!
    }
}

Because doLockTask() happens regardless of authentication, the app can end up in LockTask mode *over* the lock screen. If an attacker grabs your device, triggers LockTask mode, and then interacts in a specific way, they can sometimes dismiss the lock screen and get access to the device.

User interaction (the attacker needs to physically use the device).

- The target device is set to use LockTask/Kiosk mode.

Exploitation steps

1. Attacker gets physical access to an Android device in LockTask/kiosk mode.

The device is locked (screen times out, or user locks it).

3. The attacker attempts to exit/re-launch LockTask using power button or the specific multi-tap sequence designed for unlocking the kiosk.
4. Due to the bug, Android's lock screen validation and the LockTask state get out of sync: the app regains focus, sometimes over the top of the locked state.
5. Result: The attacker can interact with the pinned app or even the entire device *without needing to enter a PIN, pattern, or password.*

This method will not always work on every device or every LockTask app — but reports show that the right timing and sequence reliably bypass the lock on many Android versions released before June 2024.


## Demo Code/PoC Snippet

Here’s a PoC (Proof-of-Concept) snippet showing how LockTask can be (mis)used

// In a kiosk app's main Activity
@Override
protected void onResume() {
    super.onResume();
    // Automatically re-enter LockTask mode
    startLockTask();
}

When the app re-enters the foreground after the lock screen, due to the buggy logic, the user lands *inside* the app instead of being made to unlock the device first!

Fix and Mitigation

Google has patched this logic flaw in June 2024. The fixed logic explicitly requires successful authentication before LockTask mode is re-enabled:

void startLockTaskMode(Task task) {
    if (deviceIsLocked()) {
        showLockScreen();
        // return immediately, don't enable LockTask!
        return;
    }
    doLockTask(task);
}

What you can do now

- Make sure your Android system (especially if you use kiosk/LockTask mode) is updated with the June 2024 security patches.
- If you use custom kiosk apps, consider double-checking that the app doesn’t automatically restart itself after the lock screen without user verification.

References & Further Reading

- Android Security Bulletin — June 2024
- Android LockTaskController (AOSP source)
- CVE-2025-26428 at cve.org (check for updates)
- How Kiosk LockTask works (Android docs)

Final Thoughts

Sometimes, security isn't about big complex hacks, but tiny mistakes in logic. CVE-2025-26428 reminds us that even when the lock screen *looks* secure, the sequence of app states and system checks *really* matters. If you manage devices in a business or lock your own with kiosk mode, patch now — and know that, for a while, it was much too easy for someone to sneak past your Android lock.

Timeline

Published on: 09/04/2025 18:15:41 UTC
Last modified on: 09/05/2025 19:12:05 UTC