WhatsApp Lock Screen Bypass on Android: How an Incoming Video Call Exposes Your Full Photo Gallery and How to Block It

A locked smartphone is supposed to be a sealed smartphone. Yet a behavior disclosed on September 1, 2026 by security researcher Jose Rodriguez shows that anyone holding a locked Android device can browse its entire photo gallery simply by placing a WhatsApp video call to it and walking through the call’s own interface — no PIN, no pattern, no biometric, and no technical skill required. The issue has been reported to both Meta and Google, reproduced in independent testing on devices running Android 16 and Android 17, and remains unpatched at the time of writing.

This is not a remote zero-click exploit and it is not a hidden developer backdoor. Rodriguez is explicit about that: “This is in plain sight. It’s not hidden, not a secret feature. Not a hack”. It is something arguably more instructive for platform security — a chain of perfectly legitimate features (incoming-call UI, call effects, Meta AI backgrounds, photo editing) that, when composed, walk straight through the lock screen’s trust boundary. Below is a complete technical breakdown of the attack chain, the Android platform mechanics that make it possible, the device and permission conditions that decide whether you are exposed, and the mitigation you can apply in under a minute.

What’s Happening

When a locked Android phone receives a WhatsApp video call, the call screen is displayed over the keyguard and is fully interactive — by design, so that users can answer urgent calls without unlocking. From that call screen, the person holding the phone can open the effects menu, switch to the backgrounds tab, tap “Create with Meta AI,” choose “Edit photo,” and land in a gallery view that renders the device’s photo library without any authentication challenge. If WhatsApp holds the standard “Photos and videos — Always allow all” permission that most users grant for ordinary messaging, that gallery view is the entire library: every photo and video on the device, scrollable and viewable in full screen while the phone technically remains locked.

From Ringtone to Full Gallery in Five Taps

The complete attack chain, as demonstrated by Rodriguez and independently reproduced by Notebookcheck, is as follows:

1. Prerequisites. The attacker needs brief physical access to the locked Android phone and knowledge of its WhatsApp number — a scenario that matches a partner, roommate, colleague, or anyone handed the device “for a second,” not a stranger on the internet.
2. Trigger. The attacker places a WhatsApp video call to the device from their own phone. The locked device renders WhatsApp’s full-screen call UI over the keyguard.
3. Answer. The attacker swipes up to accept the call — answering a call is one of the deliberate exceptions the lock screen grants, and it requires no authentication.
4. Navigate. On the active call screen, the attacker taps the effects icon, switches from the default filters tab to Backgrounds, and taps “Create with Meta AI.”
5. Bridge into media. In the Meta AI sheet, selecting “Edit photo” opens a gallery picker. On affected devices, no keyguard check is performed at any point in this chain, and the picker renders the full Recents media grid backed by WhatsApp’s READ_MEDIA_IMAGES grant.

Notebookcheck’s testers confirmed unrestricted browsing of personal images on a Pixel 6 Pro running Android 17 with the latest security patch, emphasizing that this is not a question of an outdated device or a missing patch level. The entire sequence takes roughly fifteen seconds, and every step uses stock, visible UI elements — which is exactly why Rodriguez stresses that it is “in plain sight.”

Why the Lock Screen Can’t Stop It: Full-Screen Intents and a Composed Trust Boundary

Understanding why Android’s keyguard tolerates this requires looking at three platform mechanics that each behave correctly in isolation but fail when composed.

Full-screen intents put WhatsApp’s own UI over the keyguard

Incoming VoIP calls on Android are surfaced through the USE_FULL_SCREEN_INTENT (FSI) permission, which lets an app launch a full-screen activity directly over the lock screen so a call can be answered instantly. Since Android 14, Google treats FSI as a special, restricted permission: the Play Store automatically revokes it for any app that is not a calling or alarm app. WhatsApp is a calling app, so it legitimately retains the permission — and its call activity is displayed with the window flags (SHOW_WHEN_LOCKED, turn-screen-on) that make it interactive while the device is locked. Everything up to this point is intended behavior.

The confused deputy: the call activity inherits the app’s full privilege set

The subtle problem is that the lock-screen call UI is not a sandboxed, reduced-privilege surface. It is an activity belonging to the WhatsApp process, carrying every permission the user has granted the app — camera, microphone, and, critically, READ_MEDIA_IMAGES/READ_MEDIA_VIDEO. Android’s keyguard model assumes that the surfaces exposed over the lock screen are narrow (answer, decline, reply-with-message). It does not re-evaluate privilege when that surface offers in-app navigation into other parts of the app. So when the call screen links to the effects editor, and the effects editor links to the Meta AI sheet, and the Meta AI sheet links to a media picker, each hop is an intra-app navigation that inherits the app’s already-granted MediaStore access. Security researchers call this class of failure a confused deputy: a trusted interface (the call screen) is deputized to act on the lock screen’s behalf, and it ends up vouching for content it was never meant to expose.

The Meta AI bridge: a cosmetic feature becomes a gallery door

The final link is the “Create with Meta AI” background tool, and specifically its Edit photo option. A live camera preview or a set of synthetic backgrounds is harmless on a locked device; an editor for existing photographs is a fundamentally different capability, because its input surface is the media library itself. As security analysis of the disclosure puts it, no single feature in the chain looks extraordinary — answering a call, changing a background, editing a photo, and granting media access are all legitimate actions — and the failure lives in the path between them, where the locked state is not propagated as a constraint from one trusted interface to the next. The picker that opens queries MediaStore with the app’s full-access grant and renders everything it returns, with no check that the current user session has ever passed the keyguard.

The Deciding Precondition: WhatsApp’s Photo Permission State

The bypass has a hard gate, and it is the permission model Android introduced with Android 14’s Selected Photos Access. WhatsApp must already hold photo access for the gallery view to return content, and the mode of that access determines the blast radius:

Permission state (Settings → Apps → WhatsApp → Permissions → Photos and videos)	What WhatsApp’s MediaStore queries return	Behavior of the lock-screen call path
Always allow all (READ_MEDIA_IMAGES granted in full)	The complete photo and video library	Full gallery browsable from the call screen — the vulnerable configuration
Allow limited access (READ_MEDIA_VISUAL_USER_SELECTED)	Only the items the user explicitly selected	The picker renders at most the selected subset; widening access requires an explicit system re-selection prompt
Don’t allow	Nothing	The media bridge returns no content; the attack chain dead-ends

Under the hood, Android 14 (API 34) added the READ_MEDIA_VISUAL_USER_SELECTED permission so that apps targeting modern SDKs can operate in partial-access mode, where the system filters MediaStore results to the user’s selection and the app must handle reselection flows. In compatibility mode, temporary URI grants for selected media even expire when the app moves to the background — a design that assumes media access is a scoped, user-curated capability, not a permanent window. The WhatsApp bypass is what happens when an app with the legacy-style “allow all” grant exposes its media surfaces on a lock-screen-reachable activity: the platform’s filtering never engages, because the user never narrowed the grant.

This is also the honest place to state the limitation of the mitigation. With Allow limited access, a determined attacker holding the phone could, in theory, tap through the system’s “Allow WhatsApp to access more photos?” re-selection prompt that appears when the app requests additional media. The exposure therefore collapses from “silent, complete gallery browsing” to “an explicit, visible system dialog that expands access only if actively confirmed” — a materially different risk, and one that Don’t allow removes entirely, at the cost of re-granting access whenever you genuinely need to share media.

OEM Fragmentation Decides Who Is Exposed

One of the most important findings from independent testing is that the bypass is not uniform across Android. Notebookcheck’s matrix showed three different outcomes on current software:

• Google Pixel 6 Pro, Android 17 (latest security patch): Vulnerable. The full gallery rendered without authentication.
• Oppo K13, ColorOS 16 (Android 16): Vulnerable. Same unauthenticated gallery access.
• Samsung Galaxy S25 Ultra, One UI 8.5 (Android 16): Not vulnerable. Tapping the Meta AI button bounced the user back to the keyguard, demanding a passcode or biometric.

Two devices on the same Android version producing opposite results tells us the flaw sits in the interplay between WhatsApp’s activities, the OEM’s lock-screen containment policy, and the media picker implementation — not in a single AOSP line of code. Samsung’s behavior suggests its keyguard policy re-asserts authentication when a locked-state activity attempts to launch content-accessing surfaces, while stock Android and ColorOS trust the calling app’s own navigation. Analysis of the disclosure frames this precisely: the same application feature crosses different trust boundaries depending on how the operating system and the manufacturer contain it.

iOS is not affected. On a locked iPhone, incoming WhatsApp calls are rendered through Apple’s CallKit system interface rather than WhatsApp’s custom call activity, so the effects/Meta AI editor — and the gallery bridge inside it — is simply unreachable before unlock.

The Real-World Threat Model: Stalkerware, Not Cybercrime

It is tempting to dismiss a physical-access bug as low severity, and in a CVSS sense the attack vector is indeed physical rather than networked. But physical-access flaws are precisely the class that matters most in intimate-partner surveillance and stalkerware scenarios, where the attacker is a person who shares your space, knows your number, and gets ten unattended seconds with your phone on a table or charger. Rodriguez’s own framing, echoed in video analysis of the issue, is explicitly a stalkerware use case: a friend or spouse with the device in hand and the number memorized can exfiltrate private photographs in about fifteen seconds using nothing but stock UI taps. The same calculus applies to coerced handovers at checkpoints, workplace “let me see your phone” moments, and thieves who hold a locked device long enough to place a call to it from a second handset.

Disclosure Status: Reported to Meta and Google, Patch Pending

Rodriguez published the demonstration on September 1, 2026 and stated that the behavior had already been reported to both Meta and Google. As of publication, neither vendor has shipped a fix, and the behavior reproduces on current builds — including, per testing, the latest Android 17 security patch. The researcher is not a drive-by disclosure account: in late 2023 he reported a separate Android 13/14 lock screen bypass that was covered by Bitdefender and Security Affairs, giving him an established track record on exactly this bug class — legitimate UI compositions that defeat the keyguard. That history matters, because lock-screen bypasses have repeatedly followed the same pattern on Android: an emergency dialer, a settings shortcut, or a notification surface quietly vouching for a content-accessing activity until a researcher chains them together. Until Meta narrows the call screen’s media surfaces or Google tightens keyguard containment for locked-state activities, the permission change below is the only user-controlled control.

How to Protect Yourself: Block the Bypass in Under a Minute

The mitigation demonstrated by Rodriguez and echoed by other security researchers, including Lukas Stefanko, is to move WhatsApp from full photo access to the scoped model:

1. Open Settings on the Android device.
2. Go to Apps → WhatsApp → Permissions (on some skins: Security & Privacy → Privacy → Permission manager).
3. Tap Photos and videos.
4. Change the setting from Always allow all to Allow limited access — curating the selection — or to Don’t allow for the strictest posture.

With limited access in place, the attack chain still reaches the Meta AI sheet, but the gallery behind it can return at most the handful of items you pre-selected, and any attempt to widen access surfaces an explicit system dialog instead of silently rendering your library. With Don’t allow, the bridge returns nothing at all; the trade-off is that sharing media from within WhatsApp will require granting access per session through the system picker, which many privacy-conscious users consider a fair price.

Defense-in-depth options worth considering alongside the permission change:

• On Samsung/One UI devices, the OEM keyguard already redirected testers to authentication, but apply the permission narrowing anyway — OEM behavior changes with updates and should not be your only control.
• Review full-screen intent and lock-screen notification settings for WhatsApp if your Android build exposes them (typically under the app’s notification settings). Demoting incoming calls from full-screen lock-screen UI to a standard notification means answering requires unlock, which severs the attack chain at step three — at the cost of call convenience.
• Treat “locked on the table” as an untrusted state in sensitive environments. The entire attack presupposes seconds of unsupervised physical access.
• Watch for vendor updates. Once Meta or Google ships a fix — whether by gating the Meta AI media surfaces behind keyguard state or by enforcing picker containment for locked activities — update promptly.

Frequently Asked Questions

Can someone access my photos remotely through a WhatsApp call?
No. The caller cannot browse your gallery from their own device. The attack requires a person to physically hold and operate your locked phone while the call connects; the remote caller sees only the video stream your camera sends.

Is iPhone affected?
No. Locked iPhones render incoming WhatsApp calls through Apple’s CallKit system interface, which does not expose WhatsApp’s effects editor or Meta AI photo bridge before unlock.

Does the bypass work if I never granted WhatsApp photo access?
No. The gallery view is backed by the app’s media permission. With Don’t allow in place, the chain reaches a picker with nothing to render.

Are all Android phones vulnerable?
No. Independent testing found a Pixel 6 Pro on Android 17 and an Oppo K13 on ColorOS 16 vulnerable, while a Samsung Galaxy S25 Ultra on One UI 8.5 correctly demanded authentication at the Meta AI step. Exposure depends on the OEM’s lock-screen containment as much as on the OS version.

Has WhatsApp fixed this?
Not yet. The behavior was reported to Meta and Google and publicly disclosed on September 1, 2026; no patch had shipped at the time of writing, which is why the permission-based mitigation is the recommended interim control.

Will “Allow limited access” break normal WhatsApp usage?
Partially, by design. You can still send the photos you selected, and Android shows a re-selection prompt when the app needs more — which is exactly the friction that closes the bypass.

The Bottom Line

This disclosure is a textbook reminder that mobile security lives in the seams between features, not in the features themselves. A full-screen call intent, an effects carousel, an AI background editor, and a legacy-wide media grant are each defensible in isolation; composed, they let a locked phone hand over its most personal content to whoever is holding it. Until Meta and Google ship a fix, the single most effective action an Android user can take is thirty seconds of settings hygiene: demote WhatsApp to Allow limited access — or Don’t allow — and let the platform’s scoped media model do the job the lock screen was supposed to do.