Gemini Notification Injection Shows Chat Is Agent Input

SafeBreach Labs published research on June 3, 2026 showing a notification-based indirect prompt-injection path against Google Gemini's voice assistant on Android. The demonstrated path used ordinary notifications from apps such as WhatsApp, Slack, SMS, Signal, Instagram, and Messenger. No malicious app on the device was required in the research scenario. The assistant only had to process hostile notification text as context.

SafeBreach calls the bypass Fake Context Alignment. The important practical point is broader than one assistant bug. When an AI assistant can read notifications, speak for trusted contacts, open apps, control connected devices, remember facts, or schedule actions, chat content becomes an execution input. Google mitigated the reported scenarios before publication, but the pattern should change how teams design and approve agent permissions.

SafeBreach researcher Or Yair focused on Gemini's Android voice assistant after earlier work on calendar-based indirect prompt injection. The new research moved the entry point to notifications. If an attacker could make a message notification appear on a victim's phone, and the victim later asked Gemini to read or summarize notifications, the assistant could ingest attacker-controlled text as part of the conversation context.

The report says the payloads could manipulate Gemini output, impersonate trusted contacts through spoken summaries, open URLs, cross into applications through app intents, control connected home devices in test conditions, poison long-term memory, and create recurring scheduled actions. The research also says Google handled the disclosure through its Vulnerability Reward Program and mitigated the scenarios with content-classifier improvements before the public write-up.

Most users treat notifications as passive interface elements. They glance at them, dismiss them, or ask an assistant to read them while driving or multitasking. For an LLM-powered assistant, that same notification is input text. If the assistant is allowed to turn input into actions, the distinction between a message preview and a command becomes a product security boundary.

That boundary is difficult because the message can appear to come from a trusted human contact. A fake instruction delivered through an assistant's voice can sound less suspicious than a strange link on a screen. The user may be responding to a benign spoken question while the hidden context contains a different instruction that the backend authorization logic treats as relevant.

SafeBreach describes Fake Context Alignment as a way to create two different interpretations of the same exchange. One interpretation is visible or audible to the user and looks harmless. The other is present in the model's conversation context and looks like permission for a sensitive action. In the obfuscated version, the sensitive question can be appended in a language the user is unlikely to understand, followed by a harmless question in English.

The muted version takes advantage of text that appears on screen but is not spoken by the voice assistant, such as clickable link text. The user hears a normal prompt and replies yes. The model history, however, contains the sensitive authorization question. The risk is not that a user is foolish for answering. The risk is that a system asked the user one thing and let an attacker align the reply to another.

The affected notification source list matters because it includes the communication tools people already trust: WhatsApp, Slack, SMS, Signal, Instagram, Messenger, and similar apps. This does not mean those platforms were breached or that their encryption failed. It means their notifications became a delivery channel once another product consumed them as agent context.

That is a useful mental model for community operators and enterprise teams. A secure chat product can still feed unsafe content into a downstream assistant if previews, push text, notification summaries, or reply actions are exposed to a tool with broader powers. Messaging privacy and agent security are now linked through notification handling.

For individual Android users, the response is permission review rather than panic. Check whether Gemini is the default assistant, whether Utilities is enabled, whether the Google app has notification read, reply, and control permissions, and whether Gemini can help when the phone is locked. Disable capabilities that are not useful enough to justify the risk.

For managed fleets, mobile device policy should separate assistant convenience from sensitive work profiles. High-risk users should avoid letting consumer assistants read work notifications that contain approval requests, incident details, one-time codes, client names, legal matters, or administrative actions. If assistants are allowed, test them with adversarial notification content and verify that tool calls require explicit, visible, user-understandable confirmation.

The strongest design lesson is that instructions and data need separate paths. Filters help, but the assistant should not decide alone whether a sentence from a notification is a command, a quote, a contact's message, a system instruction, or a user authorization. Sensitive actions should be gated by deterministic policy that knows the origin of the text and the action being requested.

Agent products also need memory and scheduling controls that are harder to poison than ordinary responses. A memory write, recurring task, app launch, or connected-device action should require a confirmation surface that cannot be silently altered by the same model output being evaluated. The user should see the exact action, origin, account, app, device, and recurrence before approval.

Public sources reviewed here do not show evidence of in-the-wild exploitation, and SafeBreach did not list a CVE. Google did not publish a detailed standalone incident report describing every mitigation or affected build state. That limits what can be said about exposure windows, impacted devices, and whether related assistant surfaces had the same weakness.

The uncertainty should not dilute the takeaway. The issue was patched, but the architecture pattern is still active across the market. Assistants increasingly read chat, mail, documents, notifications, calendars, browser pages, and memory stores. Every new input channel needs the same question: can hostile content from that channel cause the agent to act?