L'SSRF di Azure MCP Server potrebbe divulgare il suo token di identità gestita a un URL

Microsoft ha pubblicato CVE-2026-26118 il 10 marzo 2026: una vulnerabilità di server-side request forgery in Azure MCP Server Tools, il pacchetto che consente agli agenti AI e ai client MCP di agire sulle risorse Azure in linguaggio naturale. Un attaccante in grado di interagire con un agente basato su MCP potrebbe inviare un URL malevolo al posto di un normale identificatore di risorsa Azure; il server invierebbe quindi una richiesta in uscita a tale indirizzo e, secondo Microsoft, «potrebbe includere il proprio token di identità gestita» — consegnando al chiamante una credenziale che non avrebbe mai dovuto vedere. Microsoft ha assegnato alla vulnerabilità CVSS 8.8 e l'ha classificata come Importante, e i pacchetti che contengono la correzione sono 1.0.2 e 2.0.0-beta.17. L'avviso non registra alcuno sfruttamento né alcuna divulgazione pubblica prima della patch, e non è stato registrato alcun danno reale. Questo incidente è una voce in l'Orca AI Incident Archive, che contiene la documentazione completa con le fonti citate, il livello di gravità e la valutazione della confidenza.

Cosa dice effettivamente l'avviso

Il record del Microsoft Security Response Center è conciso, e quasi tutti i dettagli pubblicati su questa vulnerabilità derivano da esso o dalle risposte di Microsoft a una manciata di domande di follow-up. La descrizione completa: “Server-side request forgery (SSRF) in Azure MCP Server consente a un attaccante autorizzato di elevare i privilegi attraverso la rete.” Il record CVE ha riservato l'identificatore l'11 febbraio 2026 e lo ha reso pubblico il 10 marzo alle 14:00 UTC; la nota di rilascio di Microsoft e la voce NVD riportano entrambe quel giorno. NVD ha analizzato il record e lo ha pubblicato alle 18:18 UTC lo stesso pomeriggio. L'unico avviso di un regolatore trovato per questo articolo proviene dal Marocco: l'unità maCERT della DGSSI ha riportato CVE-2026-26118 in un bollettino datato 11 marzo 2026, elencando Azure MCP Server Tools tra i prodotti interessati al proprio livello di rischio Important, senza un punteggio separato e con un rimando alla nota di rilascio di Microsoft.

La debolezza è mappata a CWE-918, falsificazione di richiesta lato server, e la classificazione dell'impatto è escalation di privilegi. Il punteggio base di Microsoft è 8.8 sul vettore CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, con un punteggio temporale di 7.7 su E:U/RL:O/RC:C — la componente E:U significa che nessun codice di exploit era noto a Microsoft quando il punteggio è stato assegnato, e RL:O significa che era disponibile una correzione ufficiale. NVD riporta lo stesso punteggio base e lo classifica come High; la scala a tre livelli di Microsoft lo definisce Important.

Due campi contano quanto il punteggio. Il record di Microsoft indica Sfruttato: No e Divulgato pubblicamente: No. Il record decisionale SSVC di CISA sulla voce NVD, con timestamp 5 marzo 2026, concorda sullo sfruttamento — nessuno — mentre valuta l'impatto tecnico totale e automatizzabile no. Il modello FIRST EPSS ha stimato la probabilità di sfruttamento nei prossimi 30 giorni a circa l'1,0%, al 62,8° percentile, in un'estrazione datata 3 novembre 2026. Si tratta di una vulnerabilità che è stata trovata e corretta, non di una che è nota per essere stata sfruttata.

Come un identificatore di risorsa diventa una richiesta in uscita

Azure MCP Server è l'implementazione Microsoft del Model Context Protocol, l'interfaccia utilizzata dagli agenti AI per chiamare gli strumenti. I suoi strumenti prendono i parametri forniti da un agente — il nome di un account di archiviazione, un identificatore di sottoscrizione, il nome di un database — e li trasformano in chiamate ai piani di gestione e dati di Azure. La documentazione Microsoft descrive il server come autenticato tramite Entra ID usando “le credenziali utente di Azure o l'identità gestita”, con accesso limitato dal controllo degli accessi basato sui ruoli di Azure.

Il difetto risiede nel punto in cui un parametro che dovrebbe indicare una risorsa Azure viene invece accettato come URL. La spiegazione fornita da Microsoft stessa: un attaccante “potrebbe sfruttare questo problema inviando input appositamente predisposti a uno strumento di Azure Model Context Protocol (MCP) Server che accetta parametri forniti dall’utente. Se l’attaccante può interagire con l’agente basato su MCP, può inviare un URL malevolo al posto di un normale identificatore di risorsa Azure”. Il server invia quindi la richiesta dove gli è stato indicato, anziché dove lo strumento intendeva.

La parte che trasforma una seccatura in un'escalation di privilegi è ciò che viaggia al seguito. Microsoft afferma che la richiesta in uscita "può includere il token della sua identità gestita", il che consente all'attaccante di catturare quel token "senza richiedere accesso amministrativo". Un token di identità gestita è una credenziale bearer: chiunque lo possieda può presentarlo ai servizi Azure per cui quell'identità è autorizzata, finché non scade. L'altra metà mitigante dello stesso paragrafo è altrettanto importante: l'attaccante ottiene "le autorizzazioni associate all'identità gestita del server MCP" e, secondo Microsoft, "non ottiene autorizzazioni più ampie a livello di tenant o di amministratore; solo quelle legate all'identità gestita compromessa". Il raggio d'azione è qualunque cosa qualcuno abbia concesso a quell'identità, che in pratica è spesso più di quanto servisse a un singolo strumento.

Microsoft non nomina lo strumento o il parametro interessato, e nessuna fonte consultata per questo articolo lo fa. Tale omissione è di per sé un dettaglio: l'avviso descrive una classe di strumenti — uno che accetta parametri forniti dall'utente e può essere indotto a recuperare un URL — anziché un singolo endpoint.

La correzione, e i pacchetti che la contenevano

Non si trattava di un aggiornamento di Windows. Azure MCP Server Tools viene distribuito come pacchetto NuGet per .NET, come pacchetto npm e come pacchetto Python su PyPI, e la correzione consiste nell'incremento di versione di quello utilizzato da una distribuzione. L'avviso di Microsoft elenca gli intervalli interessati come dalla 1.0.0 fino alla 1.0.2 esclusa, e dalla 2.0.0-beta.1 fino alla 2.0.0-beta.17 esclusa, in tutte le distribuzioni NuGet, npm e PyPI.

Le date del registro npm mostrano che le build corrette erano già presenti nel registro prima dell'advisory. La versione 1.0.2 di @azure/mcp è stata pubblicata il 6 marzo 2026, quattro giorni prima che la CVE diventasse pubblica; la 2.0.0-beta.17 è stata pubblicata il 6 febbraio 2026, cinque giorni prima che Microsoft riservasse l'identificatore CVE e un mese prima che comparisse l'advisory. Qualunque sia stata la sequenza all'interno di Microsoft, il codice corretto non è stato scritto in risposta al giorno di pubblicazione. NVD e il database degli advisory di GitHub concordano su questi limiti superiori. Differiscono leggermente all'estremità inferiore dell'intervallo PyPI — NVD indica 2.0.0-beta.1, l'advisory di GitHub indica 2.0.0b14 — una discrepanza che i due record riportano fin dalla pubblicazione e che influisce solo su quanto indietro deve guardare una distribuzione Python.

L’avviso stesso è stato revisionato il 20 marzo 2026, dieci giorni dopo la pubblicazione, con una nota in cui Microsoft aveva “aggiunto prodotti alla tabella degli aggiornamenti di sicurezza che documentano i vari metodi di pacchettizzazione utilizzati per distribuire Azure MCP Server Tools”. In altre parole, la prima versione dell’avviso indicava il prodotto ma non tutti i canali attraverso cui veniva distribuito, il che è importante quando il rimedio consiste nell’“aggiornare il pacchetto” anziché nell’“installare questo KB”.

Che cosa non è stabilito

Chi lo ha trovato. Né l'avviso di Microsoft né il record di CVE.org indicano un segnalatore; il campo credits del CVE è vuoto. Ciò non dimostra che nessuno sia stato accreditato privatamente, ma solo che non esiste alcun riconoscimento pubblico.

Qualsiasi sfruttamento. Microsoft non ne registra alcuno, la valutazione SSVC della CISA concorda e nessuna fonte consultata per questo articolo descrive un'identità compromessa in ambiente reale. Il campo relativo al danno reale del record è falso, coerentemente con ciò. Un EPSS basso è una previsione, non un riscontro, e l'assenza di un incidente segnalato non è prova che non se ne sia verificato alcuno.

Se esiste un exploit pubblico. È qui che la copertura secondaria si divide. Un post del marzo 2026 sul blog di Blueinfy afferma che esistono “exploit proof-of-concept pubblici, come quelli su GitHub” e avverte di una “rapida weaponizzazione”, ma non fornisce link, payload o procedura dettagliata, e non dimostra la vulnerabilità. Il registro di Microsoft indica che la vulnerabilità non è stata divulgata pubblicamente prima della patch. Una ricerca su GitHub per l'identificativo CVE il 4 novembre 2026 ha restituito un solo repository — un laboratorio di rilevamento Microsoft Sentinel pubblicato il 17 marzo 2026, non un exploit — e la pagina delle vulnerabilità di Mallory afferma che due potenziali exploit sono stati valutati e scartati. L'affermazione secondo cui esisterebbe codice di exploit pubblico funzionante è, sulla base delle prove disponibili, non suffragata; l'affermazione secondo cui nessuno ci abbia provato è ugualmente non dimostrata.

La cornice. Una pagina su PolicyLayer, sito di sintesi di incidenti di un fornitore, rilegge CVE-2026-26118 come una catena di esecuzione di codice remoto non autenticata che culmina nella compromissione totale del tenant, attribuendola a un ricercatore citato per nome e a una dimostrazione all'RSAC 2026. Le fonti stesse citate da quella pagina hanno titoli che parlano di SSRF, le sue date non concordano con la cronologia della CVE, e né l'advisory di Microsoft né il servizio di SecurityWeek del 10 marzo descrivono esecuzione di codice. Questo articolo considera la versione SSRF-e-token come quella accertata e non ripropone l'impostazione RCE.

Perché è il token, e non la richiesta, a costituire il risultato

La falsificazione delle richieste lato server (Server-side request forgery) è una delle classi di bug più antiche nel software web e, di per sé, è di solito un modo per raggiungere sistemi a cui l'attaccante non può rivolgersi direttamente. Ciò che rende questo caso degno di essere conservato è la credenziale associata alla richiesta. Il server MCP è un delegato confuso (confused deputy) per progettazione: possiede un'identità affinché un agente possa agire per conto di un utente, e ogni parametro che un agente passa è, dal punto di vista del server, testo influenzato dall'attaccante. Quando uno di questi parametri diventa una destinazione anziché un nome, il delegato porta con sé la propria autorizzazione verso la destinazione.

La documentazione di Microsoft chiarisce dove si concentra quel rischio. Descrive il server locale come “destinato rigorosamente all’uso da parte degli sviluppatori all’interno della tua organizzazione”, mentre pubblica separatamente guide di distribuzione per server remoti self-hosted in Microsoft Foundry e Copilot Studio — le configurazioni in cui la credenziale in gioco è tipicamente un’identità gestita, anziché l’accesso dello sviluppatore stesso. Il percorso di furto del token descritto nell’avviso riguarda specificamente l’identità gestita. Non afferma che ogni installazione fosse esposta, né dice quante lo fossero.

La lezione generale è quella che l'AI Security Verification Standard di OWASP ora usa questo caso per insegnare. Il capitolo sull'orchestrazione dell'AISVS cita CVE-2026-26118 tra i suoi esempi pratici e giunge alla conclusione che «i parametri degli strumenti MCP devono essere trattati come controllati da un attaccante, e le richieste in uscita dai server MCP devono passare attraverso le stesse politiche di egress e di origine previste per qualsiasi altro I/O guidato da agenti». Si tratta di una raccomandazione sui controlli, non di una constatazione su questo incidente, ma è la risposta più concreta pubblicata finora alla domanda su cosa dovrebbe cambiare.

Cosa è cambiato dopo

Tre cose, e nessuna di esse è drammatica. Microsoft ha rilasciato pacchetti correttivi in tutti e tre gli ecosistemi e ha revisionato l'avviso per indicarli. L'ecosistema dell'intelligence sulle vulnerabilità l'ha assorbito in silenzio: un punteggio EPSS basso e una scheda NVD modificata l'ultima volta il 17 giugno 2026. E la comunità degli standard l'ha adottato come caso didattico, che è una forma di risposta più lenta e più duratura rispetto a una patch.

Per chiunque stia ancora eseguendo una build interessata, la correzione resta invariata e senza fronzoli: passare alla 1.0.2 o successiva sulla linea stabile, oppure alla 2.0.0-beta.17 o successiva sulla linea preview, in ogni gestore di pacchetti coinvolto dal deployment. Oltre a ciò, la logica stessa dell'avviso implica tre controlli: limitare ciò che il server può raggiungere in uscita, assegnare all'identità gestita solo i ruoli di cui i suoi strumenti hanno effettivamente bisogno e trattare qualsiasi parametro di strumento che possa diventare un URL come input ostile. Nessuno di questi controlli è necessario per sopravvivere a CVE-2026-26118. Ciascuno ridurrebbe il valore del successivo per un attaccante.

Come l'archivio classifica questo

Il record è classificato come vulnerabilità, ovvero qualcosa di trovato e non qualcosa di cui sia noto che sia stato sfruttato, con livello di confidenza A, il che significa ben documentato e con fonti primarie concordanti, e non è contrassegnato come contestato. Il suo campo relativo al danno reale è false e il coinvolgimento dell'IA è confermato, poiché il prodotto interessato è il ponte tra un agente IA e un piano di controllo cloud anziché un servizio generico che si trova casualmente nelle vicinanze. La data è registrata con precisione al giorno, 10 marzo 2026, senza data di fine, perché si tratta di un singolo punto nel tempo anziché di una campagna. La regione è globale e il flag landmark è false.

Un campo risulta diverso dalla valutazione pubblicata. La gravità dell'archivio è registrata come media, sulla sua scala; il numero che sia Microsoft sia NVD pubblicano è 8,8, che Microsoft chiama Important e NVD classifica come High. Il riepilogo del record inizia con quel 8,8, e la discrepanza è una differenza nel raggruppamento per fasce, non nei fatti.

Ciò che la documentazione non riesce a trasmettere è quanto questa storia sia fatta di assenze. C’è un difetto che consegna un’identità cloud a chiunque la richieda nella forma sbagliata. C’è una correzione, rilasciata prima dell’annuncio. Non c’è uno scopritore accreditato, nessuno strumento citato per nome, nessuno sfruttamento confermato e nessun modo per un esterno di sapere se qualche deployment ospitato abbia mai eseguito una build vulnerabile mentre deteneva un’identità potente. L’avviso è preciso su ciò che il difetto fa e tace su quasi tutto il resto, e quel silenzio è la cosa più utile da notare al riguardo.