genai
SECURITY LAB
IncidentsVector & embedding

GeminiJack: A Shared Google Doc Could Poison Gemini Enterprise's Retrieval

Status: Reported 5 June 2025; Google changed Gemini Enterprise retrieval and split off Vertex AI Search before the 8 Dec 2025 disclosure; research proof of concept, no reported exploitation
Sources checked October 2026
On this page

In Noma's proof of concept the attacker never touched the victim's account. They shared a document and waited for someone to search for budgets.

WhenReported June 2025; disclosed 8 December 2025
TargetGoogle Gemini Enterprise and Vertex AI Search
ResearcherSasi Levi, Noma Labs (Noma Security)
TechniqueIndirect prompt injection through shared Workspace content retrieved by RAG; image-request exfiltration
StatusFixed by Google before disclosure; Vertex AI Search separated from Gemini Enterprise
ResultResearch proof of concept; zero-click leak of Gmail, Calendar and Docs data
Attack flow
  1. 1An outsider shares a Doc, invite or email carrying hidden instructions into the company
  2. 2An employee runs a routine Gemini Enterprise search and retrieval pulls the item into context
  3. 3Gemini searches Workspace data and leaks the results through an external image request

What happened

On 8 December 2025, Noma Labs, the research team at Noma Security, published GeminiJack, a zero-click flaw in Google's Gemini Enterprise and in Vertex AI Search. Anyone who could put a Google Doc, a calendar invitation or an email in front of someone at a target company could plant instructions in the material Gemini Enterprise indexes. When an employee later ran an ordinary search, Gemini would read those instructions, search the Gmail, Calendar and Docs data that employee could reach for sensitive material, and send what it found to the attacker. The employee did nothing but search.

Noma reported the issue on 5 June 2025, the day it found it. Google confirmed it in August, reworked how both products use their retrieval and indexing layers, and moved Vertex AI Search off Gemini Enterprise's LLM and RAG workflows entirely. This was a research demonstration with a proof of concept; no exploitation in the wild has been reported.

How the attack worked

Gemini Enterprise answers questions with retrieval-augmented generation over the sources an organisation connects, such as Gmail, Calendar and Docs. Retrieval pulls items that match the query into the model's context. The attack used that path in four stages.

  • Plant. The attacker shares a Doc, sends a calendar invite or emails someone inside the company, with instructions in the content. Noma notes that a Doc title or an email subject alone could carry them.
  • Wait. The item is indexed with the rest of the organisation's data. Nothing happens until it becomes relevant.
  • Retrieve. An employee asks a routine question, for example about budgets. Retrieval ranks the poisoned item as relevant and places it in context next to legitimate results.
  • Act and leak. The model treats the planted text as its task: it searches the data the user can reach for generic sensitive terms, then writes the results into an image reference pointing at an attacker-controlled server. The browser loads the image, and the data leaves in the request.

The attacker needed no knowledge of the company's people or projects. Generic terms were enough, because the assistant did the searching with the employee's own access.

Nothing for existing tools to seeNoma points out that the attack needed no malware, no phished credentials and no click. Data loss prevention would see only an AI query and an image load.

Root cause

Noma described GeminiJack as an architectural weakness rather than a conventional bug. The retrieval layer put content from outside the organisation into the same context as the user's request and private data, with nothing marking it as untrusted text rather than instructions. The model could read everything the user could reach, and its output could reference external URLs that the client fetched automatically. Untrusted input, broad data access and an outbound channel in one pipeline is all exfiltration needs, and indexing shared-in content gave an outsider the first of the three for free.

What a test would have caught

A poisoning test for an enterprise RAG assistant is cheap to run. From an outside account, share a document that is on-topic for a common query and carries an instruction, wait for indexing, then ask that query as an internal user. Check two things: whether the assistant acts on the planted text, and whether its answer ever contains a URL or image reference to a host the organisation does not control. Either result means the same chain is open. Repeat with an email subject and a calendar description, since each connector is a separate way in.

How to prevent it

  • Track provenance at retrieval. Label content from external senders and shared-in documents, and keep it out of the grounding set or clearly fenced as data.
  • Never take tasks from retrieved text. The model should act only on the user's request, and follow-up actions such as a second search should be checked against that request.
  • Close the outbound channel. Do not render images or links to arbitrary hosts in assistant output; allowlist a small set of domains you own.
  • Scope connectors. Give the assistant only the data sources a use case needs, and log what each answer retrieved.

Feel it yourselfThe replay lab has you contribute an on-topic note to a shared knowledge base so the assistant retrieves it and obeys the instruction inside, the same retrieval-time trust failure GeminiJack exploited.

FAQ

What was GeminiJack?

A zero-click vulnerability in Google Gemini Enterprise and Vertex AI Search, disclosed by Noma Labs in December 2025. Instructions planted in a shared Google Doc, calendar invite or email were indexed with company data and executed when an employee ran an ordinary search, leaking Gmail, Calendar and Docs content. Google fixed it before disclosure; it was a research proof of concept.

How did a shared document leak data with zero clicks?

Gemini Enterprise retrieves matching items from connected Workspace sources into the model's context. A poisoned item that matched a routine query, such as one about budgets, was pulled in next to legitimate results, and the model followed its text: it searched the user's data for sensitive terms and placed the results in an image URL on the attacker's server, which the browser fetched automatically.

How do you protect an enterprise RAG assistant from poisoned documents?

Track where retrieved content came from and keep external or shared-in items out of the grounding set or clearly fenced as data. Only take tasks from the user's request, not from retrieved text. Block rendering of images and links to hosts you do not own, scope connectors to what each use case needs, and test by planting on-topic instructions from an outside account.

Replay this attack
Contribute an on-topic note to a shared knowledge base so real retrieval pulls it into context and the assistant obeys the instruction inside — the retrieval-time trust failure behind GeminiJack, minus its image-request exfiltration.
Open the live lab
A live, sandboxed lab. It recreates the technique, not this exact product.