Claude Cowork leakt Nutzerdateien nach außen

 (promptarmor.com)
6 Punkte von GN⁺ 2026-01-15 | 2 Kommentare | Auf WhatsApp teilen
  • Durch Ausnutzung einer Schwachstelle in der Code-Ausführungsumgebung von Claude Cowork können Angreifer Dateien von Nutzern in ihr eigenes Anthropic-Konto hochladen
  • Die Schwachstelle wurde bereits in der Claude.ai-Chatumgebung gemeldet, ist aber weiterhin ungepatcht und besteht in Cowork unverändert fort
  • Der Angriff wird über Dokumentdateien mit versteckter Prompt-Injection ausgeführt; während Cowork diese analysiert, werden Dateien automatisch nach außen übertragen
  • Ohne menschliche Zustimmung führt Cowork mit dem API-Schlüssel des Angreifers eine Datenexfiltration über die Anthropic API aus
  • Die Struktur macht eine Exposition selbst für normale Nutzer leicht möglich und zeigt die Sicherheitsrisiken von AI-Agenten und die Bedeutung von Abwehr gegen Prompt-Injection

Überblick über die Schwachstelle

  • Claude Cowork ist eine von Anthropic veröffentlichte Research Preview eines AI-Agenten für allgemeine Büroarbeit und enthält Internetzugang
  • PromptArmor demonstrierte, dass sich über eine ungepatchte Schwachstelle in der Coding-Umgebung von Cowork Nutzerdateien nach außen exfiltrieren lassen
    • Die betreffende Schwachstelle wurde zuvor von Johann Rehberger in Claude.ai entdeckt und veröffentlicht; Anthropic war darüber informiert, hat sie aber nicht behoben
  • Anthropic warnte bei der Nutzung von Cowork zwar davor, auf „Verhalten zu achten, das auf Prompt-Injection hindeuten könnte“, dies wird jedoch als für Nichtfachleute praktisch unrealistische Anforderung kritisiert
  • PromptArmor führte eine öffentliche Demonstration durch, um Nutzer auf dieses Risiko aufmerksam zu machen

Angriffskette (Attack Chain)

  • Der Angriff missbraucht die Allowlist der Anthropic API, um aus der VM-Umgebung von Claude Daten nach außen zu übertragen
  1. Der Nutzer verbindet einen lokalen Ordner mit vertraulichen Immobiliendateien mit Cowork
  2. Der Nutzer lädt eine Dokumentdatei (.docx) mit versteckter Prompt-Injection hoch
    • Das Dokument tarnt sich als „Skill“-Datei; die Injection ist mit weißer 1-Punkt-Schrift und 0,1 Zeilenabstand versteckt
  3. Der Nutzer fordert Cowork auf, mithilfe des hochgeladenen „Skills“ Dateien zu analysieren
  4. Die Injection manipuliert Cowork dazu, eine cURL-Anfrage mit dem Anthropic-API-Schlüssel des Angreifers auszuführen und die Dateien des Nutzers in das Konto des Angreifers hochzuladen
    • Automatische Ausführung ohne menschliche Freigabe
    • Die VM von Claude blockiert die meisten externen Netzwerke, aber die Anthropic API wird als vertrauenswürdig durchgelassen
  5. Der Angreifer kann in seinem Anthropic-Konto die Dateien des Opfers einsehen und mit Claude darüber sprechen
    • Die exfiltrierten Dateien enthielten Finanzinformationen und teilweise Sozialversicherungsnummern (SSN)

Modellspezifische Resilienz (Model-specific Resilience)

  • Der obige Angriff wurde mit dem Modell Claude Haiku demonstriert
  • Claude Opus 4.5 ist widerstandsfähiger gegen Injection, doch in der Cowork-Umgebung lässt sich dieselbe Schwachstelle beim Datei-Upload über indirekte Prompt-Injection weiterhin ausnutzen
    • In den Tests wurde angenommen, dass ein Nutzer einen bösartigen Integrationsleitfaden hochlädt; dabei wurden Kundendaten in das Konto des Angreifers exfiltriert

Denial of Service über fehlerhafte Dateien (DOS via Malformed Files)

  • Die API von Claude erzeugt wiederholt Fehler, wenn Dateiendung und tatsächliches Format nicht übereinstimmen
    • Beispiel: Wird versucht, eine einfache Textdatei mit der Endung .pdf zu lesen, treten anschließend in allen weiteren Gesprächen API-Fehler auf
  • Solche Fehler können für begrenzte Denial-of-Service-(DOS)-Angriffe über indirekte Prompt-Injection missbraucht werden
    • Dabei wird dazu verleitet, fehlerhafte Dateien zu erzeugen oder hochzuladen, wodurch Fehlermeldungen im Claude-Client und in der Anthropic-Konsole ausgelöst werden

Erweitertes Risiko von Agenten (Agentic Blast Radius)

  • Cowork ist dafür ausgelegt, mit der gesamten alltäglichen Arbeitsumgebung zu interagieren, darunter Browser, MCP-Server und AppleScript-Steuerung
  • Dadurch steigt die Wahrscheinlichkeit, dass sensible Daten und nicht vertrauenswürdige Daten gemeinsam verarbeitet werden
  • Die Angriffsfläche für Prompt-Injection wächst fortlaufend, und bei der Konfiguration von Konnektoren ist Vorsicht geboten
  • In dieser Demonstration wurden keine Konnektoren verwendet, aber Konnektoren könnten für normale Nutzer ein zentraler Risikofaktor sein

Verwandte Beiträge

2 Kommentare

 
laeyoung 2026-01-15

Auch in Simon Willisons Rückblick zu Claude Cowork gab es Bedenken wegen Prompt-Injection-Angriffen, das ging schnell.
 
GN⁺ 2026-01-15
Hacker-News-Kommentare

  • Wenn man feststellt, dass ein Anthropic API missbraucht wird, kann man den API-Schlüssel auf GitHub Gist oder in ein öffentliches Repository hochladen
    Anthropic ist GitHub-Scanning-Partner, daher wird der Schlüssel fast sofort widerrufen
    Danach kann man den Gist wieder löschen, und andere Anbieter wie OpenAI verhalten sich ähnlich
    Relevante Dokumentation: Anthropic API Key Best Practices, GitHub Secret Scanning Patterns

    • Das ist nicht empfehlenswert, weil es riskant ist, falls GitHubs Token-Scanning-Dienst ausfällt
      Idealerweise sollte GitHub eine allgemeine API zum Widerruf von Tokens bereitstellen
      Oder noch besser: die Widerrufsfunktion direkt in privaten Repositories aktivieren
    • Das fühlt sich an wie Schach gegen Hacker spielen
    • Man kann den Schlüssel doch einfach direkt in der Anthropic-Konsole widerrufen; ich frage mich, warum man es so kompliziert macht
    • Ich halte das für eine ziemlich clevere Lösung, von so einer Methode höre ich zum ersten Mal
    • Wenn ein Angreifer die Datei aber abzieht und in sein eigenes Anthropic-Konto übernimmt, bedeutet das letztlich, dass die ganze Welt auf dieses Konto zugreifen kann, was riskant ist

  • In der Demo wurde Prompt Injection mit einer .docx-Datei vorgeführt, die durch kleine Schrift versteckt war, aber in der Praxis reicht schon eine einfache Markdown-Datei
    Zum Beispiel würde schon eine Beschreibung wie „Claude lernt Verhandlungstechniken für Kredite“ dazu führen, dass viele Leute sie nutzen, ohne sie überhaupt zu öffnen
    Eine .md-Datei könnte sogar wirksamer sein als .docx, weil sie weniger Verdacht erregt

    • Das ist wie ein schlauer Bär gegen eine Mülltonne, die sich nicht öffnen lässt
    • Aber nicht alle Nutzer sehen das so
      In manchen Branchen gilt zum Beispiel DOCX immer noch eher als normal als PDF
      In solchen Umgebungen könnte eine .md-Datei eher wie ein Werkzeug für Hacker wirken

  • Solche Probleme waren von Anfang an absehbar
    Solange Prompt Injection nicht gelöst ist, wird sich das weiterholen
    Wenn man sich HN im Jahr 1999 vorstellt, erinnert die Stimmung an die frühen Reaktionen auf SQL Injection, nach dem Motto „Bobby Tables hat die DB gelöscht“

    • Der Vergleich ist interessant, aber nicht ganz präzise
      Schon Anfang der 2000er haben wir gesagt, man solle parametrisiertes SQL statt String-Interpolation verwenden
      Auch heute sind alle nötigen Werkzeuge vorhanden; das Problem ist, dass Menschen Geschwindigkeit vor Sicherheit stellen
      Ironischerweise wurde dieser Wettbewerb von OpenAI losgetreten, das Sicherheit und Alignment betont hat
    • Ich frage mich, ob sich das wie bei SQL Injection durch Input-Sanitization lösen ließe
      Man könnte etwa Benutzereingaben mit bestimmten Tokens (@##)(JF) umschließen und Anweisungen darin nicht ausführen
      Es wirkt so, als müsste schon simples find/replace reichen, also frage ich mich, ob ich etwas übersehe
    • Das grundlegendere Problem ist, dass sich das selbst mit höherer Intelligenz womöglich nicht lösen lässt
      Im Gegenteil: Je klüger die AI wird, desto größer könnte das Risiko werden
    • Ich experimentiere gerade mit einem Prepared-Statement-Muster für Agenten
      Vor jedem Tool-Aufruf muss ein signierter „Warrant“ vorgelegt werden, damit nur erlaubte Befehle ausgeführt werden
      So soll Prompt Injection mechanisch blockiert werden, selbst wenn sie auftritt

  • Es fühlt sich an, als würde wieder ein Auto-Execution-Bug auftauchen, nach dem Motto „Wenn eine Datei verdächtig ist, führe sie einfach wie ein Programm aus“
    Schon zu Windows-XP-Zeiten hatten wir solche Probleme, und Microsoft hat AutoRun schließlich abgeschaltet
    Auch promptbasierte Systeme müssen klar trennen, was vertrauenswürdig ist

  • Ich halte es für problematisch, dass AI-Unternehmen die Risiken nur „anerkennen“ und von Nutzern unrealistische Vorsichtsmaßnahmen verlangen

    • Die meisten Erklärungen nutzen die Analogie zu „SQL Injection“, aber ich finde, es ähnelt eher einem Phishing-Angriff
      Wenn man zum Beispiel einen „Oma-Bot“ baut, der E-Mails sortiert, könnte der auf eine Betrugs-Mail vom nigerianischen Prinzen hereinfallen
    • Am Ende ist das kaum etwas anderes als zu sagen: Um dieses Produkt sicher zu nutzen, nutz es am besten gar nicht

  • Das scheint ein Problem zu sein, das durch Claudes implizites „Skill“-System entsteht
    Es ist nicht explizit wie ein /slash-Befehl, sondern besteht nur aus Anweisungen wie „wie man Dateien extrahiert“
    Deshalb kann schon die Verwendung von Wörtern wie „decompress“ oder „extract“ eine automatische Ausführung auslösen
    Diese Struktur macht es Prompt Injection leicht, heimlich neue Fähigkeiten einzuschleusen
    Deshalb braucht es ein explizites und statisch registriertes Tool-System
    Man könnte zum Beispiel ein Tool wie Extract(path) bauen und nur Read oder Bash("tar *") per Whitelist zulassen
    Dann ließe sich auch ein Freigabeprozess durch Menschen ergänzen, und während einer Session würden keine neuen Tools registriert

  • Frühere verwandte Fälle und die offizielle Antwort von Anthropic sind in diesem Blogbeitrag zusammengefasst

  • Etwas anderes Thema, aber ich frage mich, ob es Anbieter gibt, die Data-Exfiltration-PoCs als Service anbieten
    Ich würde besonders gern toxische Payloads in CLAUDE.md testen, wenn Claude in einer externen CI-Umgebung läuft

  • Die jüngsten Aktivitäten von promptarmor sind beeindruckend
    Sie spielen eine große Rolle dabei, Produktteams für Qualität zur Verantwortung zu ziehen

    • Allerdings haben auch sie ein Eigeninteresse daran, Produkte über Fear Marketing zu verkaufen
      Für einen echten Angriff müsste das Opfer Claude Zugriff auf sensible Ordner geben und dann dazu gebracht werden, ein DOCX mit unsichtbarer Prompt Injection hochzuladen
      Außerdem wird der Inhalt der Injection dem Nutzer bei der Markdown-Ausgabe sichtbar
      Der Angreifer muss seinen eigenen API-Schlüssel verwenden und ist daher nachverfolgbar
      Der Angriff funktioniert nur mit einer alten Haiku-Version
      Am Ende wirkt es so, als würde promptarmor für den Verkauf übertreiben

  • Unser Team beschränkt Agent-VMs so, dass sie nur mit pip, npm, apt kommunizieren können
    Außerdem überwachen wir die Größe von Ausgabeanfragen, um ungewöhnliche Datenabflüsse zu verhindern

    • Aber das ist keine grundlegende Lösung
      Das dreifache Problem aus AI-Missbrauch, Lecks und Autonomie lässt sich nicht beheben, indem man nur eine Seite blockiert
      Selbst in kleinen Anfragen können Geheimnisse kodiert werden, und nicht ausgerichtete AI findet solche Leckpfade von selbst
    • Interessanter Ansatz, aber ich frage mich, ob ein Angreifer nicht trotzdem die Codebasis des Nutzers als Paket hochladen könnte