The Gemini Trifecta: three injection paths into Google's AI assistant

What happened

Tenable Research disclosed three separate vulnerabilities across Google's Gemini surfaces in September 2025, collectively named the Gemini Trifecta. Each exploited the same underlying weakness — Gemini treating attacker-influenced data as trusted instruction — but through a different channel.

Gemini Cloud Assist (log-to-prompt injection). An attacker could hide a malicious prompt inside an HTTP request header such as User-Agent. Because Cloud Assist summarizes raw logs directly, the hidden instruction was processed as a command when a user asked Gemini to summarize their logs — enabling actions like querying cloud assets or surfacing IAM misconfigurations, with exfiltration via rendered hyperlinks.

Search Personalization Model (search injection). Malicious JavaScript on an attacker's site could inject fabricated queries into a victim's Chrome search history. When the victim later used Gemini's personalization features, the planted "history" was processed as legitimate context, letting the attacker leak saved information and location data.

Browsing Tool (exfiltration). When Gemini summarized a webpage, crafted content could drive the browsing tool to embed sensitive user data into a request sent to an attacker-controlled server — without needing a visible link or image to render.

Google remediated all three: it stopped rendering hyperlinks in log-summarization responses, rolled back the vulnerable search-personalization model, and hardened the browsing tool against exfiltration from indirect injections.

Root cause

• LLM01 Prompt Injection (indirect). In every case Gemini failed to separate trusted user intent from untrusted data — log text, browser history, or page content — and executed embedded instructions.
• LLM02 Sensitive Information Disclosure. Each path terminated in data leaving the user's trust boundary: cloud metadata, saved personal data and location, or page-derived data smuggled through the browsing tool.

How it would have been caught

Injection probes seeded into each untrusted channel — a poisoned log line, a planted search-history entry, a booby-trapped webpage — combined with egress monitoring for outbound requests would have surfaced all three. Frameworks such as PyRIT, Garak, and Promptfoo automate the indirect-injection tests; the load-bearing check is confirming no attacker-controlled data leaves via a rendered link or tool call.

How to prevent it

• Treat logs, browser history, and fetched pages as untrusted data in labelled blocks, never as instructions.
• Disable or sanitize model-rendered hyperlinks and tool-issued outbound requests to non-allowlisted hosts.
• Apply defense in depth across every data channel an assistant ingests, not just the obvious chat input.

The Breachwire test (red → green)

For each channel, plant an injection payload and confirm data exfiltrates (three RED controls proving each vector). Apply the per-channel containment, then confirm each payload no longer leaks, while benign log summaries, personalized results, and page summaries still work (the positive controls guarding against a break-the-feature false green).