Vai al contenuto
ai-tools

MCP Security 2026: 30 CVE in 60 Giorni — Cosa Fare Se Usi Server MCP in Produzione

5 aprile 2026|5 min di lettura|Giovanni Liguori

30 vulnerabilità nel protocollo MCP. 60 giorni. Un ecosistema da 10.000+ server attivi.

Il dato è uscito dalla prima audit sistematica dell'infrastruttura MCP in produzione, pubblicata a marzo 2026. Non è rumore di fondo: è un segnale preciso che chi costruisce sistemi Claude-nativi non può ignorare. Il collo di bottiglia non era il codice. Era l'assunzione che l'ecosistema fosse già maturo.

Cosa è successo

Il Model Context Protocol ha avuto una crescita verticale negli ultimi 12 mesi: da poche centinaia di server nel 2025 a oltre 10.000 nel 2026, una crescita 10x. Oggi MCP è lo standard de facto per connettere Claude a sistemi esterni: GitHub, Slack, Google Drive, database, API proprietarie. Tutto passa da qui. La guida completa su come funziona MCP e come connettere API esterne è disponibile su questo blog: /blog/mcp-claude-guida-connettere-api-esterne

Il problema è strutturale: velocità di adozione e velocità di maturità della sicurezza non crescono insieme. L'analisi ha identificato 30 CVE (Common Vulnerabilities and Exposures) in 60 giorni. Alcune critiche, alcune moderate. Tutte documentate e reali. (Spoiler: non era quello che mi aspettavo di leggere a colazione.)

I vettori di attacco principali

Tool poisoning. Un server MCP compromesso può restituire tool definitions alterate che manipolano il comportamento dell'agente. Claude esegue ciò che il tool descrive: se la descrizione è corrotta, l'output è compromesso. Silenziosamente, senza errori visibili nel log.

Server impersonation. La specifica MCP non impone autenticazione forte tra client e server nella versione attuale. Un server che risponde all'indirizzo giusto è considerato attendibile. Scenario concreto: man-in-the-middle su connessioni localhost o LAN aziendale. Funziona? Purtroppo sì.

Data exfiltration tramite tool. Un tool connesso a file system o database può estrarre e restituire dati in modo offuscato nel contesto dell'agente. L'LLM non ha un layer nativo per distinguere tra dato legittimo e dato esfiltrato: si fida del tool.

Privilege escalation. Se un server MCP ha accesso a risorse con permessi elevati (un bucket GCS, un database di produzione, un'API admin), un agente compromesso può scalare privilegi senza che ci sia un layer di controllo esplicito nel mezzo. Il problema non è Claude: è l'architettura intorno a Claude.

Cosa cambia per chi usa MCP in produzione

Non è teoria astratta. Se hai connesso Claude a Slack, Google Drive, Notion o un database aziendale tramite un server MCP, stai esponendo un vettore di attacco che probabilmente non è nel tuo threat model attuale. Il problema non è che MCP sia sbagliato: è che la velocità di adozione ha superato la maturità delle pratiche di sicurezza.

Chi è entrato in produzione nei primi 12 mesi ha costruito su standard che si stavano ancora consolidando. (E niente, questo è il prezzo dell'early adoption. L'ho pagato anch'io, su qualche pipeline che avrei dovuto isolare prima.) La domanda non è se aggiornare: la domanda è quanto velocemente.

3 misure da implementare questa settimana

1. Allowlist dei server MCP. Non connettere server senza validazione esplicita. Mantieni un registro dei server autorizzati con versione e data di aggiornamento. Il rischio non sta solo nel server che hai scelto: sta in quello che viene aggiornato upstream senza che tu lo sappia.

2. Sandboxing delle connessioni. I server MCP che accedono a risorse sensibili devono girare in ambienti isolati. Un container Docker con permessi minimi e rete ristretta è già un layer di difesa significativo. Non perfetto. Significativo. Su Google Cloud Run, puoi limitare le permission al minimo indispensabile con IAM granulare.

3. Audit log delle chiamate tool. Ogni invocazione tool deve essere loggata: input, output, timestamp, agente. Non per conformità formale: per avere visibilità reale su cosa sta facendo il sistema. Senza log non sai cosa è successo. E quando succede qualcosa, è troppo tardi per ricostruirlo.

La complessità dell'ecosistema MCP non è un problema da evitare: è il prezzo di sistemi che funzionano davvero. Ma un sistema che funziona senza visibilità sulla sicurezza non è un sistema in produzione: è una scommessa. Il split è già avvenuto: chi presidia questi vettori ora ha un vantaggio sensibile su chi aspetta che diventi best practice consolidata.

Il sistema funziona. Tu fallo partire — con gli occhi aperti.

Se stai costruendo sistemi Claude-nativi con MCP e vuoi strutturare l'architettura in modo che regga in produzione, Claude Mastery copre la progettazione di pipeline sicure nel Modulo 6: giovanniliguori.it/claude-mastery

Per un approfondimento su come strutturare automazioni Claude sicure in produzione, ho documentato l'intero percorso nel case study delle 21 automazioni Claude. Se vuoi implementare MCP server nel tuo stack con le giuste precauzioni, la guida completa a Claude Code include una sezione dedicata alla sicurezza.

La specifica ufficiale del Model Context Protocol include le linee guida di sicurezza per implementatori di server e client.

Condividi:

Ogni settimana condivido workflow, errori e numeri reali

21 automazioni in produzione, zero dipendenti. Su LinkedIn documento il dietro le quinte: cosa funziona, cosa no, e i dati che nessuno mostra.

MCP Security 2026: 30 CVE in 60 Giorni | Giovanni Liguori