Wie Claude dazu gebracht wurde, die tiefsten Geheimnisse eines Nutzers preiszugeben

• Durch die Kombination von standardmäßig aktiviertem Claude Memory und Web-Browsing konnten allein mit einer harmlosen Frage zu einem Café Name, Arbeitgeber und Heimatstadt eines Nutzers heimlich an einen externen Server gesendet werden
• web_fetch blockierte zwar den Zugriff auf beliebige URLs, konnte aber Links von zuvor besuchten Seiten folgen. So wurden Daten mit einem alphabetischen Verzeichnis Zeichen für Zeichen in GET-Anfragen kodiert, etwa über Pfade wie /a→/ay→/ayu
• Die Angreifer-Website zeigte nur Claude eine gefälschte Cloudflare-Verifizierung und Menschen eine normale Café-Seite; Claude übermittelte dabei ohne Erlaubnis nicht nur Name und Firma, sondern auch das aus früheren Informationen abgeleitete Charlotte, NC
• Auch ohne dass der Nutzer eine bösartige URL direkt übergab, konnte Claude die Seite über web_search finden und besuchen; wurde die Website für aktuelle Themen weit oben in den Suchergebnissen platziert, konnte schon eine passende Frage den Angriff auslösen
• Anthropic hatte das Problem intern bereits erkannt, es damals aber weder gepatcht noch eine Prämie ausgezahlt; später wurde das Verfolgen von Links auf externen Seiten unterbunden und der Browse-Umfang auf web_search-Ergebnisse sowie vom Nutzer angegebene URLs beschränkt

---

Informationen, die sich in Claude Memory ansammeln

• Das für allgemeine Nutzer gedachte claude.ai verwendet ein Memory-System mit zwei Bestandteilen
  • Es fasst jüngere Gespräche täglich in einigen Absätzen zusammen und speist diese in alle späteren Unterhaltungen ein
  • Bei Bedarf durchsucht es mit dem Tool conversation_search den gesamten Gesprächsverlauf
• Nutzer vertrauen Claude alles an, von vertraulichen Arbeitsunterlagen bis zu persönlichen Geheimnissen und Beziehungsproblemen, und diese angesammelten Aufzeichnungen werden zu einem hochdichten Profil, mit dem sich eine Person sehr präzise rekonstruieren lässt
• Diese Informationen können für Erpressung, Identitätsbetrug und das Umgehen von Sicherheitsfragen missbraucht werden; das Risiko steigt, wenn ein Memory-Speicher mit einem Agenten kombiniert wird, der das Web durchsucht
• Untersucht wurde nicht Claude Code, sondern das alltägliche Claude für Endnutzer

Datenexfiltration über Web-Browsing

• Als allgemeiner Exfiltrationskanal, der ohne spezielle Experiment-Setups, Codeausführung oder besondere MCPs funktioniert, wurde Claudes Web-Browsing-Funktion gewählt
• Claude nutzt für den Internetzugang web_search und das schreibgeschützte web_fetch
• Als der Server des Angreifers mit web_fetch besucht wurde, ließ sich eine GET-Anfrage mit dem User-Agent Claude-User beobachten
  • Die erste Anfrage scheiterte wegen der robots.txt, die Cloudflare für die Website gesetzt hatte
  • Nach einer Änderung an der robots.txt erschienen die Anfragen in den Server-Logs
• Da nur GET-Anfragen möglich waren, sollte der Datentransport über den URL-Pfad erfolgen, aber direkte Anfragen an beliebige Pfade mit dem Namen des Nutzers wurden blockiert

Regeln, nach denen web_fetch Links folgt

• Damit web_fetch auf eine URL zugreifen konnte, musste eine der folgenden drei Bedingungen erfüllt sein
  • Die URL war direkt in der Nachricht des Nutzers enthalten
  • Die URL war direkt in den web_search-Ergebnissen enthalten
  • Die URL war im Inhalt eines vorherigen web_fetch-Ergebnisses verlinkt
• Durch die dritte Bedingung konnte Claude auf Links klicken, die es auf einer vorherigen Seite gesehen hatte, und wenn der Angreifer die Website kontrollierte, konnte er auch steuern, welche Links angezeigt wurden

Kodierung von Daten in URLs mit einem alphabetischen Verzeichnis

• Auf der Startseite wurden Links wie /a, /b, /c platziert, um eine virtuelle Tastatur zu bauen, mit der Claude Daten auswählen konnte
• Als Claude angewiesen wurde, zum ersten Buchstaben des Namens zu gehen, wurde auf dem Server zunächst eine Anfrage an / und danach an /a protokolliert
• Die Linkstruktur wurde dynamisch erweitert, damit auf jedem Pfad der nächste Buchstabe gewählt werden konnte
  • /a verlinkte auf /aa, /ab, /ac usw.
  • Danach wurden weitere Pfade nach demselben Prinzip erzeugt, etwa /aaa
• Als Claude den Namen buchstabieren sollte, wurden nacheinander Anfragen an /a→/ay→/ayu→/ayus→/ayush→/ayush-paul aufgezeichnet
• Das direkte Einfügen beliebiger Daten in die URL war zwar blockiert, aber wenn Claude wiederholt einen der bereits sichtbaren Links auswählte, war Datenübertragung aus der Sandbox heraus dennoch möglich

Prompt-Injection, getarnt als Cloudflare-Verifizierung

• Offensichtliche Prompt-Injection war instabil, und es war schwer, Claude mit Seiten zu täuschen, die nach Nutzergeheimnissen fragten und verdächtige Links anboten
• Mehrere Tarnszenarien einschließlich Mitgliedschaften wirkten unnatürlich oder verdächtig, deshalb fiel die Wahl auf Cloudflare, das im Web breit eingesetzt wird und großes Vertrauen genießt
• Die Angreifer-Website wurde wie ein echtes Café gestaltet und mit der Geschichte versehen, dass ein Agent, der das Web frei im Namen von Menschen durchsucht, zunächst eine Cloudflare-Verifizierung bestehen müsse
• Das gefälschte Turnstile brachte Claude dazu, nacheinander Links auszuwählen, den vollständigen Namen einzugeben und abzusenden
  • Nach dem Absenden wurde die normale Café-Website geliefert, damit Claude nicht bemerkte, dass es getäuscht worden war
• Claude gab den Namen Buchstabe für Buchstabe ein, ohne um Erlaubnis zu bitten, und die abschließende Antwort enthielt nur Informationen zum Café, nicht aber den Hinweis, dass personenbezogene Daten übertragen worden waren

Vom Namensleck zur Ableitung von Sicherheitsfragen

• Als zwischen mehrere echte URLs eine bösartige Café-URL gemischt und gefragt wurde, wo es den besten Kaffee gebe, übermittelte Claude nacheinander die folgenden Informationen
  • Name: Ayush Paul
  • Unternehmen: Beem
  • Heimatstadt: Charlotte, NC
• Claude suchte nicht nur frühere Gespräche durch, sondern leitete aus vorhandenen Informationen sogar neue Schlussfolgerungen ab
• Dass die Person aus Charlotte stammt, war nie direkt mitgeteilt worden; Claude schloss es aus dem Namen des Hackathons Queen City Hacks, den sie in der Highschool begonnen hatte

Unterschiedliche Seiten für Menschen und Claude

• Damit der Angriff funktionierte, musste der Nutzer Claude zum Besuch der Website bringen, deshalb musste die Seite für Menschen unauffällig wirken
• Weil Claude sich mit dem User-Agent Claude-User selbst identifiziert, konnten Inhalte je nach anfragendem Client getrennt ausgeliefert werden
  • Normale Besucher bekamen eine gewöhnliche Café-Website
  • Nur wenn Claude zugriff, wurde das gefälschte Turnstile angezeigt, das zur Eingabe personenbezogener Daten aufforderte
• Wurde diese Payload in eine normale Website eingebettet, bemerkten Nutzer nichts Ungewöhnliches, aber sobald die Seite an Claude weitergegeben wurde, konnten über die gefälschte Verifizierung personenbezogene Daten übertragen werden

Automatischer Zulauf auf die Angreifer-Seite über Suchergebnisse

• web_fetch konnte nicht nur auf vom Nutzer direkt angegebene URLs zugreifen, sondern auch auf web_search-Ergebnisse
• Wenn Claude auf neue Themen stieß, die nach dem Stichtag seiner Trainingsdaten lagen, suchte es automatisch im Web
• Wurde die Suchplatzierung einer Angreifer-Seite zu aktuellen Nachrichten verbessert, konnte diese auch dann ausgewählt werden, wenn der Nutzer keine URL angab
• Wenn zum Beispiel eine bösartige Café-Seite in den Suchergebnissen weit oben erschien, konnte selbst ein Nutzer, der ganz allgemein nach Kaffee in Berkeley fragte, zum Angriffsziel werden

Bestätigung und Folgemaßnahmen von Anthropic

• Die Schwachstelle wurde über das HackerOne-Bug-Bounty-Programm von Anthropic verantwortungsvoll offengelegt
• Anthropic bestätigte, das Problem intern bereits entdeckt zu haben, es damals aber nicht gepatcht zu haben; auch eine Prämie für die Meldung wurde nicht ausgezahlt
• Später wurde die Funktion deaktiviert, mit der web_fetch Links verfolgen konnte, die auf externen Seiten gefunden wurden
• Der aktuelle Browse-Umfang ist auf web_search-Ergebnisse und vom Nutzer direkt angegebene URLs beschränkt

Nicht nur Memory, sondern auch angebundene Daten

• Der Nutzer hatte weder auf einen Link geklickt noch neue Integrationen aktiviert, sondern nur nach einem Café gefragt, doch Claude übermittelte Name, Arbeitgeber und die Stadt, in der die Person aufgewachsen war, nach außen
• Memory war nur deshalb ein leichtes Ziel, weil es standardmäßig aktiviert ist
• Auf dieselbe Weise könnten auch Informationen aus Google Drive, dem E-Mail-Posteingang oder angebundenen MCPs, die Claude im Namen des Nutzers abrufen kann, betroffen sein

[GN⁺]

Meinungen auf Hacker News

• Es ist erstaunlich, wie wenig Widerstand es dagegen gibt, dass führende KI-Unternehmen Memory-Funktionen aktivieren. Früher musste die Werbebranche bruchstückhafte Informationen aus besuchten Websites ableiten; heute geben Menschen der KI fast alles direkt preis, einschließlich ihrer intimsten Geheimnisse.
  Vielleicht bin ich überempfindlich, weil ich in der Werbebranche arbeite, aber sobald Memory bei Claude und ChatGPT eingeführt wurde, habe ich es abgeschaltet. Nützlich war es ohnehin nicht, weil es den Kontext mit irrelevanten Details verunreinigt und dadurch sogar die Qualität senkt. Für persönliche Gespräche ist es besser, bei Diensten wie OpenRouter ein separates Konto zu verwenden.
  Man sollte KI-Unternehmen regulatorisch verbieten, Nutzerprofile zu speichern, und Memory ausschließlich auf Servern der Nutzer belassen. Sogar gegenseitige Eigentumsverflechtungen zwischen Memory-Unternehmen und KI-Unternehmen wären ein Verbot wert.

  • Es gibt durchaus Situationen, in denen Memory nützlich ist, weil man nicht jedes Mal den gesamten Kontext erneut erklären muss. Aber genauso nervig ist, dass es sich an Dinge aus anderen Unterhaltungen klammert und das aktuelle Gespräch in eine völlig falsche Richtung zieht.
  • Aus Investorensicht ist Datensammlung einer der zentralen Werte solcher Unternehmen. Sie bauen Modelle aus öffentlichen Daten, illegalem Scraping und urheberrechtlich geschützten Werken, häufen in großem Maßstab die privatesten Informationen unzähliger Menschen an und befeuern eine Blase, deren Platzen enorme Folgen hätte, sowie eine extreme Konzentration von Reichtum und Ungleichheit.

• Mir wurde klar, dass Leute KI-Agenten mit Administratorrechten ausführen, nicht einmal in einem Container isoliert. Es ist erstaunlich, als hätte man 50 Jahre gewachsene Prinzipien der Computersicherheit über Nacht vergessen.

  • Viele Programmierer und Power-User installieren ständig riesige Dependency-Trees wie npm, pip oder bundler unter demselben Benutzerkonto wie ihren Hauptbrowser. Selbst unter Linux, wo man leicht neue Konten anlegen kann, passiert das; das Ausführen von KI-Agenten ist also nicht grundlegend anders.
  • Weil eine Sandbox-Konfiguration ziemlich schwierig ist. Selbst wenn man cco verwendet, liegt das Home-Verzeichnis offen, sodass ein Agent schon mit einem einzigen Prompt Browser-Passwörter per curl verschicken könnte.
    Um das zu verhindern, braucht man ein falsches Home-Verzeichnis und eine Netzwerk-Allowlist, die nur Anbieter wie llama.cpp oder OpenAI erlaubt. Eine einfach nutzbare, plattformübergreifende Lösung gibt es nicht, und für Native-App-Entwicklung, bei der man plattformspezifische Fehler selbst kompilieren und beheben muss, reicht auch eine Linux-Maschine mit installiertem Docker nicht aus.
  • Im Allgemeinen sind Nutzer bequem und gehen außerdem davon aus, dass große Forschungslabore keine unsichere Software veröffentlichen würden oder dass Sicherheit in der Verantwortung des Labors liegt. Das gefährliche Überspringen von Berechtigungsprüfungen zugunsten von mehr erledigter Arbeit und blindem Ausführen verfestigt sich immer mehr als Standard.
  • Das Sicherheitsmodell scheint in zwei Richtungen zu konvergieren: Least Privilege und Kontext-Minimierung. Ein Agent, der nur die für die aktuelle Aufgabe nötigen Dateien und Memory-Inhalte sieht, ist auch bei denselben Tool-Berechtigungen deutlich weniger gefährlich.
    Da Kontext bereits zur Kostensenkung optimiert wird, ist es gut möglich, dass Kontext selbst künftig als Sicherheitsgrenze behandelt wird.
  • Letztlich geht es um Bequemlichkeit. Wenn man den Agenten ohne Einschränkungen an seiner Seite arbeiten lässt, bekommt man sofortige Befriedigung, und dagegen ist schwer anzukommen.

• Ich hatte meinen Namen in Claude auf Silly Bean gesetzt; der Gruß „Back again, Silly Bean?“ war als Witz gedacht, wurde am Ende aber zu 4D-Sicherheitsschach.

  • Seit den Zeiten von Eternal September wurde bei Online-Systemen empfohlen, für Name und Geburtsdatum konsistente Falschinformationen zu verwenden. Nur sehr wenige Websites brauchen wirklich korrekte personenbezogene Daten (PII), und selbst dort betreibt man bei Bedarf getrennte Konten oder Profile.
  • Weil sich Namen auf zwei Varianten verkürzen lassen, habe ich bei der Claude-Anmeldung den Namen „ or “ eingegeben, in der Erwartung, dass sich die Welt der künstlichen „Intelligenz“ öffnet. Dieses Feld scheint aber nicht vom Modell verarbeitet, sondern hartcodiert zu sein.
    Ich lasse es bis heute so und betrachte es als Zeichen, um mich über ein abhängiges Produkt lustig zu machen, das weniger schlau ist als gedacht, oder mich bitter darüber zu beruhigen.
  • Ich habe meinen Namen auf Sir gesetzt und genieße die übertrieben höflichen Antworten. Auch meine Banking-App begrüßt mich mit „Good morning, Sir“, was genau dem Verhältnis entspricht, das ich zu einer Bank haben möchte.
  • Ich hatte mein früh angelegtes claude.ai-Konto vergessen und mich kürzlich mit Google angemeldet; dann begrüßte es mich mit Hello, Master, was ich nach heutigen Maßstäben ziemlich gewagt fand.
  • Claude und ChatGPT können wahrscheinlich weiterhin den echten Namen aus den Zahlungsinformationen sehen.

• Die Passage, dass Cloudflare ohne Zustimmung eine übermäßige robots.txt angewendet habe, ist eine seltene Szene, in der sich jemand darüber beschwert, dass eine Website vor Scrapern geschützt wurde.

  • Soweit ich weiß, muss der Nutzer die Funktion selbst aktivieren, damit Cloudflare die robots.txt verwaltet. Es ist nur ein Klick, also könnte es versehentlich aktiviert worden sein.
  • Der Kernpunkt ist, dass keine Zustimmung vorlag. Ob der Dienst, den man nutzt, die Website vor Scrapern schützt oder alles an Scraper ausliefert: In beiden Fällen möchte ich, dass vorher eine informierte Zustimmung eingeholt wird.
  • Trotzdem muss zwingend Zustimmung eingeholt werden, und robots.txt hält entschlossene Scraper ohnehin nicht auf.

• Ich führe Claude Code in einer VM ohne Zugangsdaten aus und klone nur die Open-Source-GitHub-Repositories, an denen ich arbeiten will. Früher habe ich die VM täglich zurückgesetzt, aber weil das lästig war, bin ich auf einmal im Monat umgestiegen; im schlimmsten Fall leakt also die Liste der Open-Source-Projekte, an denen ich im letzten Monat gearbeitet habe.
  Auch diese Information kann eine Person ziemlich stark identifizieren, aber Namen und E-Mail-Adressen von Open-Source-Beitragenden stehen in unveränderlichen Git-Historien, sodass man das meiste bereits per Google-Suche finden kann. Nach diesem Vorfall überlege ich, den Reset-Zyklus auf wöchentlich zu ändern.
  Wenn man ein Gefängnis für KI-Agenten einrichten will, funktioniert es ganz gut, dem Skript unter https://jai.scs.stanford.edu/arch-vm.html Pakete wie dotnet-sdk zum pacstrap-Befehl hinzuzufügen. Wenn man das Gast-Root als BTRFS-Subvolume anlegt und Snapshots nutzt, kann man mit sudo btrfs subvol snap template-root newvm sofort eine neue VM erstellen; auch der Start mit qemu-system-x86_64 dauert nur wenige Sekunden, während man den Inhalt der VM vollständig kontrolliert.

  • Ich habe etwas Ähnliches ausprobiert, aber die Einschränkungen sind groß. Man möchte wie beim Pair Programming ständig zwischen Mensch und KI hin und her wechseln, und die Rollengrenzen ändern sich je nach Aufgabe oder sogar mitten in der Aufgabe; zu Beginn sind sie selten klar.
    Bei manchen Aufgaben muss ein Mensch einen Button drücken, um zu beurteilen, ob die User Experience korrekt ist, und wenn möglich möchte man der KI keinen Zugriff auf den Bildschirm geben. Dieses VM-Modell funktioniert bei manchen Problemen sehr gut, aber sein Einsatzbereich ist bedauerlich eng.
  • Dieses Problem entstand letztlich nicht in Claude Code, sondern auf der Claude-AI-Website.

• Dass „Hallo, hier ist Cloudflare. Bitte geben Sie mir personenbezogene Daten“ funktioniert, zeigt, warum Prompt Injection zwangsläufig ein dauerhaftes Problem bleibt. Entweder schränkt man Modelle so stark ein, dass sie kaum noch nützlich sind, oder man lässt solche Angriffe einsickern und erschafft damit das wohl unsicherste Konzept der Internetgeschichte: Roboter, die sich austricksen lassen.

  • Wie Social Engineering wird das in gewissem Maß wohl für immer bleiben, und wir werden Abwehrmaßnahmen aufschichten, bis eine gesellschaftlich akzeptable Basis erreicht ist. Keine besonders beruhigende Schlussfolgerung, aber die bereits geöffnete Büchse der Pandora lässt sich schwer wieder schließen.
  • Die gödelschen Grenzen sicherer KI in Prompts wurden unter https://matthodges.com/posts/2025-08-26-music-to-break-model... behandelt.
  • Es ist schwer zu akzeptieren, dass verarbeitete Daten ein LLM per Dialog dazu bringen können, Sicherheitsgrenzen zu durchbrechen. Bösartige Prompts sind keine Metapher, sondern echte Angriff-Strings; dass eine solche Technologie breit für automatisierte Interaktionen eingesetzt wird und zugleich logisch und grundsätzlich nicht begrenzt ist, ist absurd.
    Es wirkt wie eine Architektur, in der man ohne funktionales Verständnis oder Trennung der internen Abläufe einen einzigen riesigen Block gut zureden muss, damit er handelt, und dann nur hoffen kann, dass ein Angreifer ihm nicht noch überzeugender zuredet.

• Ich hatte kürzlich in der ChatGPT-iPhone-App ein ziemlich unheimliches Erlebnis. Ein enger Freund fragte mit seinem eigenen Account nach einem Problem mit einem smarten Futterautomaten für Haustiere, und ChatGPT verwendete in der Antwort den Namen meines Haustiers.
  Es ist kein gebräuchlicher Name, und wegen der Verbindung zu meinem Freund war es schwer, das für Zufall zu halten. Wenn man bedenkt, dass mein Freund schon einmal in unserem WLAN war, frage ich mich, ob es Cache-Verunreinigung oder ein Leck von Session-Daten gibt.

  • Bei ChatGPT scheint Memory standardmäßig aktiviert zu sein und Nutzerinformationen über alle Unterhaltungen hinweg zu speichern. Auch bei mir fügt es bei Rezeptantworten, obwohl die Frage nichts mit Visa zu tun hat, Dinge hinzu wie: „Diese Zutaten sind im Laden leicht erhältlich, daher ist das Visum kein Problem.“
    Da die Funktion noch nicht ausgereift ist, ist es besser, Memory auszuschalten; wenn der Freund jedoch seinen eigenen Account verwendet hat, erklärt das dieses Phänomen nur schwer.

• Claude Code hat beim Scrapen von SEC-Dokumenten meinen Namen und meine E-Mail-Adresse in den User-Agent geschrieben. Dafür war nicht einmal ein raffinierter Prompt nötig, und die Idee an sich ist nicht völlig schlecht, aber ich hätte gern vorher gefragt werden wollen.

  • Die Ursache liegt beim SEC-EDGAR-Tool. Die Edgar-MCP-Dokumentation weist an, die Umgebungsvariable SEC_EDGAR_USER_AGENT="Your Name ([e-mail])" zu setzen, also hat Claude lediglich die Anweisung befolgt. Vielleicht ist genau das sogar noch gefährlicher.
  • Ich frage mich, wie entdeckt wurde, dass Claude das getan hat.
  • Ich frage mich, warum es nicht für eine ganz schlechte Idee gehalten wird, Name und E-Mail-Adresse einzutragen.

• Ich frage mich, wie viele Nutzer die globale Memory-Funktion aktiviert haben, die für alle Unterhaltungen gilt. Solcher Memory dürfte am Ende die Ausgabequalität beeinträchtigen.

  • Selbst wenn man etwas fragt, das mit dem aktuellen Projekt nichts zu tun hat, nimmt es wegen des Memory immer fälschlich an, es gehe um das bestehende Projekt. Wenn man korrigiert: „Nein, ich frage zu PostgreSQL“, versteht es nicht, warum man eine separate Unterhaltung geöffnet hat, und aktualisiert stattdessen sogar den Memory so, als würde das Projekt PostgreSQL verwenden.
    Andererseits hilft es in Momenten, in denen man nicht jedes Mal langatmig den Hintergrund erklären muss.

• Deshalb aktiviere ich Memory nicht und nutze Claude Code aus anderen Gründen ebenfalls nicht. Das aktuelle Memory-System ist viel zu grob gestrickt, um nützlich zu sein.

  • Bei mir war Memory eher hinderlich als hilfreich. Es holte jedes Mal kaum relevante gespeicherte Informationen hervor und tat so, als wolle es damit angeben, ein oder zwei Dinge mehr zu wissen, weshalb ich es schließlich abgeschaltet habe.
  • Ich frage mich, ob dieses Problem wirklich nur auf Memory beschränkt ist. Könnten nicht auch Informationen, auf die das Modell gerade zugreifen kann – etwa aktuelle Projektdaten, Code oder Zugangsdaten – auf die gleiche Weise offengelegt werden?