Microsoft chiude una falla CVSS 10 in Azure AI e rafforza i controlli di Teams

🛡️ Executive Summary

• Microsoft ha corretto CVE-2026-85889 in Azure AI Foundry, vulnerabilità CVSS 10.0 raggiungibile senza autenticazione e senza interazione della vittima.
• Teams introdurrà da novembre policy personalizzabili per bloccare estensioni considerate pericolose, superando l’attuale blacklist fissa gestita da Microsoft.
• I due interventi mostrano lo spostamento del perimetro enterprise verso control plane AI, identità cloud e piattaforme collaborative usate anche per l’initial access.

Microsoft sta intervenendo contemporaneamente su due superfici che stanno diventando centrali nella sicurezza enterprise: agenti AI e piattaforme collaborative. In Azure AI Foundry ha corretto CVE-2026-85889, vulnerabilità con punteggio CVSS 10.0 che poteva consentire privilege escalation senza autenticazione; in Teams sta invece preparando una modifica a Weaponizable File Protection che permetterà agli amministratori di decidere quali estensioni bloccare nelle chat aziendali. Sono sviluppi tecnicamente differenti ma collegati dalla stessa trasformazione: il perimetro non termina più sull’endpoint. Passa dai servizi che orchestrano modelli, API e identità cloud e dalle piattaforme nelle quali dipendenti, contractor e interlocutori esterni scambiano quotidianamente file e collegamenti.

Azure AI Foundry aveva una funzione critica raggiungibile senza autenticazione

Il problema più grave riguarda Azure AI Foundry, piattaforma utilizzata per creare, distribuire e governare applicazioni e agenti basati sull’intelligenza artificiale. La scheda ufficiale Microsoft relativa a CVE-2026-85889 classifica il difetto come Elevation of Privilege e lo associa a CWE-306, Missing Authentication for Critical Function. Il vettore CVSS 3.1 assegnato dal vendor è AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H: l’attaccante poteva quindi raggiungere il componente attraverso la rete, senza privilegi iniziali e senza alcuna interazione dell’utente. Il cambio di scope e gli impatti elevati su confidenzialità, integrità e disponibilità spiegano il punteggio massimo, ma Microsoft non ha pubblicato dettagli tecnici sufficienti per ricostruire quali endpoint fossero vulnerabili o quali risorse potessero essere raggiunte dopo l’elevazione. Il ricercatore Rémy Marot è accreditato per la scoperta e, soprattutto, non risultano evidenze pubbliche di exploitation in-the-wild. È quindi scorretto trasformare il CVSS 10.0 nella prova di compromissioni avvenute: ciò che è verificato è l’esistenza di una funzione critica priva della corretta barriera di autenticazione.

Il problema assume un peso particolare perché Azure AI Foundry non è un servizio isolato. Può mettere in relazione modelli, agenti, dati, API, tool e identità cloud, esattamente il tipo di architettura nella quale una debolezza del control plane può avere conseguenze più ampie rispetto alla vulnerabilità di una singola applicazione. La stessa espansione della superficie è già emersa con il tool poisoning nei sistemi MCP analizzato da Microsoft, dove il rischio non risiede nel solo modello ma nelle autorizzazioni che gli vengono concesse verso strumenti esterni.

Leggi anche: OpenAI investe un miliardo nella cyber-difesa mentre Astra trova zero-day

Microsoft corregge Azure AI nel cloud, ma il cliente vede poco di ciò che è accaduto prima

Per CVE-2026-85889 Microsoft specifica che non è richiesta alcuna azione da parte dei clienti. La correzione è stata distribuita direttamente nell’infrastruttura Azure, eliminando il problema senza richiedere patch, finestre di manutenzione o aggiornamenti sui tenant. Dal punto di vista operativo è uno dei vantaggi fondamentali del cloud gestito: il provider può chiudere rapidamente una vulnerabilità senza aspettare il ciclo di patching di migliaia di organizzazioni. Questa stessa caratteristica produce però un problema di visibilità. Un amministratore può verificare se una workstation Windows ha installato una determinata KB oppure se un appliance esegue ancora una release vulnerabile; su un servizio PaaS corretto interamente dal provider dispone invece principalmente della comunicazione Microsoft. Se il vendor non pubblica endpoint coinvolti, log significativi o dettagli della primitive, diventa molto più difficile ricostruire autonomamente l’eventuale esposizione precedente alla remediation.

È il motivo per cui la sicurezza degli agenti enterprise deve essere costruita assumendo che anche il control plane possa fallire. Identità separate, connector con privilegi minimi, logging duraturo e segmentazione delle autorizzazioni restano necessari anche quando il servizio sottostante è completamente gestito. Il recente arrivo di GPT-6 Astra su Amazon Bedrock e AgentCore mostra quanto rapidamente modelli e agenti stiano entrando nelle infrastrutture aziendali attraverso piattaforme che concentrano sempre più relazioni di fiducia.

Teams permette agli amministratori di decidere quali file non devono circolare

Il secondo intervento riguarda una superficie molto diversa ma altrettanto quotidiana: Microsoft Teams. La piattaforma dispone già di Weaponizable File Protection, controllo che intercetta nelle conversazioni gli allegati con estensioni considerate potenzialmente pericolose. La documentazione ufficiale Microsoft include oggi nella lista formati come EXE, DLL, MSI, BAT, CMD, VBS, JS, LNK, ISO, IMG, JAR, APK, XLL e DOCM, cioè eseguibili, script, immagini disco, collegamenti e documenti capaci di trasportare macro o codice. Il limite attuale è che questa blacklist viene stabilita interamente da Microsoft.

L’amministratore può attivare la protezione, ma non modellarla realmente sul proprio ambiente. La situazione cambierà con la funzione registrata nella Microsoft 365 Roadmap con ID 571298: da novembre 2026 le organizzazioni potranno personalizzare i file type bloccati oppure continuare a usare l’elenco raccomandato dal vendor.

La modifica è più importante di quanto suggerisca una semplice opzione amministrativa. Un’organizzazione che non usa mai file .lnk, script PowerShell o determinati pacchetti può eliminarli completamente dalla superficie Teams, mentre reparti tecnici con esigenze specifiche possono applicare policy differenti. È il principio della least functionality trasferito alla collaborazione aziendale: se un formato non possiede una funzione legittima nel workflow, non esiste una ragione per consentirne il transito solo perché Microsoft non lo considera universalmente pericoloso.

Teams e Azure AI mostrano lo stesso problema: la trust boundary si sposta verso il servizio

Il collegamento tra i due sviluppi emerge guardando al modo in cui gli attacchi enterprise stanno cambiando. Azure AI Foundry concentra identità, modelli e tool; Teams concentra utenti, file e relazioni di fiducia. In entrambi i casi il servizio diventa un punto dal quale un attaccante può cercare di attraversare il confine che separa una funzione apparentemente legittima dalle risorse aziendali. Teams è ormai anche una superficie di initial access. Le campagne contro Microsoft 365 non dipendono più soltanto dall’email: account esterni, chat, falsi help desk, guest invitation, QR code e file condivisi possono costruire il contesto necessario per convincere una vittima a consegnare token o avviare un payload. Le campagne PREY-0058 basate su vishing e session hijacking mostrano quanto sia ormai sottile il confine tra comunicazione aziendale e vettore di compromissione, mentre BigBear 2.0 ha dimostrato che anche l’MFA Microsoft 365 può essere aggirata.

Il blocco personalizzabile delle estensioni non elimina phishing, URL malevoli o token theft, così come la patch di Azure AI Foundry non elimina il rischio creato da un agente che possiede permessi eccessivi. In entrambi i casi Microsoft sta intervenendo su un punto specifico della catena, ma la difesa efficace richiede di ragionare sulle relazioni di fiducia, non sul singolo componente.

Continua con:
Microsoft Patch Tuesday settembre 2026 corregge 966 vulnerabilità e due zero-day sfruttati
Microsoft 365: Teams non si apre ed Exchange Online ritarda le email

Microsoft sta spostando la sicurezza dove oggi transitano identità e automazioni

I due interventi raccontano quindi la stessa trasformazione da prospettive opposte. In Azure AI Foundry Microsoft ha dovuto correggere una vulnerabilità critica del piano di controllo prima che il cliente potesse fare qualcosa autonomamente; in Teams sta invece consegnando agli amministratori una capacità di enforcement più granulare su ciò che può attraversare il canale collaborativo. La lezione operativa è che cloud e collaboration non sono più servizi periferici, ma parti del perimetro di sicurezza allo stesso livello degli endpoint. Gli agenti AI possono collegarsi a repository, API e dati; Teams può portare un interlocutore esterno direttamente davanti all’utente. In entrambi i casi il rischio cresce quando il servizio eredita troppi privilegi o quando il controllo resta troppo generico. Per le organizzazioni, il criterio dovrebbe quindi essere lo stesso: concedere soltanto le capacità realmente necessarie e conservare abbastanza telemetria da ricostruire ciò che accade quando una trust boundary viene attraversata. Il problema più difficile non è più soltanto impedire l’esecuzione di un file malevolo o correggere una CVE. È sapere quale servizio può parlare con quale identità, quale dato e quale strumento, perché è precisamente in queste connessioni che si sta spostando il nuovo perimetro enterprise.