Gli agenti AI per la scrittura di codice promettono di automatizzare interi flussi di sviluppo, ma per farlo hanno bisogno di eseguire comandi shell, modificare file e talvolta chiamare API esterne in totale autonomia. Per questo motivo i tool più seri li fanno girare dentro una sandbox: un ambiente isolato che limita cosa l’agente può leggere, scrivere o eseguire, con un sistema di approvazione umana per le operazioni più rischiose. Una vulnerabilità critica scoperta in DeepSeek Harness, il tool open source di DeepSeek per eseguire coding agent in locale, dimostra però quanto sia fragile questo modello quando il “guardiano” della sandbox è raggiungibile senza autenticazione. Con un singolo comando shell, l’agente stesso poteva disattivare le proprie restrizioni — bypassando sia il file-sandbox sia i prompt di approvazione.
Cos’è DeepSeek Harness e come funziona la sua sandbox
DeepSeek Harness espone un’interfaccia web locale che funge da pannello di controllo per la sessione dell’agente: consente di monitorare l’esecuzione, approvare le azioni sensibili e, soprattutto, gestisce lo stato di sicurezza della sandbox. Come molti tool della stessa categoria, l’harness fornisce all’agente stesso l’indirizzo di questa interfaccia e l’identificativo di sessione, così che possa interagirci per richiedere operazioni o notificare eventi.
È proprio questa combinazione — interfaccia locale privilegiata + agente che ne conosce i dettagli di accesso — ad aver reso possibile l’attacco.
Il meccanismo della vulnerabilità (CVE-2026-82533)
La falla, tracciata come CVE-2026-82533 con un punteggio CVSS 9.4 (critico) e classificata come CWE-807 (“Reliance on Untrusted Inputs in a Security Decision”), nasce dalla combinazione di tre debolezze distinte:
- Nessuna autenticazione sull’API web locale del control-plane: chiunque potesse raggiungere l’endpoint poteva invocarlo senza credenziali.
- Validazione errata dell’origine della richiesta: il servizio si fidava del valore
Hostfornito dal client invece di verificare l’effettiva origine della connessione TCP (host header spoofing). - Superficie di attacco esposta all’agente stesso: dato che l’harness comunica all’agente indirizzo e session ID dell’interfaccia, un agente compromesso (ad esempio tramite prompt injection da codice o output di terze parti) aveva già tutto ciò che serviva per attaccare il proprio control-plane.
Sfruttando lo spoofing dell’header Host, un attore malevolo — o l’agente stesso se manipolato — poteva raggiungere l’interfaccia in loopback e inviare una richiesta che impostava la sessione in modalità danger-full-access. Questo stato elimina la sandbox sul filesystem e disattiva i prompt di conferma per le operazioni sensibili. Con questo accesso era inoltre possibile invocare direttamente endpoint privilegiati come commands/execute e leggere le conversazioni salvate in sessione, senza mai fornire una credenziale.
Versioni interessate e correzione
Le versioni 0.1.1-rc.2 e precedenti sono vulnerabili. Il fix introduce un’autenticazione a token monouso per l’interfaccia locale: al momento dell’avvio, il tool stampa un token che il browser scambia con un cookie firmato, richiesto da quel momento per ogni chiamata al control-plane.
| Versione | Stato |
|---|---|
| ≤ 0.1.1-rc.2 | Vulnerabile |
| 0.1.2-alpha.1 | Fix pubblicato solo su GitHub (non su npm) |
| 0.1.2-alpha.2 | Prima release corretta pubblicata su npm |
| 0.1.2-rc.1 (corrente) | Consigliata per l’aggiornamento |
È importante notare il dettaglio sulla distribuzione: chi installa il pacchetto da npm senza controllare la versione esatta rischiava di restare esposto anche dopo l’annuncio della patch, perché la prima correzione non era disponibile su quel registro.
Non è un caso isolato: un problema architetturale
La vulnerabilità era già stata segnalata autonomamente dalla community su GitHub Discussions il 13 e 14 agosto, prima ancora del report ufficiale a VulnCheck (24 agosto) da parte di OX Research. Analisi successive hanno evidenziato pattern simili — API di controllo locali prive di autenticazione solida, affidamento eccessivo sull’header Host o su altri dati forniti dal client — anche in altri framework per agenti AI, tra cui LangChain, CrewAI e Google ADK. Il messaggio per chi lavora con questi strumenti è chiaro: la logica di orchestrazione e di esecuzione tool-calling degli agenti AI è oggi un’area con superficie di attacco ancora immatura, non un caso isolato di un singolo progetto.
Come proteggersi
Per chi gestisce infrastrutture dove girano coding agent locali (server di sviluppo condivisi, VM CI/CD, workstation con accesso a repository sensibili) valgono alcune raccomandazioni pratiche:
- Aggiornare immediatamente DeepSeek Harness alla versione 0.1.2-rc.1 o successiva, verificando che il pacchetto installato provenga effettivamente da npm e non da una cache vecchia.
- Verificare l’esposizione delle API locali: controllare che le porte del control-plane non siano raggiungibili da reti diverse dal loopback, e che non ci siano tunnel, reverse proxy o port-forwarding che le espongano inavvertitamente (es. tramite VS Code Remote, SSH -L o container con rete condivisa).
- Rivedere le sessioni e le conversazioni eventualmente esposte durante il periodo di vulnerabilità, specialmente se contenevano segreti, token o codice proprietario.
- Applicare il principio del minimo privilegio agli agenti: eseguirli con utenti dedicati a permessi limitati, evitando di lanciarli con lo stesso utente che ha accesso a credenziali cloud o chiavi SSH.
- Non fidarsi della sola autenticazione basata su header HTTP per servizi locali critici: preferire token generati a runtime, socket Unix con permessi ristretti, o mutui TLS quando possibile.
Conclusione
Il caso DeepSeek Harness è un promemoria utile per chi sta integrando agenti AI autonomi nei propri flussi di sviluppo o di sistema: la sandbox è utile solo quanto il meccanismo che la protegge, e un’interfaccia di controllo locale non autenticata è, di fatto, una porta sul retro. Con CVSS 9.4 e un percorso di sfruttamento che richiede solo un comando HTTP verso localhost, questa vulnerabilità mostra come la sicurezza degli agenti AI vada trattata con lo stesso rigore — se non maggiore — riservato a qualsiasi altro servizio che espone comandi privilegiati in rete, anche se “in rete” significa solo 127.0.0.1.
Fonte: The Hacker News e VulnCheck Advisory, via 4sysops.