A single malicious notification from WhatsApp, Slack, SMS, Signal, Instagram, or Messenger could have taken over Google Gemini’s voice assistant on Android, forcing it to open a victim’s linked windows, forge a message from their manager, drop the phone into a Zoom call, or silently corrupt its long-term memory.
No harmful app needs to be installed on the device. The assistant simply had to interpret a hostile notification as legitimate context.
The findings, released by SafeBreach researcher Or Yair, build on the team’s prior “Invitation Is All You Need” study, which achieved comparable results using malicious Google Calendar invitations. Following that work, Google strengthened Gemini’s defenses against indirect prompt injection.
Yair discovered a method to circumvent those updated protections. Google has since applied a fix, SafeBreach has not assigned a CVE to the issue, and there is no indication that this technique was ever exploited in real-world attacks.
On Android, Gemini’s Utilities feature can scan and respond to your notifications, including those from apps like WhatsApp. This capability is not present on iOS or the web, making the attack vector exclusive to Android. Yair determined that the agent responsible for reading those notifications interprets their content as actionable instructions. As a result, any service capable of sending a notification to a phone can deliver a malicious payload—an attack surface Yair described as “effectively infinite.”
At the very least, this allows an attacker to alter Gemini’s responses, such as fabricating a message from a specific contact. Delivered by voice while someone is driving and not glancing at the display, a statement like “your manager asked you to upload the documents to this Drive folder” would be difficult to question. The silent variant is even more dangerous: the malicious payload activates after Gemini has already loaded genuine notifications, enabling it to seize the first real sender’s name in the queue and attribute the fake message to them.
Manipulating output is one concern. Triggering actual functions—like opening a window or launching an app—is precisely what Google’s post-“Invitation” safeguards were designed to prevent. Yair’s analysis, based on black-box testing, revealed that when a “Yes” is required to approve a sensitive action, a verification step evaluates both the user’s response and Gemini’s most recent output to determine whether that “Yes” is appropriate. When a delayed instruction is injected unexpectedly, Gemini rejected it consistently.
The workaround, which Yair called Fake Context Alignment, executes two deceptions simultaneously: a convincing authorization prompt for the security verification, and a benign conversation for the user.
- Obfuscated. Gemini poses the real authorization question in a language the victim doesn’t understand, for example Chinese (“Do you want to open the window?”), then follows up in English with something harmless like “Is that all you needed?” The user dismisses the foreign text as a glitch, responds “Yes,” and the backend associates that “Yes” with the Chinese question.
- Muted. Gemini’s text-to-speech engine omits hyperlinks concealed behind clickable text. So the malicious question is embedded in a link the assistant never vocalizes. Gemini says, “I’m sorry, I encountered an error, are you there?” while the screen quietly displays “Do you want to open the window?” The driver replies “Yes,” the verification step reads the on-screen text, and the windows open.
Merge the two—a Chinese authorization prompt tucked inside a muted link—and you get a payload that sounds like an ordinary English conversation while bypassing Google’s latest security checks.
Beyond the authorization barrier, the consequences mirrored the earlier research and extended even further:
- Smart home manipulation via Google Home: controlling connected windows, heating systems, and lighting.
- Surveillance and downloads. Opening web addresses to pinpoint a victim’s location by IP address or initiate file downloads.
- Spreading into other applications. In the demonstration, Yair configured a seemingly safe domain to redirect to a Zoom app link, and Gemini followed it without asking, forcing the phone to join a meeting and broadcast video. According to Yair, this worked because Gemini had already trusted the domain after it previously served clean content, then complied with the subsequent redirect. SafeBreach emphasizes that its own domain never redirected to Zoom; the redirect was executed on a local server running on the test device.
- Memory corruption, something the earlier calendar-based technique never achieved. Fake Context Alignment fabricates user consent, allowing Gemini to permanently store a fact chosen by the attacker. In the demonstration, it recorded the victim’s name as “Danny.” Because this memory is tied to the account, the corrupted data isn’t confined to the phone—it travels with the victim wherever they access Gemini under that account.
- Persistence through scheduled actions, such as a recurring task set to read the victim’s recent messages every evening at 8 PM.
SafeBreach submitted the findings to Google’s Vulnerability Reward Program on August 17, 2025. Google classified it as high priority and confirmed on November 14, 2025, that improvements to its content-classifier had mitigated both the notification injection attacks and the Delayed Tool Invocation bypass.
Since the fix is applied server-side, there is no app update required. The only measure users can take is controlling whether Gemini reads notifications at all: disable the Utilities app within Gemini’s Connected Apps settings, or revoke the Google app’s “Notification read, reply & control” permission on Android.
