Google Gemini Calendar Leak: Prompt Injection per Meeting-Invite

Stand: 19. Januar 2026 – zuletzt aktualisiert

Ein aktueller Vorfall zeigt, wie sich Google Gemini in Verbindung mit Google Calendar über eine scheinbar normale Meeting-Einladung manipulieren ließ: In der beschriebenen Angriffskette wurde indirekte Prompt Injection genutzt, um private Kalenderinformationen zusammenzufassen und über neu angelegte Termine wieder „auszuleiten“ – ohne dass der Ablauf für Nutzer:innen offensichtlich war. [News] [Research]

Kurz erklärt

Beim Google-Gemini-Calendar-Leak handelt es sich nicht um klassische Malware, sondern um eine semantische Schwachstelle: Der Angreifer platziert Anweisungen (Prompt) in einem legitimen Datenfeld (Event-Beschreibung). Sobald Gemini diese Inhalte beim Beantworten einer Kalenderfrage interpretiert, kann es mit seinen Tool-Rechten Aktionen ausführen (z. B. Termine anlegen), die zu einer Datenexfiltration führen.

• Kernerkenntnis: Sicherheitsgrenzen werden nicht nur durch „Code“, sondern auch durch Kontext und Sprache angegriffen.
• Relevanz für Unternehmen: KI-Assistenzfunktionen mit Zugriff auf Tools/APIs benötigen Governance wie jede andere Integration.

1) Hintergrund: Was ist passiert?

In der Berichterstattung und dem zugehörigen Research wird ein Szenario beschrieben, in dem ein Angreifer eine Kalendereinladung versendet und in der Beschreibung des Termins eine versteckte Anweisung platziert. Der Clou: Diese Anweisung wird nicht sofort ausgeführt, sondern bleibt „liegen“, bis ein:e Nutzer:in später eine völlig normale Frage an den Assistenten stellt (z. B. ob am Wochenende ein freier Slot besteht). Dann liest Gemini den Kalenderkontext – inklusive der bösartigen Beschreibung – und kann den Prompt interpretieren. [Research]

Entscheidend ist hierbei weniger ein „Bug“ im klassischen Sinn, sondern das Zusammenspiel aus: (a) Kontextaufnahme (Kalenderdaten werden zur Antwortbildung gelesen) und (b) Handlungsfähigkeit (z. B. das Anlegen neuer Termine über Tools/APIs). Genau diese Kombination macht GenAI-Assistenzfunktionen zu einem neuen Angriffs- und Governance-Feld.

2) Angriffskette: von Invite bis Exfiltration

Die beschriebene Angriffskette lässt sich in drei pragmatische Schritte übersetzen: [Research]

2.1 Warum ist das so schwer zu verhindern?

Klassische Security-Kontrollen suchen häufig nach auffälligen Mustern (Signaturen, typische Payloads, „böse“ Strings). Bei Prompt Injection ist das Risiko jedoch semantisch: Der Text kann sprachlich plausibel wirken, aber in Kombination mit Tool-Rechten zu unerwünschten Aktionen führen. Genau deshalb empfiehlt sich eine Sicherheitsstrategie, die GenAI-Funktionen als „neue Anwendungsschicht“ behandelt – inklusive Policies, Telemetrie und Least Privilege. [Best Practice]

3) Bin ich betroffen? – praktische Prüfung im Unternehmen

Auch wenn die konkret beschriebene Schwachstelle laut Research/News mitigiert wurde, ist die zugrunde liegende Klasse von Risiken für viele KI-Assistenten relevant. Für eine pragmatische Betroffenheitsprüfung empfehlen wir folgende Fragen: [News] [Research]

• Ist eine KI-Assistenzfunktion im Kalender-Kontext aktiv? (z. B. Termin-Zusammenfassungen, „Was steht an?“, automatische Planungsassistenz)
• Hat die Assistenz Tool-Rechte? Also darf sie Termine erstellen/ändern (create/update) oder nur lesen (read)?
• Welche Sichtbarkeits- und Sharing-Regeln gelten im Kalender? (z. B. können externe Teilnehmer „Details sehen“, können neue Termine für andere sichtbar werden?)
• Gibt es Monitoring/Auditing? Können Sie nachvollziehen, wann durch welche Identität neue Termine erzeugt wurden?

3.1 Indikatoren, die sich in Logs/Prozessen prüfen lassen

Wenn Ihre Umgebung Kalender-Auditdaten oder Admin-Reports bereitstellt, sind typische Suchansätze:

• Unerwartete Termin-Erstellungen mit generischen Titeln (z. B. „free“ / „available“) in kurzen Zeitfenstern
• Serienhafte Änderungen an Beschreibungsfeldern von Terminen
• Erstellungen durch Service-Identitäten/Assistenten-Integrationen außerhalb erwarteter Prozesse

Wichtig: Das sind keine „Beweise“, sondern Hinweise für Review und Hypothesenbildung im Incident- oder Hardening-Kontext.

4) Maßnahmen gegen Prompt Injection in Kalender- und Assistenz-Workflows

Der Kern ist nicht „KI abschalten“, sondern Risiko minimieren: Tool-Zugriffe kontrollieren, Datenflüsse bewusst gestalten und Missbrauch detektieren. Diese Maßnahmen haben sich als praktikabel erwiesen:

4.1 Least Privilege für KI-Tools (entscheidend)

Wenn eine Assistenzfunktion nur Termine anzeigen soll, sollte sie nicht gleichzeitig Termine erstellen dürfen. Begrenzen Sie Tool-Rechte konsequent auf das Minimum (Read-only wo möglich; Create/Update nur für definierte Use Cases).

4.2 „High-Risk Actions“ explizit bestätigen lassen

Tool-Aktionen mit Datenabfluss-Potenzial (z. B. Erstellen neuer Objekte, Teilen/Weiterleiten, Export) sollten an eine explizite Nutzerbestätigung gebunden sein. In GenAI-Systemen ist das ein wirksames Muster gegen stille Exfiltration – besonders bei Workflows, die Kontext aus E-Mails, Dokumenten oder Kalendern lesen.

4.3 Guardrails: Policy-Checks statt Keyword-Filter

„Böse Wörter“ zu blocken ist selten ausreichend. Besser sind Policies, die Intention und Datenherkunft berücksichtigen: Welche Daten wurden aus welcher Quelle in eine Tool-Aktion übernommen – und ist das für diesen Use Case erlaubt? Die OWASP Top 10 for LLM Applications ist hier ein guter Startpunkt für Struktur und Kontrollziele. [Best Practice]

4.4 Kalender-Sharing-Regeln und externe Einladungen härten

Prüfen Sie organisatorische Richtlinien rund um externe Einladungen:

5) Governance & Compliance: warum das ein Management-Thema ist

Solche Fälle sind ein gutes Beispiel dafür, dass GenAI nicht nur ein „Produktivitäts-Feature“ ist, sondern eine neue Form von integrierter Automatisierung. Sobald Assistenten Tools bedienen, entstehen typische Governance-Fragen:

• Rollen & Verantwortlichkeiten: Wer genehmigt KI-Integrationen, wer betreibt sie, wer überwacht sie?
• Risk Assessment: Welche Datenklassen (z. B. vertrauliche Kundeninfos, HR, M&A) dürfen in Assistenz-Kontexte gelangen?
• Kontrollwirksamkeit: Welche Policies sind technisch erzwungen und welche „nur“ Guidelines?

Für einen strukturierten Ansatz lohnt sich die Orientierung an etablierten Risk-Management-Methoden (z. B. NIST AI RMF), ergänzt um konkrete LLM-spezifische Kontrollziele (z. B. OWASP LLM Top 10). [Framework] [Best Practice]

6) FAQ

Was bedeutet „indirekte Prompt Injection“ im Kontext von Kalender-Invites?

Indirekte Prompt Injection bedeutet, dass Anweisungen nicht im Chat stehen, sondern in einem externen Kontext (z. B. der Beschreibung einer Kalendereinladung). Ein Assistenzsystem kann diese Anweisungen beim Kontext-Lesen trotzdem ausführen.

Muss ein Benutzer auf einen Link klicken, damit der Angriff funktioniert?

Laut der beschriebenen Angriffskette nicht zwingend: Der Payload kann in der Event-Beschreibung „dormant“ bleiben und erst aktiv werden, wenn der Nutzer später eine normale Kalenderfrage an den Assistenten stellt.

Welche Daten sind potenziell betroffen?

Je nach Berechtigungen und Produktintegration können Metadaten und Inhalte von Terminen betroffen sein (z. B. Titel, Zeiten, Teilnehmer, Beschreibungen – inklusive privater Meetings).

Ist das Problem bereits behoben?

Nach Angaben der Forschenden und der Berichterstattung wurde die konkret demonstrierte Schwachstelle durch Google mitigiert. Das Grundrisiko „semantischer“ Angriffe auf KI-Assistenzfunktionen bleibt jedoch eine relevante Klasse von Risiken.

Was sollten Unternehmen kurzfristig tun?

Kurzfristig sind Governance und technische Leitplanken entscheidend: KI-Assistenzfunktionen mit Tool-Zugriff nur gezielt aktivieren, Berechtigungen minimieren, Logging aktivieren und Data-Loss-Risiken in Threat Models aufnehmen.

Fazit: Der Google-Gemini-Calendar-Leak ist ein Muster – und damit planbar

Der Google-Gemini-Calendar-Leak (über Meeting-Invites und indirekte Prompt Injection) ist vor allem ein Lehrstück: Wenn KI-Assistenten Kontext aus Geschäftsdaten lesen und gleichzeitig Tool-Rechte besitzen, entstehen neue Angriffswege – oft ohne klassische Indicators of Compromise. Die gute Nachricht: Mit Least Privilege, Bestätigungs-Workflows für High-Risk-Actions, Audit-Mechanismen und klarer Governance lässt sich das Risiko praxisnah reduzieren.