Una panoramica della vulnerabilità MCP

Il Model Context Protocol (MCP) è alla base di molte soluzioni di automazione domestica basate su intelligenza artificiale. Tuttavia, il rapporto “Welcome to the Jungle” di OX Security, pubblicato su The Hacker News, ha evidenziato che circa 0,45 % dei 15.465 server MCP indicizzati pubblicamente operano su macchine personali, spesso esposte tramite servizi di tunneling come ngrok.

Questa percentuale, seppur numericamente piccola, rappresenta una porta d’accesso aperta per chiunque scandagli Internet alla ricerca di hardware vulnerabile.

Scelta architetturale “by design”

Il vero problema non è un semplice bug, ma una scelta architetturale fondamentale. Gli SDK ufficiali di Anthropic per Python, TypeScript, Java e Rust usano un metodo di trasporto chiamato STDIO, che accetta un parametro “command” ed esegue il comando così com’è, senza alcuna sanitizzazione.

Quando OX Security ha segnalato che questa implementazione crea una vulnerabilità sistemica di command injection, Anthropic ha confermato che il comportamento è by design e ha rifiutato di modificare il protocollo, lasciando la responsabilità della sanitizzazione interamente agli sviluppatori.

Stime e impatti reali

Secondo la advisory di OX Security sulla catena di approvvigionamento, si contano circa 200 000 istanze di server MCP vulnerabili a livello globale, di cui più di 7 000 sono pubblicamente accessibili e oltre 150 milioni di download degli SDK.

Le vulnerabilità sono state già sfruttate in attacchi concreti:

    • CVE-2025-6514: vulnerabilità critica di esecuzione remota di codice (RCE) con CVSS 9.6, presente nel pacchetto npm mcp-remote, proxy OAuth usato da molti client MCP. Scoperta da JFrog nel luglio 2025, ha ottenuto un EPSS del 77 %.
    • CVE-2026-30624: vulnerabilità RCE ad alta gravità in Agent Zero, che permette di definire server MCP con comandi arbitrari eseguiti senza validazione.

Il “AI worm” e il rischio di auto‑replicazione

Questa architettura favorisce lo scenario dell’“AI worm” descritto dal Frontier Red Team di Anthropic. Ricercatori hanno dimostrato che piccoli modelli AI possono auto‑replicarsi su dispositivi IoT consumer senza privilegi di root, poiché i motori di inferenza operano nello spazio utente.

Unendo la vulnerabilità di iniezione “by design” a un agente auto‑replicante, si crea una catena di fornitura che può trasformare la propria smart home in un nodo di una rete indesiderata più ampia.

Cosa devono sapere gli utenti domestici

Non tutte le implementazioni MCP sono ugualmente pericolose. Google Home MCP, lanciato in early access a settembre, utilizza il trasporto SSE (Server‑Sent Events) con OAuth, una architettura significativamente più sicura rispetto a STDIO.

Home Assistant, invece, integra MCP con OAuth 2.0 e PKCE, offrendo un ulteriore livello di protezione. È consigliabile essere cauti con progetti comunitari come ha‑mcp, che possono fornire accesso diretto in scrittura alle configurazioni e alle automazioni domestiche.

Misure pratiche per mitigare il rischio

    • Trattare il server MCP domestico come qualsiasi altro servizio esposto: assumere che sia soggetto a scansioni.
    • Limitare al massimo l’esposizione su Internet; chiudere il tunnel se non è strettamente necessario.
    • Preferire SDK e integrazioni che usano trasporti sicuri (SSE, OAuth) anziché STDIO.
    • Aggiornare regolarmente i componenti e monitorare le vulnerabilità note (CVE‑2025‑6514, CVE‑2026‑30624).
    • Implementare sanitizzazione dei comandi a livello di applicazione, anche se l'SDK non lo richiede.

Le imprese investono ingenti risorse per proteggere le proprie implementazioni AI, ma per l’utente domestico la responsabilità ricade spesso su di sé. Se gestisci un server MCP a casa, consideralo vulnerabile fin da subito e prendi tutte le precauzioni necessarie per ridurre al minimo la tua superficie di attacco.