TL;DR: On a fully patched Pixel 6a running Android 16, an attacker with physical access can escape the lock screen in under 60 seconds using Google Gemini’s Deep Research feature — no PIN, no password, no biometrics. This is a bypass of a previously patched vulnerability rewarded by Google VRP.

A Bit of Context

Back in 2024, I found and reported a lock screen bypass involving Google Gemini to the Google Vulnerability Reward Program. Google acknowledged it, rewarded it, and published details in September 2025.

I assumed the chapter was closed.

Then in April 2026, on a fully updated Pixel 6a with the March 2026 security patch, I reproduced the same class of vulnerability using a different path. Same boundary. Different door.

What’s at Stake

An attacker with brief physical access to a locked Android device can without ever entering a PIN, pattern, or biometric switch Google accounts, modify security settings, read and exfiltrate Gemini conversation history, and set up persistent lock screen messaging and calling capabilities.

The device stays locked the entire time. No failed unlock attempts are logged. The victim has no indication anything happened.

How It Works

Step 1. Lock the device. Confirm PIN is required to access the home screen.

Step 2. Long-press the power button to invoke Gemini on the lock screen. This is by design — no authentication required at this step.

Step 3. Long-press the gear icon inside the Gemini overlay. Additional options surface.

Step 4. Select “Deep Research.” This is the pivot point. The full Gemini application launches — transitioning out of the constrained lock screen overlay into a full app context.

Step 5. Immediately press and hold the “+” icon. This races the re-authentication dialog that would normally appear, preventing it from taking focus. The prompt never completes & You’re in.

Proof of Concept

Video Demonstration

The video walks through the full chain — from a locked device through account switching, settings modification, and conversation access — with zero authentication at any step.

Root Cause

There are three things going wrong simultaneously:

1. No authentication check on context transition. When Deep Research launches the full Gemini app, Android does not verify the device is unlocked before granting access to privileged functionality. The launched from lock screen flag is simply not propagated to child activities.

2. A raceable re-authentication dialog. The re-auth prompt is a UI dialog — not a system-level gate. Holding the “+” icon at the right moment prevents it from taking focus. It’s a software lock with a physical bypass.

3. The original patch was too narrow. The previous fix addressed one specific navigation path. It didn’t address the underlying principle: any Gemini sub-feature capable of launching a full app context is a potential escape route.

The root issue isn’t Deep Research specifically. It’s that the lock screen boundary has no hard enforcement once you’re past the initial overlay.

What an Attacker Can Do

Once inside, the attack surface is significant:

• Account reconnaissance — tap the avatar to see every Google account signed into the device
• Persistent downgrade — enable “Perform actions on lock screen,” “Send messages,” and “Make calls” in Gemini settings. Every future lock screen interaction now has expanded capabilities — for anyone
• Data exfiltration — Gemini conversation history may contain sensitive personal, medical, financial, or professional queries. Share it to any external contact in seconds
• Anti-forensics — delete conversations after reading them. No trace left

The entire operation takes under 60 seconds and requires zero technical skill after the initial discovery.

The Fix

Three things need to happen:

1. Hard system gate, not a UI dialog. Any transition from a lock screen assistant overlay to a full application context must require authentication enforced at the WindowManager/system level — something that cannot be raced or suppressed by a UI interaction.
2. Feature restriction in lock screen context. Deep Research, account switching, settings, history access, and share/delete must be disabled when the device is locked — regardless of how the user navigated there.
3. Flag propagation. The launched from lock screen context must be inherited by every child activity and fragment. No sub-feature should be able to shed it.

And given this is the second bypass of the same boundary: a full audit of every Gemini entry point accessible from the lock screen is overdue.

Final Thought

Lock screen security is one promise an OS makes that users never think to question. When AI assistants start opening doors inside that boundary, the attack surface grows in ways that are hard to enumerate — and patchwork fixes will keep falling behind.

The right solution is a single, hard, non-raceable gate between “the overlay” and “the app.” Until that exists, the boundary is a suggestion.

Found this useful? Follow me for more security writups.