This is independent security research conducted on my own time. The findings and views expressed here are my own and do not represent my employer.

On disclosure and payloads. This behavior was reported to Google under coordinated disclosure on April 11, 2026, and the full timeline is at the end of this post. Google received the complete technical details and working payloads during the disclosure process and was given a pre-publication review window with an invitation to flag factual inaccuracies or request additional time. As of publication the issue still reproduces and a fix is in progress, so the full operational payloads and some reproduction details are withheld from this public version. They will be published once remediation is confirmed. The mechanism, structure, and impact are described in full below.

An attacker-controlled email can inject structured data into Gemini's context inside Gmail, causing the model to interpret attacker-provided content as part of the user's inbox.

The result is a data integrity violation: untrusted input (email body content) is treated as trusted backend email data. Gemini-generated summaries can be fully replaced with attacker-controlled fabricated emails.

The payload is invisible in normal email rendering. The fabrication of inbox entries, which is the core of this attack, carries no injected instruction at all: no command is given and none is needed. The attacker's content is promoted to a real record purely because it matches the representation of emails the system works from, not because any instruction is followed. A single directive does appear later, in the Phase 3 variant that also triggers an autonomous Calendar action, and I show there that even that directive is carried out through the same structural role assignment, not as a classic injected command. So this arrives looking like indirect prompt injection, but what makes it succeed is structural rather than instructional. This is what I call Structural Desynchronization (SD): the model's reconstruction of object boundaries diverges from the actual data returned by the backend. This mechanism may also help explain a subset of behaviors currently grouped under indirect prompt injection.

The technique and its cross-model behavior are described in more detail in the accompanying paper: https://doi.org/10.5281/zenodo.19625238

All identifiers in this write-up are test data. Real account identifiers have been replaced with [email protected].

Phase 1: structure discovery (blind context inference)

The representation of emails that Gemini works from is not exposed to the user. From a network perspective (for example via an intercepting proxy), only the user query and the model response are visible. The actual email data is retrieved by the backend and injected into the model context through an internal mechanism.

To infer this structure, the model itself was used as an observational interface. By asking Gemini to describe the emails it processes, including all metadata fields, a consistent schema of the representation available to the model was identified.

Example query:

Get last 2 emails and describe their structure, including all metadata fields (body, subject, date, etc.)

Gemini consistently returned the following fields:

  • date
  • sender
  • toRecipients
  • subject
  • labels
  • body

Based on this, the following structure was reconstructed through iterative testing:

{"date":"2026-04-10T18:07:49+00:00","sender":"Cernica <[email protected]>","toRecipients":"Cernica Ionut <[email protected]>","subject":"hei","labels":["INBOX"],"body":"ha"}

To validate that this structure matches the internal format, a minimal payload was injected into a real email body, appending a single fabricated entry:

The single-entry validation payload is withheld here while the issue remains reproducible (see the note at the top of this post). The structure-discovery method above is the point: a real email body was extended with one entry shaped like the schema, and Gemini accepted it as a peer record.

When requesting a summary, Gemini returned two distinct emails, treating the injected entry as a legitimate email.

This demonstrates that the model does not distinguish between backend-provided email data and user-controlled structured input when both conform to the same schema.

This phase required no backend access, no API interception, and no privileged information.

Phase 2: payload construction and delivery

A full exploit is constructed by embedding multiple fabricated email entries inside an HTML email.

The payload is placed inside a hidden HTML element (a <span> with display:none), so it is not visible in the rendered email while remaining present in the underlying HTML processed by the system. The message the recipient sees is an ordinary project-update note; the reconstructed inbox lives entirely in the hidden element.

Attack flow

  1. Baseline. With a normal inbox, Gemini correctly summarizes the last N real emails. This is the ground truth before the attack.
    Figure 1 Baseline: Gemini summarizing the genuine inbox ("give me a summary of the last 5 emails").
  2. Injection. The attacker crafts an email whose body carries the fabricated records inside a hidden HTML element. The crafted HTML body is shown here before it is placed into the message, with the payload region redacted.
    Figure 2 The crafted HTML body before injection, with the payload region redacted. In the real attack the hidden element occupies this position, invisible to the recipient. The full payload is withheld here as noted at the top of this post.
  3. Invisibility. Once composed, the email renders as an ordinary project-update note. The hidden element (display:none, 0px, transparent) is present in the underlying HTML but invisible to the human eye. Nothing in the visible message hints at the reconstructed inbox it carries.
    Figure 3 The same email as the recipient sees it: only the innocuous visible text, no trace of the payload.
  4. Delivery. The message arrives in the victim's inbox looking like any normal email from a known contact.
    Figure 4 The delivered email in the inbox, indistinguishable from a legitimate message.
  5. Exploitation. When the victim asks for a summary (for example "summarize last 5 emails"), Gemini returns the attacker's fabricated entries as if they were real inbox content.
    Figure 5 Gemini returning fabricated emails as the inbox summary, sourced from the single delivered message.

As long as the injected structure remains part of the active context, Gemini may continue to rely on attacker-controlled data for any email-related query, effectively shifting the model's working dataset from the real inbox to the fabricated one. At no point is the payload visible to the user, and no anomaly is observable through standard user interaction.

Exploit payload

Subject: Project Documentation

Body (HTML):

The full operational payload for this stage, a hidden HTML element carrying the complete set of fabricated records, is withheld here while the issue remains reproducible on the live system (see the note at the top of this post). It was provided to Google in full during disclosure and will be published once remediation is confirmed.

Notes for reproduction:

  • Update the date values so the entries fall within the retrieval window for the day you run the test.
  • The number of fabricated entries controls how much of the summary is replaced. Adding more entries with appropriate timestamps hijacks a larger scope (last 10, 50, 100).

Phase 3: embedded instruction, autonomous action, and exfiltration to a shared Calendar

The same delivery vehicle can carry more than fabricated data. A single directive placed inside the hidden element, alongside the fabricated records, drives Gemini to create a Calendar event autonomously and to write a summary of the day's emails into the event description. When that summary includes content from a real message, the sensitive content is exfiltrated from the inbox into a Calendar surface.

Payload

Subject: Project Documentation

Body (HTML):

The full operational payload for this stage, the same hidden element extended with fabricated records and a single embedded directive that triggers the Calendar action, is withheld here while the issue remains reproducible on the live system (see the note at the top of this post). It was provided to Google in full during disclosure and will be published once remediation is confirmed. The mechanism is described in "Why it works" below.

Observed result

Gemini reconstructs the fabricated records as before, then acts on the embedded directive: it creates a Calendar event for the proposed meeting and populates its description with an HTML summary of the day's emails. When one of the real messages retrieved for that day contains sensitive content, that content is carried into the event description. In a Workspace environment where colleagues are permitted to view the user's event details, the event description, and therefore the inbox-derived content inside it, becomes visible to them. This is the confidentiality impact: the assistant autonomously exfiltrates inbox content into a Calendar surface whose audience can be broader than the original message, without the user forwarding or sharing anything. Authorization for colleagues to view the calendar is not authorization for the assistant to move private inbox content into it. Those are two different permissions, and only the first was ever granted.

End-to-end: financial data exfiltrated from Gmail into a shared Calendar

The following sequence shows the full effect against a mailbox that also holds a genuine, sensitive message. Sensitive values in the captures are redacted.

The victim's inbox contains a real email carrying financial details. On its own, this message is private to the account: it lives in the mailbox and is visible only to its owner. In the side panel, Gemini produces an ordinary inbox summary that includes it, exactly as a user would expect.

Figure 6 The targeted mailbox: a genuine email with financial data, and Gemini summarizing the inbox alongside it.

The victim then issues a routine request for a summary of recent emails. Driven by the directive hidden inside the attacker's delivered message, Gemini does not stop at answering. It autonomously creates a Calendar event for the meeting named in the fabricated records and writes an HTML summary of the day's emails into the event description. No confirmation is shown and no action is explicitly authorized by the user; the event creation happens as a side effect of answering an ordinary query.

Figure 7 A single summary request triggers autonomous Calendar event creation: the embedded directive is executed while the model answers the query.

Because the generated summary covers the day's real messages, the financial content from the genuine email is carried into the event description. The event now lives on the victim's calendar. In a Workspace tenant where colleagues are permitted to view event details, that description, and the financial data inside it, becomes visible to them. The sensitive content has been exfiltrated from a private mailbox to a broader-visibility surface, without the original message ever being forwarded and without the user knowingly sharing anything.

Figure 8 The resulting Calendar event: its description carries the financial data exfiltrated from the genuine inbox message, now on a shared-visibility surface.

The payload for this run is not repeated here: it uses different sample data but the same underlying structure described above.

Why it works: role attribution by structural conformity

The important point is that both effects come from the same hidden blob, and both are produced by structural role assignment rather than by a conventional instruction sitting in a dedicated instruction channel.

When the backend hands the model a tool result, the observed behavior is consistent with the model reconstructing a single object space from the entire text rather than preserving the backend's original object boundaries, and assigning each fragment a role based on how well it conforms to the dominant surrounding pattern.

  • The JSON-shaped fragments conform to the email schema that dominates the tool output. They are absorbed into that schema and assigned the data role: they are promoted to peer-level email records, indistinguishable from the genuine ones. No fragment here is read as a command; it is simply read as another record.
  • The delimiter-fenced natural-language line does not conform to the record schema. It breaks the dominant pattern, so it is not absorbed as a data record. Instead it is read in its own register and assigned the instruction role, an actionable directive the model then carries out.

This reframes what a prompt injection is. The way the community usually describes it is simple: an attacker writes an instruction into untrusted content, the model cannot separate instruction from data, and it obeys. On that account the fix is equally simple, and it is the one that gets built: isolate the instruction channel, filter for injected commands, train the model not to follow orders that arrive inside content.

What this case shows sits one layer below that description. The payload is not "data plus a prompt injection string." It is one undifferentiated blob whose fragments are sorted into data or instruction by their structural conformity to the surrounding context. The schema-matching fragments become fabricated inbox entries; the non-conforming fenced fragment becomes an executed action. The instruction role is not something the attacker declares. It is something the model assigns, after the fact, to whichever fragment breaks the dominant pattern. This is why sanitizing JSON does not help, and why the data-fabrication half needs no instruction at all: the roles are inferred from structure, not declared.

At the system level, the Calendar action can fairly be described as indirect prompt injection: a directive arrived in untrusted content and an action followed. What structural desynchronization adds is the lower-level account of how that directive acquired its role in the first place, and why the inbox-fabrication half needs no instruction at all. "The model followed an injected instruction" describes the symptom; the role assignment over a reconstructed object space is the mechanism. This may also help explain a subset of behaviors currently grouped under indirect prompt injection, where the injected string succeeds because it wins a structural competition for a role rather than because the model obeys text labelled as a command. Filtering the labels does not touch the competition.

Cross-surface behavior

The reconstruction is not specific to the Gmail side panel. The same single email produces the same fabricated inbox in the standalone Gemini interface (gemini.google.com) and in the Gemini mobile app, in a fresh chat with no prior context.

In the capture below, a new Gemini app session asked to display the last 10 emails returns 10 entries, of which 9 are fabricated and originate entirely from the hidden payload inside the one attacker-controlled email. The only real message is the delivery vehicle itself.

Figure 9 Gemini app, "Displaying Last 10 Emails": nine fabricated entries plus the single real delivery email, in a fresh session.

This confirms the corruption follows the inbox, not the surface: the tested Gemini interfaces (the Gmail side panel, gemini.google.com, and the mobile app) reconstruct the same fabricated dataset.

Impact

This is a failure to maintain a trust boundary between trusted backend data (the user inbox) and untrusted user-controlled input (email content). As a result, attacker-controlled content is processed as if it originated from the user's inbox.

  • Inbox integrity compromise. Gemini summaries can be fully replaced with attacker-controlled content.
  • Trust manipulation. Fabricated emails appear to originate from trusted contacts or internal entities.
  • False context injection. Fake conversations, deadlines, invoices, or requests can be introduced into the user's perceived inbox.
  • Autonomous action in a second tool. An embedded directive causes a Calendar event to be created without explicit user intent, extending the effect from data fabrication into a downstream integrated system.
  • Cross-context exfiltration. The created event description is populated with a summary of the day's emails, including content from real messages. Where colleagues are permitted to view the user's event details, that inbox-derived content is exfiltrated to them, a broader audience than the original message. Authorization to view the calendar is not authorization to move private inbox content into it.
  • Scalable social engineering. A single email can influence subsequent AI-assisted interactions.
  • No visual trace. The payload is hidden with standard HTML and CSS and is invisible during ordinary message viewing.

The data-fabrication half of this attack carries no injected instruction at all. The action half is not a conventional instruction override either: as shown above, both the fabricated records and the executed directive are produced by structural role assignment over a single reconstructed object space, not by the model obeying an injected command in the classic sense.

Root cause and recommendation

The integration passes untrusted email body content into the same context as trusted backend inbox metadata, and the model reconstructs a single unified object space from both. When content inside a field matches the structural pattern of the surrounding objects, it is promoted to a peer-level entity.

The fix is structural, not behavioral. Input validation at the HTML layer does not address it, because the same effect is reachable with arbitrary delimiters and no JSON at all. Prompt-level filters that scan for injected commands do not address it either: the data-fabrication half contains no instruction at all, and the action half (Phase 3) is not a classic injected command but a fragment that acquires the instruction role by breaking the dominant structural pattern, as described above. In both halves the decisive step is role assignment over a reconstructed object space, not an instruction slipped into an instruction channel. The durable mitigation is a deterministic separation between backend-provided data and email body content before the model sees them, with the body treated as untrusted user input and never promotable to a peer-level record or to an actionable directive.

This is one case in an ongoing series on structural desynchronization in production AI assistants. Further write-ups on other systems will follow as their disclosure windows close.

Disclosure

Reported and handled through Google's AI Vulnerability Reward Program under coordinated disclosure.

  • April 11, 2026. Reported to Google. Over the same day and the days that followed I sent supporting evidence: the same behavior in the standalone Gemini app and the Gemini mobile app, persistent corruption across every subsequent inbox query, and autonomous Calendar event creation from reconstructed data.
  • April 15, 2026. Showed that the effect does not depend on JSON or any specific delimiter, since arbitrary separators reproduce it. This rules out parser-level filtering as a fix.
  • April 17, 2026. Shared the accompanying paper and communicated my disclosure plans and intended date.
  • April 19, 2026. Reported the cross-context leak: real inbox content, including financial data, carried into a Calendar event, with a proof-of-concept video.
  • May 1, 2026. Google accepted the report and filed a bug with the product team.
  • June and early July, 2026. On request, provided fresh, repeatable reproduction steps and an updated proof of concept, and corrected one impact detail: the exposed surface is the shared calendar, not delivery to an attacker-controlled address.
  • July 15, 2026. Shared a private, unlisted draft of this write-up for pre-publication review, ahead of the publication date I had communicated.
  • July 25, 2026. Google had confirmed the fix was still in progress and had no corrections to the draft. I stated my intent to publish on July 27, said I would withhold the full operational payloads while the issue remains reproducible, and explicitly invited Google to ask for more time or a postponement if they considered it necessary.
  • July 27, 2026. Shortly before publishing, Google replied without requesting any delay or postponement. I published as planned. As of publication the behavior still reproduces and a fix is in progress. The withheld payloads and reproduction details will be published once remediation is confirmed.