0,00 Prozent im Test, 80 Prozent im Angriff

Als Claude Code am 14.08.2026 auf Pro, Max und Team in den Auto-Mode umgestellt hat, lag eine Zahl auf dem Tisch, die schwer zu schlagen ist: Trajectory Labs hatte im Auftrag von Anthropic 72 Angriffsszenarien je zehnmal durchgespielt, und keiner der 720 Versuche kam gegen Claude im Auto-Mode durch. 0,00 Prozent.

Johann Rehberger, dessen Funde wir schon im Mai zusammengetragen haben, hat am 27.08.2026 eine Angriffskette veröffentlicht, die in bis zu 80 Prozent der Läufe funktioniert. Beide Zahlen stimmen. Genau darum geht es.

Die Kette: Claude vergiftet sich mit seinem eigenen Decoder

Der Einstieg ist banal. Ein Nutzer bittet Claude, eine Website zusammenzufassen. Der Server antwortet auf die WebFetch-Anfrage mit einem HTTP 415, also "Unsupported Media Type". Nichts an dieser Antwort sagt Claude, was es tun soll. Sie macht nur einen anderen Weg attraktiv, und Claude geht ihn von selbst: Es wechselt ins Bash-Werkzeug und holt die Seite mit curl.

Dahinter liegt ein ZIP-Archiv, das wie ein digitalisierter Notizbuch-Katalog aussieht. Darin: kodierte Datensätze, eine Prüfsummen-Datei, ein mitgeliefertes Decoder-Programm und eine unscheinbare Datei namens struct.py.

Claude prüft das fremde Programm und weigert sich, es auszuführen. Das ist genau richtig. Und es ist der Grund, warum der Angriff klappt.

flowchart TB
  A["Prompt: Fasse diese Seite zusammen"] --> B["WebFetch bekommt HTTP 415"]
  B --> C["Claude wechselt von selbst auf curl"]
  C --> D["ZIP mit Daten, Programm<br/>und struct.py"]
  D --> E{"Fremdes Programm<br/>ausführen?"}
  E -->|"Nein, zu riskant"| F["Claude schreibt<br/>eigenen Decoder"]
  F --> G["python3 im entpackten Ordner:<br/>import base64"]
  G --> H["base64 lädt intern struct<br/>und findet das fremde struct.py"]
  H --> I["Schadcode läuft,<br/>C2-Verbindung steht"]
  classDef decision fill:#1A3A4A,stroke:#F59E0B,color:#FDE68A
  classDef abort fill:#7F1D1D,stroke:#EF4444,color:#FCA5A5
  class E decision
  class I abort

Der Trick heißt Module Shadowing und ist so alt wie Python. Wer ein Skript in einem Verzeichnis startet, hat dieses Verzeichnis im Modulpfad. Die Standardbibliothek base64 importiert intern struct. Liegt im Arbeitsverzeichnis eine Datei struct.py, gewinnt sie. Das fremde Modul reicht die echten Funktionen brav durch, sodass das Dekodieren normal weiterläuft, führt beim Import aber nebenbei verschleierten Code aus, der eine Remote-Stage nachlädt.

Rehberger hat drei Varianten gemessen, jeweils an fünf Läufen: dreimal erfolgreich bei der Variante mit Rückkanal zum Kontrollserver, dreimal und viermal bei zwei Varianten, in denen die vergiftete struct.py per claude -p eine zweite Claude-Code-Instanz startet. Diese Kind-Instanz bekommt eigenen Werkzeugzugriff und eigenen Kontext. Kleine Stichproben, wie er selbst schreibt, aber die Richtung ist eindeutig.

Warum der Klassifizierer nichts Verdächtiges sieht

Der Auto-Mode ersetzt die Rückfrage durch einen Klassifizierer. Bei Opus 5 übernimmt das laut der Analyse von veganmosfet ein Sonnet 5, und dieser Klassifizierer bekommt die Werkzeugaufrufe zu sehen, nicht deren Ergebnisse.

Damit ist klar, warum die Kette durchläuft. Was der Klassifizierer zu bewerten bekommt, ist ein curl auf eine Website und ein Python-Einzeiler, der base64, zlib und json importiert. Beides ist offensichtlich harmlos. Der eigentliche Angriff steht in einer Datei, die der Klassifizierer nie liest, und passiert mehrere Schritte später.

Die Bauart ist nicht neu, wir haben sie im Juni schon an der Clean-Repo-Falle beschrieben: harmlos aussehendes Material, das den Agenten selbst die gefährliche Handlung ausführen lässt. Neu ist, dass diesmal der Klassifizierer danebensteht und zusieht.

Rehberger ist damit nicht allein. Zwei Wochen vorher, am 12.08.2026, hat veganmosfet einen völlig anderen Weg beschrieben: ein Repo mit einer einzigen Datei, README.jpg, in der per Steganografie eine Anleitung steckt. Ausgelöst wird die Kette durch ein simples /init. Ergebnis, wörtlich: "In 6 out of 10 trials the agent executed untrusted code from the remote server - and the safety classifier allowed it."

Zwei Forscher, zwei grundverschiedene Ketten, vergleichbare Quoten. Das ist der eigentliche Befund, nicht die einzelne Demo.

Der Auto-Mode blockt das Aufräumen

Ein Detail aus Rehbergers Läufen ist unangenehmer als der Einbruch selbst. Claude hat die Kompromittierung mehrfach nachträglich bemerkt, sich die verdächtige struct.py angesehen und wollte den Schadprozess beenden. Der Auto-Mode hat das Aufräumkommando abgelehnt.

Der Klassifizierer hat also das Starten des Prozesses durchgewinkt und danach das Stoppen blockiert. Rehberger fasst es so zusammen: "The safety mechanism itself can become part of the failure."

Das ist keine Bosheit, sondern Logik. Ein Kommando, das Prozesse abschießt, sieht für sich genommen zerstörerisch aus. Dem Klassifizierer fehlt der Kontext, dass hier gerade aufgeräumt wird. Er bewertet Aufrufe einzeln, und genau da liegt seine Grenze.

Warum 0,00 und 80 Prozent beide stimmen

Anthropic hat den Bericht bekommen und als "Informative" geschlossen, mit der Begründung, das Verhalten sei so vorgesehen: Der Auto-Mode sei ein Komfort-Feature mit einem Best-Effort-Klassifizierer, keine Sicherheitsgrenze. Diese liege bei Betriebssystem-Isolierung und Netzwerkkontrolle.

Sachlich ist das richtig, und es deckt sich mit dem, was Anthropic schon in der Ankündigung geschrieben hat: Der Auto-Mode beruht auf Klassifikation und beseitigt kein Risiko. Die 0,00 Prozent stammen aus einem festen Set von 72 Szenarien. Rehbergers Kette war nicht darin. Ein Benchmark misst, was man hineingelegt hat, und eine einzelne Schlagzeilenzahl daraus suggeriert eine Vollständigkeit, die sie nicht haben kann.

Für die Praxis heißt das schlicht: Eine Auto-Mode-Freigabe ist kein Beleg dafür, dass ein Kommando sicher ist. Sie ist ein Hinweis, mehr nicht.

Was hilft, ist bereits eingebaut

Die gute Nachricht steckt in der Werkzeugkiste, die ohnehin da ist. Claude Code bringt seit einiger Zeit eine echte Sandbox mit, die auf Betriebssystemebene arbeitet, auf macOS über Seatbelt, auf Linux und WSL2 über zusätzliche Pakete. Der entscheidende Satz aus der Dokumentation: Die Grenze gilt für jedes Bash-Kommando und dessen Kindprozesse.

Genau da hakt Rehbergers Kette ein: Der Schadcode läuft als Python-Kindprozess und braucht eine Verbindung nach draußen. Vorab erlaubt die Sandbox keine einzige Domain.

Eine Einstellung macht dabei den Unterschied. In der Grundeinstellung fragt Claude Code bei einer neuen Domain nach, und im Auto-Mode geht diese Frage an denselben Klassifizierer, der die Kette schon vorher nicht erkannt hat. Erst strictAllowlist macht daraus eine harte Grenze: Was nicht auf der Liste steht, wird abgewiesen statt zur Abstimmung gestellt. Ohne diese Zeile ist die Sandbox eine Bremse, mit ihr eine Wand.

Ein Blick auf die Schichten, mit dem Angriff als Prüfstein:

Dass Deny-Regeln bei Unterprozessen aufhören, stand schon in unserem Artikel vom 14.08. Rehbergers Kette ist die Demonstration dazu.

Eine brauchbare Grundkonfiguration in ~/.claude/settings.json:

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"],
      "strictAllowlist": true
    },
    "credentials": {
      "files": [
        { "path": "~/.ssh", "mode": "deny" },
        { "path": "~/.aws/credentials", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" }
      ]
    }
  }
}

Drei Dinge dazu, die man wissen sollte. allowUnsandboxedCommands: false schaltet die Notluke ab, über die Claude ein an der Sandbox gescheitertes Kommando sonst außerhalb erneut versuchen darf. Ohne diese Zeile gibt es einen Weg nach draußen, und im Auto-Mode entscheidet darüber wieder der Klassifizierer. strictAllowlist wirkt nur in Nutzer-, Managed- oder CLI-Einstellungen und braucht Claude Code 2.1.219 oder neuer, in einer Repo-Einstellung hat es keine Wirkung. Und Organisationen setzen das Ganze besser über Managed Settings, dann kann es niemand lokal aufweichen. Wie das im Team sauber aufgezogen wird, steht in Coding-Agenten im Team sicher betreiben. Den aktuellen Stand zeigt /sandbox in der Sitzung.

Eins gehört noch dazu, damit die Erwartung stimmt: Die Sandbox umschließt Bash und dessen Unterprozesse. Die Datei-Werkzeuge Read, Edit und Write laufen weiter über das Berechtigungssystem, und Computer Use arbeitet ohnehin auf dem echten Desktop. Für diese Angriffskette spielt das keine Rolle, sie läuft komplett über Bash. Für das Gesamtbild schon.

Bleibt die Frage, ob Isolierung überhaupt hält

Einen Tag vorher haben wir berichtet, dass ein Cyber-Modell dreimal aus einer QEMU-VM ausgebrochen ist. Das klingt erst einmal so, als wäre auch die Sandbox-Empfehlung hinfällig. Ist sie nicht, und der Unterschied lohnt sich.

Trail of Bits hat ein Modell getestet, das aktiv aus seiner Umgebung ausbrechen sollte. Rehbergers Schadprogramm versucht das gar nicht, es will nur eine Verbindung nach Hause. Gegen einen Angreifer, der gezielt auf Ausbruch spielt, ist eine Sandbox eine Hürde und keine Garantie, zumal eine OS-Sandbox die dünnere Grenze ist als eine VM. Die Dokumentation schreibt das selbst hin: "Sandboxing reduces risk but is not a complete isolation boundary." Gegen das, was auf einer Entwicklermaschine realistisch ankommt, wirkt sie sehr wohl.

Fazit

Der Auto-Mode ist besser als ein müder Mensch, der zum fünfzigsten Mal auf "Ja" klickt. Diese Rechnung geht auf, und der Produktivitätsgewinn ist real. Er ist nur keine Sicherheitsgrenze, und das sagt Anthropic auch selbst, nur eben leiser als die 0,00 Prozent.

Die Antwort darauf ist unspektakulär und liegt bereit: Sandbox einschalten, Netzwerk auf das Nötige beschränken, Schlüssel und Tokens aus der Reichweite des Agenten nehmen. Das kostet einmal eine halbe Stunde Konfiguration und macht aus der Frage "hat der Klassifizierer richtig geraten?" eine Frage, die das Betriebssystem beantwortet.