Nel settembre 2026 ho scritto un template di rilevamento per la vulnerabilità CVE‑2026‑61560, una falla critica in un popolare server Model Context Protocol (MCP) costruito dalla community per GitLab. Il difetto in sé era semplice, ma ciò che è rimasto impresso è l’intero contesto: come il server è stato distribuito, cosa custodiva e quanto tempo la catena di sicurezza ha impiegato per accorgersene.

Che cos’è un server MCP e perché è pericoloso

I server MCP fungono da connettori che permettono agli assistenti AI di interagire con altri sistemi. Il pacchetto open‑source @zereight/mcp‑gitlab espone più di 100 strumenti capaci di leggere e modificare progetti su GitLab. Per farlo, mantiene un token di accesso personale di GitLab; qualsiasi azione che il token consente, il server può compierla.

Configurazione vulnerabile nella versione pre‑2.1.27

Prima della versione 2.1.27, l’esecuzione del server in modalità rete (SSE) lasciava le endpoint /sse e /messages aperte a chiunque potesse raggiungere la porta. Non c’era password né token di autenticazione. Il file docker‑compose.yml pubblicava la porta su tutte le interfacce di rete e il container girava come utente root. Uno degli strumenti, upload_markdown, leggeva qualsiasi percorso di file fornito; puntandolo verso /proc/self/environ restituiva l’ambiente del server, contenente il token di GitLab in chiaro. Da quel punto, un attaccante poteva accedere a tutti i repository, variabili CI/CD e chiavi di deploy associate al token. La vulnerabilità ha ricevuto un punteggio CVSS di 9,8.

Facilità di sfruttamento e mancanza di visibilità

Non era necessario un attaccante sofisticato: bastava lanciare docker compose up e dimenticarsene. Nessun processo di revisione o di inventory ha rilevato il nuovo asset, perché il server è stato introdotto “da una porta laterale” da uno sviluppatore desideroso di rendere più utile un assistente AI. Il componente è stato trattato come uno strumento di sviluppo, non come infrastruttura, e non è stato registrato in alcun asset inventory.

Problemi di timing nella correzione

Il manutentore ha rilasciato una correzione solida il 22 giugno 2026, in risposta a una segnalazione dei ricercatori @gil‑maman‑p e @hodaya‑prz. La versione 2.1.27 introduce:

    • Rifiuto di ascoltare su interfacce non‑localhost senza token di autenticazione
    • File docker‑compose.yml che espone la porta solo su localhost
    • Esecuzione del container come utente non privilegiato
    • Blocco del percorso di lettura file potenzialmente pericoloso

Tuttavia, il record CVE è stato pubblicato solo il 15 settembre 2026, lasciando circa 12 settimane in cui gli scanner di dipendenze, le piattaforme di gestione delle vulnerabilità e i contenuti di rilevamento non avevano nulla da confrontare. Qualsiasi processo che attende un CVE prima di intervenire è rimasto indietro.

Altri incidenti legati a MCP

Non si tratta di un caso isolato. Gli SDK ufficiali di MCP hanno richiesto correzioni di trasporto nello stesso anno:

    • Go SDK accettava richieste cross‑site senza verificare l’origine (CVE‑2026‑33252)
    • Ruby SDK privo di protezione contro DNS‑rebind (CVE‑2026‑63118)

La specifica MCP, aggiornata a luglio 2026, afferma ancora che l’autorizzazione è opzionale. Le impostazioni predefinite hanno privilegiato la rapidità di avvio rispetto alla sicurezza. Anche la versione corretta gitlab‑mcp conserva una “scappatoia” tramite la variabile d’ambiente SSEDANGEROUSLYALLOWUNAUTHENTICATEDREMOTE, che qualcuno potrebbe attivare per far funzionare una demo.

Raccomandazioni operative per le organizzazioni

Le squadre di sicurezza devono adottare tre azioni concrete:

    • Scoprire tutti i server MCP: ogni server deve avere un proprietario, un elenco dei token custoditi e una registrazione delle interfacce su cui ascolta. Se non si può rispondere “quali server MCP possono raggiungere il nostro GitLab?”, esiste un gap.
    • Limitare la portata dei token: un assistente che riassume merge request non ha bisogno di un token con permessi di lettura delle variabili CI/CD. Utilizzare il token più ristretto possibile, impostare una data di scadenza e ruotarlo quando il server cambia gestore.
    • Monitorare i rilasci, non solo le CVE: sottoscrivere gli avvisi di sicurezza e le note di rilascio dei repository MCP. Un anticipo di 12 settimane è prezioso, anche a costo di un po’ più di rumore.

Implementazione di rilevamenti pratici

Dal punto di vista della detection, la verifica è semplice: un trasporto MCP che risponde su un’interfaccia non‑loopback senza richiedere credenziali è un’indicazione di vulnerabilità, indipendentemente dalla versione. Il mio template controlla esattamente questo comportamento; lo stesso controllo può essere integrato negli scanner interni per tutti i server MCP in uso.

Conclusioni: l’evoluzione dei connettori AI

Gli assistenti AI continueranno a guadagnare nuovi connettori. Ognuno di essi è un piccolo pezzo di infrastruttura che detiene le chiavi di qualcuno. Le organizzazioni che cominciano a trattarli come componenti critici, con inventario, gestione dei segreti e monitoraggio continuo, avranno molte meno sorprese in futuro.