Il 31 marzo 2026, un artefatto di debugging in un package npm ha esposto il codice sorgente completo del CLI di Claude Code di Anthropic. Nel giro di poche ore, il team Purple Graph di Phoenix Security ha iniziato l’analisi degli attack path, identificando 100 ipotesi iniziali che si sono ridotte a 8 vulnerabilità concrete e tre command injection confermati (CWE-78) nel sistema di risoluzione comandi, invocazione editor e helper di autenticazione del CLI.
Tutti e tre condividono la stessa root cause: interpolazione di stringhe non sanitizzate in esecuzioni valutate dalla shell. La validazione runtime ha confermato esecuzione arbitraria di comandi, evasione dell’output e esfiltrazione dati tramite il sink dell’authentication helper.
Come siamo arrivati qui
Claude Code di Anthropic è un agent AI da linea di comando distribuito come package npm sotto @anthropic-ai/claude-code. Il 31 marzo 2026 è stato scoperto un file source map JavaScript da 59.8 MB (cli.js.map) nella versione 2.1.88 del package sul registry npm. Questo artefatto di debugging mappava il bundle production minificato ai file TypeScript originali non offuscati, hostati nello storage cloud R2 di Anthropic.
L’esposizione era massiccia: oltre 1.900 file sorgente, più di 512.000 righe di TypeScript, l’intera architettura interna del CLI – dal renderer terminal basato su React al loop agentico, subsystem di autenticazione, framework plugin e layer sandbox.
Tre vulnerabilità, una root cause
L’assessment ha identificato tre sink di command injection indipendenti nel CLI:
- Command lookup vulnerability – Triggerata tramite variabile d’ambiente letta durante la detection del terminale. Zero interazione utente richiesta. Quattro varianti di payload su sei hanno raggiunto esecuzione arbitraria a runtime.
- Editor invocation vulnerability – Sfrutta un comportamento POSIX shell dove la command substitution viene valutata dentro le doppie virgolette. Il quoting del developer non fornisce protezione contro $() o backtick injection tramite file path.
- Credential helper vulnerability – Confermata attraverso tre tecniche di escalation: creazione file locale, output evasion credential-shaped, esfiltrazione HTTP callback verso listener controllato con evidenza timestampata.
Il problema del vendor response
Anthropic ha confermato il finding lo stesso giorno. La risposta: il comportamento dell’helper è by design, analogo al credential.helper di git.
Ma ecco il punto – quella analogia rinforza il finding invece di mitigarlo. Il credential helper di git ha prodotto sette CVE dal 2020 per la stessa classe di vulnerabilità. Git ha da allora aggiunto protezioni di validazione input che questo sistema non ha per niente.
Il vendor ha confermato che in modalità non-interattiva (-p), il workspace trust dialog viene intenzionalmente skippato. Questo rimuove l’unico gate di sicurezza runtime esattamente nel contesto deployment (CI/CD, automation) dove la configurazione è più probabilmente influenzata dall’attacker.
VULN-01: Shell Injection in Command Lookup
Il command lookup utility costruisce stringhe shell command con input non sanitizzato e le esegue con interpretazione shell abilitata sul runtime path Node.js. Quando l’input proviene dalla variabile d’ambiente TERMINAL, un attacker che controlla questa variabile ottiene esecuzione arbitraria di comandi.
Root cause: interpolazione di stringhe di input esterno in command string valutata dalla shell. La funzione dice al child process executor di usare interpretazione shell, causando /bin/sh -c a valutare l’intera stringa inclusi metacaratteri.
Impact: esecuzione arbitraria comandi nel contesto processo CLI con il full permission set dell’utente.
Evidenza runtime
Il rig Purple Code Navigator di Phoenix Security ha settato TERMINAL a una serie di payload contenenti metacaratteri shell, poi triggerato il deep-link handler sotto process tracing. Quattro payload malevoli su sei hanno raggiunto side-effect execution. Process tracing ha confermato system shell che spawna child process inaspettati dalla chiamata command lookup.
VULN-02: Shell Injection in Editor Invocation
La funzione editor launch costruisce shell command string interpolando editor path e target file path in un template. Il file path viene piazzato dentro doppie virgolette nella shell string. Il developer intendeva le doppie virgolette come protezione. La semantica POSIX shell rende questa protezione inefficace per command substitution.
Root cause: fraintendimento della semantica POSIX shell double-quote. Sezione 2.2.3 della specifica: $, backtick, \, e ! mantengono significato speciale dentro doppie virgolette. Il quoting previene word splitting e glob expansion ma non previene command substitution.
Più sottile della vulnerabilità command lookup. Il codice sembra fare la cosa giusta. Un reviewer che non ha interiorizzato POSIX shell quoting probabilmente lo mancherebbe.
VULN-03: Il Mostro – Authentication Helper Command Injection
Questa è quella pericolosa. Quattro credential helper values vengono eseguiti come shell command con interpretazione shell abilitata. Il trust dialog viene skippato in modalità non-interattiva. Validata attraverso tre tecniche di escalation.
Tecnica 1: Local Side-Effect Execution
Prima validazione: il sink helper interpreta metacaratteri shell. Helper value contenente command separator seguito da side-effect command iniettato via settings flag. CLI ha stampato authentication failure. Marker file è apparso su disco. L’esistenza del file è conferma binaria: shell ha interpretato il separator ed eseguito entrambi i comandi.
Tecnica 2: Credential-Shaped Evasion
Seconda validazione: helper output può mimare un vero prefisso API key Anthropic mentre esegue attacker commands silenziosamente. Pattern evasion che un vero attacker userebbe: helper appare funzionare normalmente, produce output credential-shaped, mentre secondo comando gira in background.
Authentication failure non previene exploitation. Payload attacker completa indipendentemente dal fatto che credential funzioni. In scenario reale, helper leggerebbe legitimate API key dall’environment, la invierebbe all’attacker, e la echoeggerebbe come output così CLI autentica con successo. Utente vede comportamento normale. Attacker ha la key.
Tecnica 3: HTTP Callback Exfiltration
Terza validazione: injection raggiunge network. Callback receiver girava su porta locale. Helper value costruito per outputtare fake credential mentre simultaneamente inviava HTTP POST al receiver con contenuto scelto dall’attacker.
Callback server log (3 run indipendenti) – tre callback across tre run indipendenti. Contenuto payload diverso in ognuno. Ogni callback ha consegnato esattamente i dati inviati, con timestamp UTC. Output del CLI stesso mostrava expected authentication error dopo che HTTP POST aveva già completato.
Multi-line file exfiltration runs hanno provato l’attacco è data-driven: rig ha letto specific line ranges da file e trasmesse attraverso helper sink. Helper può leggere contenuti file arbitrari e inviarli a qualsiasi endpoint network-reachable.
Il pericolo credential exfiltration
In CI/CD runner, helper esegue con accesso a tutto quello che pipeline ha: cloud IAM role credentials, API tokens, deploy keys, registry passwords, source code, build artifacts. Refresh helpers (awsAuthRefresh, gcpAuthRefresh) girano periodicamente durante sessione. Malicious refresh value dà all’attacker esecuzione ricorrente.
Se environment contiene valid Anthropic API key, malicious helper può leggerla, esfiltrarla, ed echeggiarla come output. CLI autentica con successo. No error. No warning. Utente vede comportamento normale. Attacker ha la key e può consumare account e quota della vittima.
Attack Scenarios
Scenario A: Developer workstation via .env poisoning (VULN-01) – Attacker contribuisce .env file a repository condiviso contenente poisoned TERMINAL value. Developer clona repository. Shell o dotenv loader setta variabile. Developer apre Claude CLI deep link. Terminal detection legge TERMINAL, passa a command lookup, Node.js fallback esegue injected command. No prompt.
Scenario C: CI/CD credential theft via PR (VULN-03) – Attacker submits PR che modifica .claude/settings.json con malicious helper value. CI pipeline fa checkout PR branch, gira CLI in non-interactive mode, helper fires. Environment credentials (cloud IAM, API tokens, deploy keys) esfiltrate a endpoint attacker. Intera chain richiede zero user interaction.
Blast radius: CI/CD infrastructure. Cloud accounts, production deployments, artifact registries, source code.
Cosa fare adesso
Per utenti Claude Code:
- Usa environment variables per credentials, non helpers – Setta ANTHROPIC_API_KEY direttamente, bypassa helper execution path completamente
- Review .claude/settings.json in code review – Tratta settings changes con stesso scrutiny di CI/CD configuration changes
- Non usare -p mode con untrusted workspaces – Se CI/CD gira CLI contro PR branches da external contributors, workspace settings sono attacker-controlled
- In CI/CD, genera settings da trusted sources – Non caricare settings dal checked-out workspace
- Audit existing pipelines per CLI invocations che operano su PR branches o fork-contributed workspaces
Il punto vero
Questi sono CWE-78 command injection. Su ogni lista “top vulnerability” da oltre un decennio. Il fix (argv-based execution con shell: false) è ugualmente well-established.
Quello che rende questi finding significativi è il contesto. Un AI coding agent gira con full permission set del developer, in ambienti dove configuration può essere attacker-influenced e trust dialogs sono assenti. Stessa shell injection che sarebbe local concern in traditional tool diventa credential exfiltration e supply-chain compromise vector quando siede dentro agent con broad access e non-interactive automation mode marketato per CI/CD use.
Agentic loop security controls (permission engine, dangerous-pattern blocking, sandbox) sono well-designed ma proteggono wrong boundary per questi finding. Injection sinks sono in subsystems che eseguono prima o fuori agentic loop. Authentication helpers girano fuori sandbox e permission engine completamente.
Il rischio non è mitigato da current controls. È riducibile da users attraverso raccomandazioni sopra. È eliminabile da vendor attraverso shell: false execution, metacharacter rejection, structured command configuration, auditable helper logging.
Fino a quando quei cambiamenti non shippano, injection paths sono open.
