Il server Git MCP di Anthropic contiene tre vulnerabilità critiche che permettono lettura di file arbitrari, cancellazioni e potenziale esecuzione di codice remoto attraverso prompt injection e chaining di tool MCP. Le falle, scoperte da Cyata Research, colpiscono la reference implementation ufficiale e hanno implicazioni dirette per IDE e assistenti AI come Cursor e Windsurf, oltre a tutti gli ambienti che adottano MCP senza hardening.
mcp-server-git Anthropic è finito sotto i riflettori dopo che Cyata Research ha dimostrato come tre vulnerabilità distinte, identificate come CVE-2025-68143, CVE-2025-68145 e CVE-2025-68144, consentano ad attaccanti di abusare dei tool Git esposti dal server MCP per ottenere accesso a file sensibili, cancellare contenuti e, in scenari più avanzati, arrivare all’esecuzione di codice. Il punto critico non è solo tecnico, ma concettuale: questi attacchi non richiedono accesso diretto al sistema. È sufficiente manipolare il modello linguistico attraverso prompt injection provenienti da contenuti apparentemente innocui, come README, repository o pagine web.
Il risultato è un cambio di paradigma nella sicurezza AI-powered, dove il confine tra input testuale e azione sul filesystem diventa estremamente fragile.
Cosa leggere
Server Git MCP di Anthropic e origine delle vulnerabilità
Il protocollo MCP, introdotto da Anthropic nel novembre 2024, nasce per consentire agli assistenti AI di interagire con sistemi esterni come filesystem, database e repository Git. Il server Git MCP ufficiale, distribuito come pacchetto Python mcp-server-git, funge da bridge tra il modello e il comando Git locale, eseguendo azioni sulla base di istruzioni generate dall’LLM.
Cyata Research ha analizzato questa reference implementation e ha individuato una serie di assunzioni di sicurezza errate. La prima riguarda git_init, che nella versione vulnerabile accettava percorsi filesystem forniti dall’utente senza alcuna validazione. Questo comportamento, formalizzato nella CVE-2025-68143 con CVSS 8.8, permetteva di inizializzare repository Git in directory arbitrarie, incluse cartelle sensibili come /home/user/.ssh. Da quel momento, altri comandi come git_log o git_diff potevano leggere e caricare nel contesto del modello contenuti che non avrebbero mai dovuto essere accessibili.
La seconda vulnerabilità, CVE-2025-68145 con CVSS 7.1, riguarda un bypass logico nella validazione del percorso del repository. Il parametro repo_path veniva preso direttamente dagli argomenti della richiesta e passato a git.Repo(repo_path) senza essere confrontato con il percorso configurato tramite flag –repository. In pratica, qualunque repository presente sul sistema diventava accessibile, vanificando completamente il concetto di sandbox.
La terza falla, CVE-2025-68144 con CVSS 8.1, colpisce i comandi git_diff e git_checkout. Gli argomenti venivano inoltrati alla CLI Git senza sanitizzazione, consentendo l’iniezione di flag arbitrari come –output, utilizzabili per sovrascrivere file sul filesystem. Cyata ha dimostrato come un payload del tipo {“target”: “–output=/home/user/.bashrc”} permetta di cancellare o azzerare file critici senza alcun controllo.
Exploit reali e abuso del contesto LLM
L’aspetto più delicato di queste vulnerabilità non è la singola primitive, ma il modo in cui possono essere sfruttate attraverso l’LLM. Cyata ha dimostrato che un attaccante può inserire istruzioni malevole all’interno di contenuti apparentemente legittimi, come README di un repository o testo caricato da una pagina web. Questi contenuti, una volta interpretati dal modello, inducono l’assistente AI ad attivare tool MCP vulnerabili.
Nel caso della lettura file, lo scenario tipico prevede la creazione di un repository Git in una directory sensibile tramite git_init, seguita dall’uso di git_log o git_diff per leggere file e caricarli nel contesto del modello, causando leakage di dati come chiavi SSH o configurazioni interne.
Per la cancellazione di file, Cyata ha mostrato due approcci. Il primo sfrutta direttamente l’iniezione di argomenti in git_diff con il flag –output. Il secondo utilizza un workflow Git più sottile: inizializzazione del repository in una directory, commit iniziale, creazione di un branch, rimozione di file e ritorno al branch originale tramite git_checkout. I file spariscono dalla working directory pur restando nello storico Git, risultando di fatto cancellati per l’utente.
Chaining MCP e esecuzione di codice
Il passaggio più critico emerge quando Cyata combina il server Git MCP con il Filesystem MCP. In questo scenario, l’attaccante usa git_init per creare un repository in una directory scrivibile, quindi sfrutta Filesystem MCP per scrivere una configurazione Git malevola in .git/config, definendo un filtro clean che esegue un comando shell. Successivamente vengono creati .gitattributes e uno script payload. Quando l’assistente AI invoca git_add, il filtro clean viene eseguito automaticamente, portando all’esecuzione di codice arbitrario.
Questo attacco non richiede permessi di esecuzione espliciti né accesso diretto al sistema. Tutto avviene come conseguenza di azioni “legittime” richieste dall’LLM. È qui che il modello MCP mostra la sua fragilità strutturale: la fiducia riposta nei tool e nel contesto diventa un vettore di attacco.
Timeline di disclosure e risposta di Anthropic
Cyata ha avviato la responsible disclosure il 24 giugno 2025 tramite HackerOne. I primi report, relativi a git_init e al bypass di repo_path, sono stati inizialmente classificati come informativi. Un secondo report del 6 luglio 2025 ha invece dimostrato l’iniezione di argomenti in git_diff e la possibilità di arrivare a code execution tramite chaining.
Anthropic ha riaperto i report il 24 luglio, li ha accettati formalmente il 10 settembre 2025 e ha assegnato gli identificativi CVE il 17 dicembre 2025. Le mitigazioni sono state distribuite in due fasi: una prima correzione in versione 2025.9.25 e il fix completo con la 2025.12.18, che ha rimosso completamente git_init, introdotto validazioni rigorose dei path e sanitizzato gli argomenti passati ai comandi Git.
Cyata ha pubblicato i dettagli solo dopo la disponibilità delle patch, sottolineando la collaborazione corretta da parte di Anthropic ma evidenziando anche il rischio di propagazione, dato che molti sviluppatori copiano la reference implementation senza modificarla.
Implicazioni sistemiche per MCP e assistenti AI
Queste vulnerabilità non colpiscono solo un singolo pacchetto, ma l’intero modello MCP. Il protocollo è pensato per rendere gli assistenti AI agenti attivi sul sistema, capaci di eseguire operazioni concrete. Quando la reference implementation contiene flaw di questo tipo, il rischio diventa sistemico.
IDE e strumenti AI-powered come Cursor e Windsurf, che utilizzano MCP per integrare Git e filesystem, ereditano implicitamente questi problemi se non applicano ulteriori controlli. In contesti aziendali, governativi o sanitari, l’esposizione può tradursi in leakage di dati sensibili o compromissione completa dell’ambiente.
Cyata sottolinea che il vero problema è la combinabilità dei server MCP. Ogni singolo tool può sembrare innocuo, ma insieme creano superfici di attacco emergenti difficili da prevedere con modelli di threat tradizionali.
Protezione dei server origine e mitigazioni operative
In parallelo, Cloudflare ha pubblicato linee guida utili per proteggere i server origine, valide anche per ambienti MCP esposti. L’approccio ruota attorno alla riduzione della superficie di esposizione. L’uso di record DNS proxy, tunnel outbound-only tramite Cloudflare Tunnel e validazione di header segreti consente di nascondere completamente l’IP dell’origine, impedendo accessi diretti.
Ulteriori misure includono l’autenticazione delle origin pulls, l’uso di certificati dedicati, allowlist degli IP Cloudflare e, per contesti enterprise, soluzioni come Magic Transit o Interconnect diretto. Queste tecniche non risolvono le vulnerabilità applicative, ma riducono drasticamente le possibilità di sfruttamento remoto.
Domande frequenti su server Git MCP Anthropic
Cosa rende queste vulnerabilità diverse da un classico bug Git?
La differenza principale è l’interazione con un LLM. Le azioni non vengono eseguite da un utente umano, ma da un assistente AI manipolabile tramite prompt injection, che trasforma input testuale in operazioni di sistema.
È necessario avere accesso al server per sfruttarle?
No. Cyata ha dimostrato che è sufficiente influenzare il contesto dell’LLM con contenuti malevoli, senza accesso diretto al filesystem o ai comandi Git.
Quali versioni di mcp-server-git sono sicure?
Anthropic raccomanda di aggiornare almeno alla versione 2025.12.18, che rimuove git_init, valida i path e sanitizza gli argomenti dei comandi.
Il protocollo MCP è intrinsecamente insicuro?
Non necessariamente, ma richiede un livello di hardening e audit molto più elevato. Le reference implementation devono essere considerate codice critico, non esempi da copiare senza revisione.
Iscriviti a Matrice Digitale
Ricevi le notizie principali direttamente nella tua casella di posta.
Niente spam, disiscriviti quando vuoi.