2026-07-31 · RESEARCH · Il team di Offensive Technology

Sicurezza dei server MCP remoti: cosa mostra un censimento di 19,321 server pubblicati

La metà dei server nel registro ufficiale di Model Context Protocol è remota. Abbiamo estratto l'intera popolazione pubblicata il 31 luglio 2026, 19,321 server unici, e analizzato come viene distribuito ciascuno di essi. Il 50.0% espone un endpoint remoto, un URL a cui il tuo agente IA si connette tramite la rete, in modo che il codice venga eseguito sulla macchina di qualcun altro e tu veda solo i risultati restituiti. L'altra metà, il 48.3%, è costituita da pacchetti locali che vengono eseguiti sulla tua macchina dove puoi ispezionarli. Questa singola divisione è la questione di sicurezza celata in ogni installazione di MCP: stai aggiungendo una libreria che controlli o stai collegando il tuo agente al server di uno sconosciuto? Oltre a questo, il 30.5% dei server richiede una credenziale prima di eseguirsi, e la metà remota fa capo a 7,420 host terzi distinti. Nessuno di questi numeri cita un server, un'azienda o una persona. Sono i tassi di base di un ecosistema che la maggior parte dei team sta adottando più velocemente di quanto riesca ad analizzarlo.

Che cos'è davvero un server MCP remoto

Il Model Context Protocol è l'infrastruttura di collegamento che consente a un agente IA di chiamare strumenti esterni: leggere un ticket, interrogare un database, aprire una pull request. Un server dichiara un set di strumenti, l'agente ne sceglie uno, invia gli argomenti e legge la risposta reinserendola nel proprio contesto di lavoro. Ci sono due modi in cui tale server può raggiungerti. Un server locale è un pacchetto, su npm, PyPI o un'immagine OCI, che installi ed esegui autonomamente; comunica con l'agente tramite stdio sulla tua macchina. Un server remoto è un URL. Il tuo agente apre una connessione verso di esso, invia le chiamate agli strumenti in streaming e riceve i risultati in streaming.

La differenza risiede nel perimetro di fiducia (trust boundary). Con un server locale il codice, le dipendenze e le chiamate di rete in uscita si trovano tutti su hardware che controlli e puoi ispezionare. Con un server remoto il codice risiede sull'infrastruttura dell'operatore. Non puoi vederlo, non puoi bloccarne la versione esatta tramite hash come faresti con un pacchetto, e ogni argomento inviato dal tuo agente, insieme a qualsiasi cosa l'agente abbia scelto di includere come contesto per la chiamata, passa a quell'operatore. I risultati dello strumento che ritornano vengono quindi considerati dall'agente come se fossero il suo stesso ragionamento. È proprio in quel percorso di ritorno che si annidano il tool-poisoning e l'indirect prompt injection.

Come vengono distribuiti i 19,321 server pubblicati

Ecco l'intera popolazione, suddivisa in base a come ciascun server raggiunge il tuo agente. La quota remota è il dato principale, perché è la percentuale in cui il perimetro di fiducia esce dalla tua macchina.

Vale la pena mostrare la suddivisione esatta, poiché le due metà arrotondate nascondono un dettaglio. Dei 19,321 server, 8,642 (44.7%) sono solo remoti, senza alcun pacchetto locale che potresti eseguire in alternativa. Un altro 1,014 (5.2%) offrono entrambi sia un endpoint remoto che un pacchetto locale, consentendo di scegliere. 9,323 (48.3%) sono solo pacchetti locali, e una percentuale residua 342 (1.8%) non ha dichiarato né un pacchetto né un endpoint funzionante. Quindi, quando un server è remoto, nella maggior parte dei casi lo è senza opzioni di riserva: utilizzarlo significa accettare l'endpoint di terze parti o non utilizzarlo affatto.

La richiesta di credenziali: un terzo dei server vuole le tue chiavi

Un elemento software che legge i tuoi issue su GitHub o interroga il tuo stack di osservabilità deve autenticarsi da qualche parte, quindi le richieste di credenziali sono prevedibili. Vale comunque la pena sottolineare il numero: il 30.5% dei server pubblicati, ossia 5,888 di essi, dichiara almeno una credenziale assimilabile a un segreto, una variabile d'ambiente o un header di autenticazione il cui nome contiene un token come KEY, TOKEN, SECRET, PASSWORD, o AUTH. Circa un server su tre richiede una credenziale attiva prima di svolgere qualsiasi operazione.

Se a questo si aggiunge la quota remota, il rischio diventa ancora più evidente. Quando fornisci una credenziale a un server locale, il segreto rimane nel tuo ambiente e lo strumento lo utilizza dalla tua macchina. Quando fornisci una credenziale a un server remoto, la stai trasferendo all'operatore oppure stai autorizzando l'operatore ad agire per tuo conto usandola. In entrambi i casi, l'operatore diventa un custode della tua chiave. Se l'operatore gestisce i log in modo superficiale o viene compromesso, la credenziale definita per un singolo strumento finisce nelle mani di un attaccante. Il principio del minimo privilegio non è opzionale: un server dovrebbe ricevere un token limitato esattamente a ciò di cui i suoi strumenti hanno bisogno e a nient'altro.

Dove risiedono effettivamente gli endpoint remoti

La metà remota non fa capo a una manciata di cloud affidabili. I 9,656 server con un endpoint remoto sono distribuiti su 7,420 host distinti. La coda lunga è reale: il 98.1% di questi host gestisce esattamente un solo server, il che significa moltissimi operatori indipendenti, ciascuno dei quali rappresenta una terza parte da valutare. Se i tuoi agenti adottassero il registro in blocco, aprirebbero connessioni verso migliaia di endpoint diversi, la maggior parte dei quali gestita da soggetti sconosciuti.

All'altro estremo della distribuzione c'è la concentrazione. L'host gateway più grande da solo fa da front-end per il 13.5% di tutti i server remoti, e i dieci host più attivi rappresentano insieme 18.9% degli endpoint remoti. Circa un quarto dei server remoti si poggia su un host multi-tenant condiviso anziché su un proprio dominio. Questo è l'aspetto a doppio taglio di qualsiasi marketplace: pochi aggregatori gestiscono una grossa fetta del traffico, il che è comodo ma significa anche che un singolo operatore o un singolo disservizio impatta un'ampia porzione dell'ecosistema. Non citeremo questi host; il punto è la struttura, non l'indirizzo.

L'allarme mancato: i caratteri Unicode nascosti

Un attacco MCP ampiamente dimostrato nasconde istruzioni per l'agente all'interno dei campi di testo pubblicati da un server, utilizzando caratteri invisibili: codepoint di tag Unicode, zero-width joiner, controlli bidirezionali, sequenze di escape ANSI. L'agente li legge, un revisore umano no. Abbiamo scansionato ogni campo di testo visibile al modello di tutti i 19,321 server alla ricerca di queste classi di codepoint. Il risultato è un valore nullo: 0 server su 19,321 contenevano caratteri non stampabili o riconducibili a injection nei metadati del proprio registro.

Questa è una buona notizia, ma con dei limiti bene precisi, e questi limiti contano. Il registro pubblica il nome, il titolo e la descrizione di un server, ma non le descrizioni dei singoli strumenti che esso espone, che sono invece i campi caricati nel contesto dell'agente a ogni chiamata e costituiscono il bersaglio più ricco per un attacco basato su istruzioni nascoste. Il nostro valore nullo indica che il livello dei metadati del registro stesso è pulito ad oggi. Non dimostra che lo siano anche gli strumenti dietro quei server, poiché il registro non fornisce quella superficie da analizzare in modo passivo. Quindi la conclusione onesta è circoscritta: al livello che possiamo misurare senza toccare il server di nessuno, il canale dei caratteri invisibili non viene utilizzato.

La lettura di questo registro dal punto di vista dell'attaccante

Osserva questi numeri dalla prospettiva di chi deve decidere se un controllo di sicurezza sia necessario. Un attaccante che desidera penetrare in un'organizzazione attraverso i suoi strumenti di IA ha due opzioni evidenti, e il censimento mostra che entrambe sono praticabili su larga scala. La prima è gestire un server: pubblicare qualcosa di utile, far sì che venga installato, e a quel punto ricevere legittimamente ogni richiesta inviata dall'agente e controllare ogni risultato che esso legge. Con metà del registro già remoto, un ulteriore server remoto non solleva alcun sospetto. La seconda è compromettere un operatore che gode già della fiducia di molti team, e la concentrazione nella parte alta della distribuzione degli host mostra dove risieda tale punto di leva.

Il dato sulle credenziali è il fattore moltiplicatore. A un terzo dei server è già affidato un segreto, quindi un server compromesso o sequestrato non si limita a leggere il traffico; può detenere chiavi che accedono ai sistemi alle spalle degli strumenti. Si tratta dello stesso ampliamento del perimetro che descriviamo nella nostra guida su cosa possono effettivamente vedere gli attaccanti della tua azienda, spostato un livello più all'interno: la superficie non è più soltanto il tuo DNS e i tuoi servizi pubblici, ma l'insieme dei server esterni con cui i tuoi agenti sono autorizzati a comunicare. Ciascuno di essi rappresenta una dipendenza, e le dipendenze sono il modo in cui iniziano le intrusioni moderne.

Come tenere sotto controllo i server MCP remoti

Nulla di tutto questo vuole essere un'argomentazione contro i server MCP remoti. Si tratta di gestirli per quello che sono: dipendenze di terze parti. Se utilizzi agenti collegati a strumenti MCP, ecco la lista delle azioni da intraprendere.

• Mantieni una lista di consentiti (allow-list), non un registro aperto. Decidi quali server specifici i tuoi agenti possono utilizzare e bloccali (pinning). Il fatto che metà del registro sia remota significa che per metà ti stai affidando a un operatore che scegli di considerare affidabile, quindi decidi in modo consapevole anziché installare al momento della scoperta.
• Prediligi l'opzione locale quando sono disponibili entrambe. Per il 5.2% dei server che forniscono sia un pacchetto che un endpoint, il pacchetto locale mantiene il codice e il relativo traffico sulla tua macchina. Sceglilo quando lo strumento non ha un reale bisogno di essere remoto.
• Limita il raggio d'azione (scope) di ogni credenziale allo specifico strumento. Poiché il 30.5% dei server richiede un segreto, emetti un token limitato esattamente a ciò di cui i tool del server hanno bisogno, ruotalo e non fornire mai una chiave con permessi ampi a un server che non hai sottoposto ad audit.
• Tratta l'output dello strumento come input non attendibile. I risultati restituiti da un server possono contenere istruzioni dirette al tuo agente. Limita ciò che l'agente è autorizzato a fare con essi ed evita che il risultato di uno strumento attivi silenziosamente azioni privilegiate.
• Sappi chi c'è dall'altra parte. Un endpoint remoto fa capo all'host di qualcuno. Per i server da cui dipendi, impara a conoscere l'operatore e ricorda che la maggior parte degli host in questo registro gestisce un singolo server gestito da un singolo soggetto.

Metodologia, affinché anche gli scettici possano fidarsi dei numeri

Il set di dati è nostro, estratto da una fonte pubblica e gestito solo in forma aggregata. Abbiamo interrogato l'API pubblica del registro ufficiale di Model Context Protocol e analizzato l'intero catalogo il 31 luglio 2026, memorizzando 62,430 record di versione. Abbiamo ridotto tali dati ai 19,321 server contrassegnati come versione corrente e più recente, che costituiscono la popolazione attiva deduplicata e il denominatore per ogni percentuale citata. La modalità di distribuzione è stata classificata in base ai pacchetti e agli endpoint remoti dichiarati da ciascun server; il dato sulle credenziali conteggia qualsiasi variabile d'ambiente o header di autenticazione dichiarati il cui nome contenga un token assimilabile a un segreto; la concentrazione degli host è stata calcolata risolvendo l'hostname di ciascun endpoint remoto; e la scansione dei caratteri nascosti ha verificato ogni campo di testo rispetto al blocco tag Unicode, ai caratteri di formattazione zero-width e bidirezionali, alle sequenze di escape ANSI e ad altri codepoint di controllo e uso privato.

Abbiamo letto esclusivamente l'API pubblica del registro stesso. Non ci siamo connessi a nessuno dei server elencati, non abbiamo inviato alcuna richiesta all'endpoint di alcun operatore e non abbiamo raccolto alcuna informazione su singoli individui. Leggere un catalogo pubblico è un'azione passiva; interagire con gli host al suo interno non lo sarebbe stato, e non lo abbiamo fatto.

Cosa questo non dimostra

Un numero privo di contestualizzazione è solo marketing, quindi ecco i limiti di questa analisi.

• Si tratta di un solo registro. Il registro ufficiale è il catalogo centrale, ma esistono server che non vi vengono mai pubblicati, e altre directory ne elencano di propri. Questa analisi misura la popolazione pubblicata e individuabile, non l'insieme di tutti i server esistenti.
• Dati dichiarati, non osservati. La modalità di distribuzione e le credenziali derivano da ciò che ciascun server dichiara nella propria scheda del registro. Un server potrebbe richiedere un segreto che non ha elencato, o distribuire un pacchetto che in realtà non supporta. Abbiamo misurato il manifesto, non un'installazione dal vivo.
• Essere remoti rappresenta una superficie di rischio, non un giudizio di colpevolezza. Un server remoto non è poco sicuro per il solo fatto di essere remoto. Molti sono gestiti in modo ottimale da operatori seri. Il 50.0% rappresenta la portata della decisione in termini di fiducia, non un conteggio di attori malevoli.
• Il valore nullo è circoscritto. L'assenza di riscontri sui caratteri nascosti riguarda esclusivamente i campi a livello di server del registro. Le descrizioni dei singoli strumenti che vengono caricate in un agente a ogni chiamata non sono pubblicate per una lettura passiva, quindi questo non è un certificato di idoneità per gli strumenti stessi.
• Si tratta di una fotografia istantanea. Il registro cresce ogni giorno. Cifre come queste descrivono la situazione al 31 luglio 2026, non una tendenza, e un'estrazione effettuata il mese prossimo produrrà valori diversi.

Domande frequenti

I server MCP remoti sono sicuri da usare?

Un server MCP remoto è sicuro solo quanto l'operatore che lo gestisce, poiché il tuo agente invia le richieste ed estrae i risultati dall'endpoint di tale operatore. In questo censimento il 50.0% dei server era remoto e tutti utilizzavano HTTPS, quindi il problema non è la cifratura del trasporto. È la fiducia. Blocca i server che hai verificato e fornisci a ciascuno credenziali basate sul minimo privilegio.

Qual è la differenza tra un server MCP locale e uno remoto?

Un server locale viene eseguito come pacchetto sulla tua macchina, per cui il relativo codice e le chiamate di rete sono a tua disposizione per essere ispezionati. Un server remoto è un URL a cui il tuo agente si connette, quindi il codice viene eseguito sull'infrastruttura di qualcun altro e tu vedi soltanto le risposte. Nel censimento il 48.3% era solo locale, il 44.7% solo remoto e il 5.2% offriva entrambe le soluzioni.

Quanti server MCP esistono?

Il registro ufficiale elencava 19,321 server pubblicati unici quando abbiamo estratto l'intera popolazione il 31 luglio 2026, considerando solo l'ultima versione di ciascuno. L'ecosistema sta crescendo rapidamente, pertanto considera questo dato come una fotografia datata.

I server MCP richiedono chiavi API o credenziali?

Molti sì. Nel censimento il 30.5% dei server ha dichiarato almeno una credenziale assimilabile a un segreto, quindi circa uno su tre richiede una chiave o un token prima di eseguire qualsiasi operazione. Ciò amplia il raggio d'azione di un eventuale danno (blast radius) se il server o il suo operatore vengono compromessi.

Un server MCP può rubare i tuoi dati?

Un server malevolo o compromesso può leggere ogni richiesta inviatagli dal tuo agente e restituire risultati manipolati ad arte nel contesto dell'agente stesso: è così che funzionano il tool-poisoning e il prompt-injection. Non può accedere oltre i tool e le credenziali che gli concedi, pertanto la difesa consiste nel principio del minimo privilegio e in una lista di consentiti (allow-list) sottoposta ad audit.

Il registro MCP viene sottoposto a controlli?

No. L'inserimento nell'elenco è una semplice pubblicazione, non un audit di sicurezza. Il registro prende nota di dove risiede un server, non se il suo operatore sia affidabile. I server remoti sono risultati appartenere a 7,420 host, il 98.1% dei quali ospitava un singolo server, quindi la maggior parte della supply chain è composta da operatori che dovresti verificare uno per uno.

Quali sono i rischi di sicurezza dei server MCP?

I principali rischi sono l'invio da parte di un server di output di strumenti manipolati verso il tuo agente, un operatore remoto che vede e registra ogni richiesta, l'esposizione di credenziali quando un server richiede delle chiavi, e il rischio di concentrazione quando molti server si trovano dietro un unico gateway. In questo censimento, le tecniche esotiche come l'Unicode nascosto erano assenti dai metadati del registro, 0 su 19,321, per cui il rischio a breve termine riguarda la fiducia e l'accesso, non la codifica.

Letture correlate

• Cosa possono effettivamente vedere gli attaccanti della tua azienda? La superficie che questo articolo estende verso l'interno, arrivando agli strumenti dei tuoi agenti.
• p=none è sufficiente? Lo stesso metodo di misurazione passiva, applicato all'autenticazione e-mail.
• Prima l'autorizzazione. Perché ogni misurazione che pubblichiamo rimane entro i limiti della legalità.