Esposti by design: un audit dal vivo di 414 server MCP esposti su Internet ha individuato 68 vulnerabilità

Il 31 luglio 2026 Nicolás Padilla ha pubblicato Exposed by Design (arXiv:2608.00150), un preprint di 13 pagine che descrive quella che definisce la prima valutazione dinamica di sicurezza comportamentale dei server Model Context Protocol esposti a Internet. Quattro campagne di misurazione in quel mese hanno confermato 640 server di produzione attivi, dei quali 414 sono stati testati attivamente; i test hanno prodotto 68 vulnerabilità segnalabili, tutte registrate presso i manutentori come GitHub Security Advisories. 380 dei 414 — 91,8% — non avevano autenticazione OAuth, e 687 istanze di strumenti dichiaravano esecuzione di shell senza controlli di accesso. Padilla non riporta alcuna prova che qualcosa sia stato sfruttato: i test sono rimasti a livello di proof of concept, non sono state ottenute credenziali e nessun dato è stato esfiltrato. L'elenco completo delle fonti della scheda, il livello di gravità e la valutazione della confidenza si trovano in l'archivio degli incidenti AI, insieme alle altre segnalazioni relative a MCP e all'infrastruttura archiviate intorno a essa.

Che cosa ha effettivamente fatto l'audit

Il Model Context Protocol è l'interfaccia che consente a un agente AI di chiamare strumenti ospitati altrove — una ricerca di documenti, un'interrogazione di database, un helper di shell. Un server che lo parla via HTTP ed è raggiungibile da internet è, di fatto, una superficie di strumenti che chiunque può indirizzare. Il paper di Padilla sostiene che la popolazione di tali server non è mai stata contata in modo adeguato, e che contarli è il punto: la scoperta è la parte difficile, e ogni indagine precedente ha guardato una fetta diversa.

La sua fase di scoperta ha unito undici fonti — crt.sh, Hugging Face, GitHub, npm, Smithery, PyPI, Censys, FOFA, Shodan, glama.ai e pulsemcp.com — sulla base del fatto che nessuna di esse, da sola, cattura la popolazione. La fase attiva ha utilizzato Corvus, un framework che Padilla ha sviluppato per lo studio: 34 moduli di test che coprono 10 classi di vulnerabilità specifiche per MCP, suddivisi in 13 statici e 21 dinamici. È pubblicato su GitHub sotto l'organizzazione CobaltoSec e su PyPI come cobaltosec-corvus, e il file di statistiche del repository stesso registra lo stesso conteggio di 34 moduli.

Le quattro esecuzioni hanno avuto luogo il 15, 18, 21 e 24 luglio 2026. Le esecuzioni precedenti hanno fornito solo numeri di conferma; le ultime tre hanno scansionato 3.485, 3.948 e 4.110 candidati e confermato rispettivamente 140, 464 e 296 server attivi. Deduplicando 972 osservazioni grezze con 332 presenze ripetute sono rimasti 640 server univoci confermati, dei quali 414 — 64,7% — hanno accettato il test dinamico completo. Padilla considera 640 un limite inferiore. Censys, una delle fonti di scoperta, aveva stimato più di 21.000 endpoint correlati a MCP in tutto il mondo a maggio 2026, e lui usa tale valore come stima su scala anziché come conteggio di ciò che ha testato.

Letto come un imbuto, i numeri sono la vera tesi dell’articolo: una passata ampia ed economica trova candidati più in fretta di quanto una passata accurata possa testarli. Solo 414 dei 640 server confermati sono stati pienamente messi alla prova, e Padilla non afferma che il sottoinsieme testato somigli al resto non testato.

Quello che ha trovato

Il risultato principale riguarda l'autenticazione, o la sua assenza. Dei 414 server testati, 380 (91,8%) non avevano OAuth. Lo studio afferma che la maggior parte dei restanti usava token bearer statici o chiavi API, spesso prevedibili o vuote — anche un server che accetta una stringa fissa non è autenticato in modo significativo. Poiché l'audit ha testato solo server pubblicamente raggiungibili senza credenziali, questo dato descrive per costruzione la popolazione esposta; non è una stima per i server MCP in generale.

I 68 riscontri segnalabili si suddividono per classe, e i conteggi per classe si sovrappongono anziché partizionare il totale: 380 carenze di autenticazione, 52 casi di accettazione del fuzzing di protocollo, 47 di avvelenamento degli strumenti, 38 di iniezione di comandi, 31 di bypass dello schema, 29 di server-side request forgery, 24 di manipolazione degli URI delle risorse, 22 di prompt injection, 18 di esposizione di token e 14 di indicatori di supply chain. I moduli di denial-of-service sono stati scritti ma deliberatamente non eseguiti contro server di produzione, che Padilla esclude per motivi etici. I quattro tipi di vulnerabilità citati nell'abstract — SQL injection, SSRF contro servizi di metadati cloud, prompt template injection e path traversal tramite manipolazione del cursore — compaiono ciascuno all'interno di tali classi.

La cifra relativa all'esecuzione shell necessita di un'avvertenza che l'articolo non risolve. Nella sua sezione risultati, 687 istanze di strumenti con esecuzione shell e senza autenticazione vengono conteggiate nel pool confermato di 640 server. Nella discussione, la stessa cifra viene introdotta con le parole "dei 414 server sottoposti a audit dinamico" e poi riferita al "più ampio insieme confermato". Le due formulazioni non concordano, e l'articolo non fornisce mai un conteggio totale degli strumenti per i server testati, quindi 687 non può essere convertito in una percentuale.

Il churn è il rilevamento che più di ogni altro cambia il modo in cui dovrebbero essere letti i numeri. Dei 464 server confermati il 21 luglio, 193 — il 41,6% — erano scomparsi quando la quarta esecuzione ha verificato tre giorni dopo. Nove dei 41 server che presentavano un rilevamento CRITICO erano anch'essi scomparsi. Padilla lo interpreta come distribuzione senza revisione; significa anche che un rilevamento confermato lunedì potrebbe non avere alcun proprietario che lo corregga entro giovedì.

I tre casi di studio e ciò che può essere verificato

Tre risultati sono descritti in dettaglio, ciascuno con un identificatore di GitHub Security Advisory. Un'iniezione SQL in lectorium-corpus-mcp (GHSA-m8qh-p8m5-8c48, classificata CRITICA) è stata confermata con il payload ' OR 1=1 -- e una differenza nella dimensione della risposta, senza che alcun contenuto del documento sia stato letto o conservato. Un SSRF in epwforge (GHSA-r9fx-qwmc-rvx3, ALTA) è stato confermato tramite temporizzazione: 11,9 secondi verso un indirizzo interno di metadati rispetto a un valore di riferimento di 0,3 secondi, senza che alcun contenuto della risposta dei metadati sia stato memorizzato. Un'iniezione di template di prompt in frootai (GHSA-5h8f-r9g8-5w5p, ALTA) completa l'elenco.

Due dei tre possono essere verificati direttamente. Il 30 ottobre 2026 le prime due pagine di advisory erano pubblicamente accessibili nel repository di advisory di CobaltoSec, entrambe pubblicate il 20 agosto 2026, ed entrambe riportavano ancora "Versioni corrette: Nessuna" e nessuna CVE. La terza, GHSA-5h8f-r9g8-5w5p, ha restituito "non trovato" a quell'indirizzo. Il repository di CobaltoSec elencava 46 advisory pubblicati alla stessa data, riguardanti server MCP e strumenti AI correlati; il documento ne contava 19 come divulgati pubblicamente e 49 ancora sotto embargo al momento della stesura. Un artefatto di scansione per frootai datato 28 luglio 2026 si trova nel repository Corvus, quindi il test è avvenuto; solo l'advisory non è visibile.

Il processo di divulgazione è descritto solo a grandi linee, non nel dettaglio. Tutti i 68 risultati sono stati inviati ai manutentori tramite GitHub Security Advisories privati, nell’ambito di un embargo coordinato di 90 giorni; dove la segnalazione privata non era disponibile, Padilla ha invece aperto una issue pubblica nel repository. L’articolo riporta in modo aneddotico che alcuni manutentori hanno applicato la patch entro 24 ore, altri non hanno risposto per settimane e alcuni repository sono stati abbandonati. Non fornisce un conteggio dei manutentori contattati né una tabella dei tassi di risposta, affermando che saranno riportati integralmente al momento della presentazione.

Ciò che il documento non stabilisce

Exposed by Design è una prestampa di un solo autore. arXiv riporta la versione 1, inviata il 31 luglio 2026, senza riferimento a rivista né dichiarazione di peer review. L'archivio assegna al record il livello di confidenza B — documentato, ma da un'unica fonte — e tale livello vale per l'intero pezzo: ogni dato riportato sopra proviene dall'articolo di Padilla o dagli artefatti che pubblica, non da una misurazione indipendente.

Nessuna redazione giornalistica indipendente sembra aver riportato lo studio. Esiste una copertura — un’analisi scritta dall’IA su forkast.news, post su LinkedIn e Medium, un blog sulla sicurezza in lingua cinese, un articolo divulgativo in giapponese — ma parafrasa il preprint senza intervistare l’autore, verificare gli avvisi o aggiungere dati. La copertura derivata non è una conferma.

Padilla stesso dichiara i limiti, e sono insolitamente specifici. Sono stati testati solo i trasporti HTTP; i server stdio, il caso locale comune, sono fuori ambito. La scoperta è best-effort, quindi 640 è un limite inferiore. I 226 server confermati che non sono stati testati completamente sono stati esclusi per risposte 403, reset delle connessioni, risposte JSON-RPC non conformi o semplicemente perché offline, e l'articolo afferma che il conseguente bias di selezione non può essere delimitato. Il rilevamento si basa su euristiche — oracoli temporali, risposte differenziali, ispezione degli schemi — senza un benchmark etichettato e senza precisione o richiamo pubblicati per i 34 moduli. Il ricambio che documenta mina la validità temporale dei singoli risultati. E un singolo ricercatore che svolge la verifica manuale introduce un rischio di bias di conferma che egli nomina e non quantifica.

Cosa è cambiato dopo

Il risultato pratico finora è lo strumento e il flusso di advisory. Corvus è installabile e documentato, e il repository di advisory di CobaltoSec conteneva 46 voci pubblicate il 30 ottobre 2026, rispetto alle 19 divulgazioni pubbliche che il paper contava alla fine di luglio. Due dei casi di studio dello stesso paper non hanno ancora una versione corretta — per quei server, la divulgazione ha prodotto una registrazione pubblica ma non, ancora, una correzione.

Per i difensori, la parte utile dello studio è il metodo più che il titolo. Una cifra del 91,8% ricavata solo dai server che rispondevano senza credenziali dice qualcosa di limitato e reale: gran parte di ciò che è esposto non è mai stata protetta, e il ricambio nell'arco di tre giorni suggerisce che molto è stato messo in piedi per una demo, un prototipo o un test e mai irrobustito. Ciò che lo studio non può dire è se lo stesso valga per i server MCP su cui le organizzazioni fanno effettivamente affidamento, perché quelli non sono mai stati nel campione.