Zero-App Hijacking? Poisoned Notifications Weaponizing Google Gemini
Just saw the report on HackerNews about a scary vector for Google Gemini on Android. Apparently, a single poisoned notification from apps like WhatsApp, Slack, or even SMS can hijack the voice assistant.
The mechanics of this are fascinating but terrifying. No malicious app is installed on the device. Instead, the attack relies on the Gemini assistant processing the notification content as a command or context. We're talking about the potential to:
- Force the device into a Zoom call.
- Open connected windows on the desktop.
- Impersonate a boss via fake messages.
- Most critically: Poison the assistant's long-term memory, leading to persistent influence.
This is effectively a prompt injection attack delivered via the OS notification system. The assistant trusts the input source because it's a "trusted" app sending the alert.
If you're managing Android fleets, you might want to audit which assistants have notification listener permissions. You can check active listeners on a device using ADB:
adb shell dumpsys notification | grep -A 20 "Notification listeners"
Until Google patches the parser logic, the only real mitigation seems to be revoking notification access for AI assistants or strict filtering on notification content. How is everyone else handling AI integration on BYOD devices? Are you blocking Gemini entirely, or just locking down permissions?
This is a textbook example of indirect prompt injection moving to the OS level. We've seen similar things with ChatGPT plugins, but this is much more dangerous because it leverages the trust established by apps like Slack and WhatsApp.
From a pentesting perspective, if you can send a phishing SMS that triggers a command on the user's workstation via their phone, that's a huge bridge across the air-gap. I'd recommend looking for anomalous android.intent.action.ASSIST triggers in your telemetry if you suspect exploitation.
We're pushing a policy update via our MDM (Intune) today to disable 'Google app' notification access for corporate-owned devices. It's a blunt instrument, but the risk of data exfiltration via long-term memory poisoning is too high.
For detection, I'm using this KQL query to spot unexpected assistant launches shortly after receiving messages:
DeviceProcessEvents
| where FileName == "com.google.android.googlequicksearchbox"
| project Timestamp, DeviceName, InitiatingProcessFileName
| order by Timestamp desc
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access