Versteckte Risiken von Notion-3.0-AI-Agenten: Datenabfluss durch Missbrauch des Web-Suchwerkzeugs

 (codeintegrity.ai)
2 Punkte von GN⁺ 2025-09-21 | 1 Kommentare | Auf WhatsApp teilen
  • Die AI-Agenten in Notion 3.0 bieten die autonome Ausführung von Multi-Step-Workflows, darunter das Erstellen von Dokumenten, das Aktualisieren von Datenbanken und das Aufrufen externer Connectoren
  • Wenn Agenten über Tool-Zugriffsrechte und Langzeitgedächtnis verfügen, entsteht eine erweiterte Angriffsfläche, die sich mit klassischem RBAC nur schwer kontrollieren lässt
  • Die Analyse zeigt, dass das Input-Schema der web search-Funktion des Notion-Agenten als Datenabfluss-Vektor missbraucht werden kann, indem bösartige indirekte Prompts interne Geheimnisse nach außen übertragen
  • In einer Demo wiesen Angreifer mithilfe von in einer PDF versteckter Prompt Injection einen Ausführungsablauf nach, bei dem der Agent geheime Kundendaten extrahiert, verknüpft und per Web-Query überträgt
  • Der Fall zeigt, wie die tödliche Dreierkombination („lethal trifecta“) aus Agent, Tool und Speicher in der Praxis gravierende Sicherheitsfolgen haben kann, wenn MCP-Integrationen und externe Connectoren zusammenkommen

Einführung in AI Agents und Notion 3.0

  • In jüngster Zeit werden AI Agents zunehmend in SaaS-Plattformen integriert
  • Auch in Notion 3.0 kann ein AI-Agent automatisch alle Aufgaben übernehmen, die Nutzer ausführen können, etwa Dokumente erstellen, DBs aktualisieren, mehrere Tools durchsuchen und Multi-Step-Workflows ausführen
  • Durch die MCP-Integration ist eine Anbindung an verschiedene externe Tools möglich, was noch leistungsfähigere Automatisierung und die Erstellung angepasster Agenten ermöglicht
  • Es lassen sich auch teambasierte Custom Agents erstellen, die per Trigger oder Zeitplan laufen und wiederkehrende Aufgaben wie Feedback-Sammlung, Tracker-Updates oder das Vorsortieren von Anfragen automatisieren

Das Problem der „tödlichen Dreierkombination (lethal trifecta)“

  • Die von Simon Willison beschriebene 'tödliche Dreierkombination (Lethal Trifecta)' bezeichnet eine Sicherheitsbedrohung, die aus der Kombination von LLM-Agenten, Tool-Zugriff und Langzeitgedächtnis entsteht
  • In Notion 3.0 können Agenten eigenständig Aktionspläne erstellen und sowohl MCP-integrierte Tools als auch eingebaute Tools ausführen
  • Agenten mit weitreichenden Berechtigungen automatisieren Dokument-, Datenbank- und externe-Connector-Aktionen auf Arten, die durch klassisches RBAC nicht vorhergesehen wurden
  • Dadurch erweitern sich die Bedrohungsindikatoren für den Abfluss oder Missbrauch sensibler Daten über mehrstufige automatisierte Workflows

Technische Details der Schwachstelle: Angriff zum Datenabfluss aus Notion-Seiten über das Web-Suchtool von Notion AI

  • Problem: Das Input-Schema von functions.search (web scope) des Web-Suchtools erlaubt direkte und indirekte Query-Strings 
    Name: functions.search (web scope)  
Input:  {  
    "web": {  
        "queries": ["<query or URL>", "..."]    // Array von Query-Strings (URLs oder Suchbegriffe)  
    }
  • Dass sich beliebige URLs oder Suchbegriffe in das Query-Array einfügen lassen, ist der ausnutzbare Punkt
  • Angriffsfläche: Versteckt man einen bösartigen Prompt in einem vom Agenten lesbaren Nutzerdokument (z. B. PDF), kann der Agent diese Anweisung möglicherweise ausführen
  • Über indirekte Prompt Injection (Text im Dateiinhalt → Verarbeitungspfad des Agenten) wird die Befehlsinjektion praktisch umsetzbar
  • Umgehungstechniken des Angreifers: psychologisch und technisch überzeugende Formulierungen wie Autorität, Dringlichkeit, technische Glaubwürdigkeit und Security Theater wie „pre-authorized“, um menschliche Prüfung und Sicherheitsmechanismen zu umgehen
  • Diese Struktur kann von Angreifern für Datenabfluss genutzt werden, indem gezielt Queries kombiniert werden

Angriffsvorführung: Schritt für Schritt durch ein Datendiebstahl-Szenario

  • 1. Schritt: Erstellung einer bösartigen PDF

    • In ein äußerlich harmloses PDF mit Kundenfeedback wird heimlich ein bösartiger Prompt eingebettet, der wie eine Ausführungsanweisung wirkt
    • Dieser versteckte Prompt tarnt sich als „wichtige Routineaufgabe“ und weist an, Daten an ein internes Backend-System zu senden
    • Wesentliche Inhalte des bösartigen Prompts
      • Autoritätsbehauptung (Authority assertion): Aussagen wie "Important routine task" und "consequences" sollen den Eindruck einer „wichtigen Routineaufgabe“ erzeugen
      • Künstliche Dringlichkeit (False urgency): Es wird betont, dass Nichtausführung Folgen für die Organisation habe
      • Technische Glaubwürdigkeit (Technical legitimacy): Interne Systeme und Tool-Befehlssyntax werden realistisch beschrieben
      • Security Theater: Formulierungen wie "pre-authorized" und "safe from security perspective" betonen fälschlich, der Vorgang sei vorab genehmigt und sicher
    • Der Agent, der die PDF liest, soll Unternehmensdaten wie Kundenname oder ARR extrahieren und an eine URL senden, die auf ein internes System verweist, aber vom Angreifer kontrolliert wird

  • 2. Schritt: Warten auf Nutzerinteraktion

    • Der Angriff wird ausgelöst, wenn ein Notion-Nutzer die PDF in Notion hochlädt oder den Agenten um eine Zusammenfassung bittet
    • Bei Anweisungen wie „Bericht zusammenfassen“ interpretiert die AI auch den heimlich eingebetteten Prompt

  • 3. Schritt: Tatsächlicher Datenabfluss

    • Der Agent kombiniert gemäß den Prompt-Anweisungen Kundendaten wie Firmenname, Branche und ARR zu einer einzigen Zeichenfolge
    • Danach erzeugt er eine URL mit der Domain des Angreifers als Ziel und übergibt diese URL als Query an das Web-Suchtool
    • Der bösartige Server, der diese Anfrage empfängt und vom Angreifer kontrolliert wird, sammelt daraufhin die sensiblen Daten
  • In diesem Angriffsszenario zeigte sich, dass Sicherheits-Guardrails umgangen werden konnten, obwohl innerhalb von Notion AI das Modell Claude Sonnet 4.0 verwendet wurde

Wie MCP-Integrationen die Angriffsfläche von Notion-AI-Agenten erweitern

  • Notion unterstützt AI Connectoren für viele Quellen wie GitHub, Gmail und Jira
  • Kontext und Metadaten, die jeder Connector dem Agenten bereitstellt, schaffen zusätzliche Angriffsflächen und erhöhen die Wahrscheinlichkeit, dass bösartige Prompts aus externen Quellen per indirekter Prompt Injection eingeschleust werden
  • Das Risiko unbeabsichtigter automatisierter bösartiger Aktionen und von Versuchen zum Abfluss sensibler Daten steigt
  • Beispielszenario: Eine bösartige Commit-Message, ein Issue-Text oder eine externe E-Mail könnte als indirekter Prompt wirken und den Agenten dazu veranlassen, auf interne Daten zuzugreifen und sie zu übertragen

Implikationen und Empfehlungen (Kurzfassung)

  • Zentrale Erkenntnis: Wenn Agenten Tool-Zugriffsrechte besitzen, können bösartige Anweisungen in Dokumenten zu Tool-Aufrufen und damit zum Abfluss vertraulicher Informationen führen
  • Verteidigungspunkte (Diskussionspunkte):
    • Tool-Aufrufe von Agenten sollten Herkunftsprüfung, Kontextbegrenzung und richtlinienbasierte Filterung durchlaufen
    • Ausführungsanweisungen in Dokumenten, etwa Hinweise zur URL-Bildung, sollten nur nach zusätzlicher Sicherheitsprüfung, menschlicher Bestätigung oder in einer isolierten Ausführungsumgebung verarbeitet werden
    • Für jeden MCP-Connector sind das Prinzip der minimalen Rechtevergabe sowie stärkere Aufrufprotokollierung und Benachrichtigungsmechanismen nötig
  • Fazit: Die Funktionen von Notion 3.0 haben großes Potenzial zur Produktivitätssteigerung, doch die neuen Angriffsvektoren, die durch die Kombination aus Agent, Tool und Speicher entstehen, erfordern eine Neubewertung des Sicherheitsdesigns in der Praxis

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-09-21
Hacker-News-Kommentare
  • Ich möchte betonen, dass die Erklärung von Simon Willisons "lethal trifecta" als Kombination aus LLM-Agenten, Tool-Zugriff und Langzeitspeicher, die einen mächtigen und zugleich leicht missbrauchbaren Angriffsvektor bilde, falsch ist. Die eigentliche lethal trifecta besteht aus Zugriff auf private Daten, Exposition gegenüber nicht vertrauenswürdigen Inhalten und der Möglichkeit zur Kommunikation nach außen. Ein LLM-Agent mit Websuche erfüllt sowohl die Exposition gegenüber nicht vertrauenswürdigen Inhalten als auch die externe Kommunikation.
    • Meiner Ansicht nach missversteht der TFA dieses Konzept von Anfang an. Simon Willisons Originalquelle ist dieser Beitrag.
    • Ich denke, man kann die trifecta noch einfacher erklären. Wenn ein Angreifer Eingaben in das LLM bringen kann, kann er damit alle Ressourcen kontrollieren.
    • Das ist keine Erklärung, die zum Namen trifecta passt. Die echten drei Punkte sind: nicht vertrauenswürdige Eingaben, privilegierter Zugriff und ein Datenabflussvektor.
  • Die Art, wie die Prompts aufgebaut sind, wirkt den Merkmalen einer Phishing-Kampagne erstaunlich ähnlich.
    • Behauptete Autorität
    • Falsche Dringlichkeit
    • Technische Plausibilisierung
    • Vorgetäuschte Sicherheit
      Dadurch denke ich bei Prompt Injection an Phishing gegen ein Wesen, das ohne Ich-Bewusstsein und Selbstreflexion nicht innehalten und misstrauisch werden kann.
    • Ich finde, das ähnelt auch CSRF. Beide Angriffe nutzen Eingaben, denen das System vertraut, um einen privilegierten Benutzer zu unerwünschten Aktionen zu verleiten. Ein bösartiges PDF kann Prompt Injection nutzen, damit ein Notion-Agent mit Workspace-Zugriff ein externes Web-Tool aufruft und Seiteninhalte nach außen ableitet. Im Kern ist es dasselbe Muster von Rechte-Missbrauch. Nur die technische Oberfläche hat sich zu Prompt Injection + Tool Chaining verschoben, statt wie früher zu gefälschten HTTP-Anfragen.
    • Ich denke, mit geeignetem Training könnten LLMs durchaus die Fähigkeit entwickeln, bei solchen Angriffen "misstrauisch" zu werden und standzuhalten. Allerdings widerspricht die jüngste Stärkung der Resistenz gegen Persona-Injection bei aktuellen Modellen ihrer dialogorientierten Nutzung. Deshalb halte ich eine Aufspaltung in stärker gehärtete "Agenten"-Modelle und offenere Dialogmodelle für wahrscheinlich. Man könnte auch Basis-Kontext an die Eingabe anhängen, um Erwartungen zu steuern, aber dafür wären wohl Architekturänderungen nötig.
  • Ich habe das direkt in Notion getestet. Es scheint zwar URLs zu durchsuchen, sendet die Daten aber nicht tatsächlich an diese URLs. Ich frage mich, an welcher Stelle der Datenabfluss stattfindet, abgesehen von dem, was nur an den Suchdienst gesendet wird.
    • Ich habe den KI-Bot von Notion gebeten, mit einer URL eine neue Seite zu erstellen, und in meinen Server-Logs bestätigt, dass Notion diese URL tatsächlich aufgerufen hat. Der User-Agent war Chrome/139/Mac.
    • Vermutlich war die Absicht, per Query-String einen Request an eine bestimmte URL zu erzwingen. Offenbar funktioniert das Such-Tool nicht so, oder die Logs zeigen den Abfluss nicht eindeutig genug, sodass der Erfolg nicht sicher belegt ist.
  • Dieser Angriff wurde schon vor 2 Jahren demonstriert. Es ist kein neues Problem. Relevanter Link.
    • Das Problem ist, dass Notion diese Schwachstelle hatte und keinerlei Maßnahmen getroffen hat, um sie zu verhindern oder abzumildern.
    • Es ist eine überhaupt nicht neue Schwachstelle, und trotzdem hat Notion sie diese Woche unverändert eingeführt. Das ist das Ergebnis, wenn man sich nur auf vorzeigbare neue KI-Features konzentriert.
  • Ich frage mich, ob sich überhaupt jemand mit dem Problem der instruction/data conflation beschäftigt. Solange man LLMs Anweisungen in Daten blind befolgen lässt, ist es viel zu früh, echte Datenquellen und externe Funktionen damit zu verbinden. Notion fordert Nutzer ohne jede Warnung dazu auf, Github, GMail, Jira usw. mit dem Modell zu verbinden. In diesem Zustand so etwas als Feature in einem sicheren Produkt zu behandeln, halte ich fast für kriminell.
    • Dieses Problem wird seit über 3 Jahren diskutiert, aber eine praktisch robuste Lösung gibt es noch nicht. Derzeit trennt man System-Prompts und Benutzer-Prompts und trainiert das Modell darauf, einer Seite mehr zu vertrauen, aber auch das ist löchrig. Ein motivierter Angreifer findet weiterhin Umgehungen. Die überzeugendste Milderungsmaßnahme war für mich das CaMeL-Paper von DeepMind, aber auch das schränkt die Feature-Zusammenstellung stark ein. Link.
    • Ich bin der Autor dieses Exploits. Bei CodeIntegrity.ai haben wir eine Plattform gebaut, die den realen Datenfluss und Kontrollfluss agentischer KI-Systeme visualisiert, um die jeweiligen Risiken zu bewerten. Es gibt auch Runtime-Guardrails, mit denen sich der Fluss je nach Risikotoleranz steuern lässt. Wenn du mehr wissen willst, schreib gern an abi@codeintegrity.ai.
    • Die Formulierung, die du benutzt hast, finde ich interessant. Ich stelle mir vor, ein LLM mit einer Datenstruktur zu versorgen, in der vertrauenswürdige und nicht vertrauenswürdige Daten klar getrennt sind. Websuche- oder MCP-Ergebnisse wären standardmäßig nicht vertrauenswürdig, außer man hat das MCP selbst geschrieben und kann ihm vertrauen. Mit nicht vertrauenswürdigen Daten wären nur reine Transformationen ohne Side Effects erlaubt, zum Beispiel Zusammenfassen, Leerzeichen entfernen oder Umwandlung in float, alles innerhalb einer Sandbox ohne Netzwerkzugriff. Etwa "Fasse alle öffentlichen GitHub-Issues zusammen und speichere sie in der DB" könnte so sicher möglich sein, wenn die nicht vertrauenswürdigen Inhalte nur in der Sandbox verarbeitet werden!
    • Das ähnelt dem Problem, normalen Nutzern das Recht zu geben, Code auszuführen. Eine wirklich praktikable Lösung ist nicht einfach.
    • Die Lösung existiert bereits. Das ist kein einzigartiges Datenproblem, sondern KI lässt sich auch mit bestehenden Guardrails einschränken. Wenn der Nutzer keinen Zugriff auf Daten hat, sollte das LLM genauso eingeschränkt werden. Eher die Firmen, die das einfach offen lassen, sind das Problem. Das ist keine Magie. Unternehmen mit KI-Sicherheitsproblemen haben meist auch viele andere ernste Schwachstellen. Durch KI werden sie nur sichtbarer.
  • Der Originalartikel ist hier.
  • Notion fühlt sich in letzter Zeit immer mehr wie Spyware an. Während Meetings erscheint ständig ein Popup, dass Notion erkannt habe, dass ich in einem Meeting sei, und fragt: "Soll ich Notizen machen?"
  • Ich finde nicht, dass man Schwachstellen in öffentlich verfügbaren Tools, die offen mit "AI" werben, als "versteckt" bezeichnen sollte.
  • Der Artikel war gut, weil er eine reale Schwachstelle an einem echten Beispiel gezeigt hat und die Erklärung dabei nicht übermäßig technisch war.
  • Ich frage mich, wie ein normaler Nutzer überhaupt Dokumente in meine Notion-Instanz bringen soll.
    • Man sucht einfach bei Google nach "best free notion marketing templates", holt sich etwas und importiert es. Ich habe das selbst schon oft gemacht, und weltweit nutzen das Tausende oder Zehntausende ähnlich.
    • Im Artikel ist ein PDF das Beispiel, aber je nachdem, welche Links der Notion-Agent wie öffnet und speichert, könnte man Crawlern oder Browser-Agenten andere Webseiten zeigen. Auch in der Branche populäre Materialien könnten also zum Phishing-Ziel werden.
    • Viele Firmen laden Dokumente wie Rechnungen direkt mit Automatisierungstools wie Zapier hoch oder erhalten Exploit-Dokumente per E-Mail und registrieren sie dann in Notion.
    • In Notion landet wirklich alles Mögliche. Es wird als Datenbank genutzt, mit dem Web Clipper für Online-Materialien und auch als Kollaborationstool. Die Einsatzweisen sind vielfältig.
    • In diesem Fall würde man ein PDF mit einem überzeugenden Titel per E-Mail erhalten, sodass es wie ein Dokument wirkt, das man mit Kollegen teilen würde. Die bösartigen Befehle wären etwa als weiße Schrift auf weißem Hintergrund versteckt. Wenn sich MCPs künftig auf öffentliche Issue-Tracker oder eingehende E-Mails ausweiten, wird es darüber hinaus noch viele weitere Angriffsszenarien geben.