CVE 10.0 in Azure AI Foundry: rischio per gli agenti AI

Il fatto: punteggio massimo su una piattaforma per agenti

CVE-2026-85889 raggiunge un punteggio CVSS di 10.0, il tetto della scala. Microsoft ha rilasciato la correzione per Azure AI Foundry, la piattaforma enterprise su cui le imprese costruiscono, distribuiscono e gestiscono applicazioni e agenti generativi.

L'advisory, pubblicato giovedì 17 settembre 2026, parla di «missing authentication for critical function»: una funzione critica della piattaforma restava raggiungibile via rete da un attaccante privo di autorizzazione, con esito di elevazione dei privilegi. The Hacker News ha riportato la vicenda il 18 settembre 2026^[1], attribuendo la scoperta al ricercatore Rémy Marot.

L'azienda dichiara zero evidenze di sfruttamento in the wild. La stessa nota chiarisce che il difetto risulta già mitigato sul lato cloud.

Il dato che conta per chi progetta sistemi agentici sta nella combinazione delle condizioni: punteggio massimo, vettore di rete, autenticazione assente, privilegi elevati come risultato.

Il meccanismo: autenticazione assente davanti a una funzione critica

Un CVSS 10.0 nasce da una somma precisa. Vettore di rete, complessità di attacco bassa, privilegi richiesti pari a zero, interazione dell'utente pari a zero, impatto pieno su riservatezza, integrità e disponibilità.

La classe di difetto è l'assenza di un controllo di identità davanti a una funzione che invece lo richiede. Il codice applicativo può risultare corretto, il modello allineato, il prompt filtrato: l'accesso arriva a monte di tutto questo, prima della logica di business.

Cybersecurity News^[2] riprende la stessa descrizione tecnica e la stessa attribuzione, e conferma l'assenza di azioni richieste ai clienti. Il dettaglio pubblico si ferma alla classificazione, come accade di regola per i CVE cloud.

La catena esatta di chiamate resta interna al fornitore. Chi valuta il rischio lavora quindi su una etichetta, mai su una traccia riproducibile.

Piano di controllo, altro livello rispetto al modello

Qui sta il punto che separa questa vicenda dalle discussioni abituali su allucinazioni e jailbreak. Il difetto tocca il piano di controllo, cioè lo strato che crea gli agenti, monta i deployment, gestisce le chiavi e collega i modelli ai dati aziendali.

Un attacco al modello produce output sbagliati. Un attacco al piano di controllo produce accesso a risorse, a configurazioni e ad altri agenti.

In un contesto agentico la superficie di attacco coincide con la piattaforma di orchestrazione. Un agente eredita le credenziali del proprio ambiente di esecuzione: chi eleva i privilegi su quell'ambiente raggiunge a sua volta tutto ciò che l'agente raggiunge.

La security posture dei sistemi AI resta due o tre anni indietro rispetto alla maturità dell'infrastruttura che li ospita. Lo schema si ripete su framework, runtime e piattaforme gestite: prima la produzione, poi l'hardening.

«No customer action required»: la parte scomoda

La mitigazione lato cloud è insieme una buona notizia operativa e un problema di governance. Buona notizia: il rischio risulta chiuso a monte e i clienti hanno zero patch da applicare, zero finestre di manutenzione da negoziare.

Il rovescio riguarda la verifica. Manca una KB da tracciare, manca una versione da confrontare, manca un artefatto da inserire nel proprio inventario delle vulnerabilità.

Un revisore che domanda «per quanto tempo siamo rimasti esposti» riceve come risposta la data dell'advisory. La finestra reale, quella fra introduzione del difetto e correzione, rimane informazione del fornitore.

Questa asimmetria produce effetti contrattuali concreti. Un'impresa regolata deve dimostrare controllo su ciò che ospita dati sensibili, e la dimostrazione poggia interamente sulla dichiarazione del provider.

Chi tratta il cloud come pura fornitura di capacità accetta il modello. Chi lo considera parte del proprio perimetro di conformità deve metterlo nero su bianco nel contratto.

La finestra completa: Copilot, PostgreSQL, Cosmos DB

La falla di Foundry arriva accompagnata da altre correzioni critiche della stessa finestra. Vale la pena leggerle come un insieme, poiché toccano lo stack completo su cui poggia un'applicazione agentica.

• CVE-2026-85885 (CVSS 9.9): command injection in Microsoft 365 Copilot, con elevazione di privilegi via rete da parte di un attaccante autorizzato
• CVE-2026-85878 (CVSS 9.9): autorizzazione impropria in Azure Database for PostgreSQL
• CVE-2026-87701 (CVSS 9.6): neutralizzazione impropria in Azure Cosmos DB
• CVE-2026-62721 (CVSS 7.8) e CVE-2026-85921 (CVSS 8.2): elevazione locale su Windows 11 versione 26H1, chiuse con l'aggiornamento fuori ciclo KB5129194

Il layer applicativo, il layer dati e il layer di piattaforma compaiono nella stessa settimana. Un agente in produzione attraversa abitualmente tutti e tre, e un difetto su uno qualsiasi di essi lo raggiunge.

Nella settimana precedente Microsoft aveva corretto 974 vulnerabilità sul proprio portafoglio software, un record secondo la ricostruzione della stessa testata. Il volume dice qualcosa sulla velocità con cui la superficie si espande.

Le tre falle cloud condividono un tratto: risultano già mitigate, con zero interventi richiesti. La classe di rimedio è identica, e identico è il limite di trasparenza.

Tre domande per un team AI enterprise

La parte utile del lavoro arriva dopo l'advisory. Tre punti meritano una risposta scritta prima del prossimo ciclo di rilascio.

1. Quali agenti in produzione girano su Azure AI Foundry, e quale identità e quale ambito di permessi porta ciascuno di essi?
2. Quale log dimostra il comportamento di quegli agenti fra la data di creazione del deployment e la data dell'advisory?
3. Quale procedura revoca in meno di un'ora le credenziali di un agente compromesso, e chi la esegue fuori orario?

La terza domanda smaschera le architetture fragili. L'identità dell'agente è il piano di controllo di questa stagione: ciò che manca di credenziali proprie e di log nominativi rimane fuori da qualsiasi revoca, e ciò che sfugge alla revoca sfugge al governo.

Un sistema multi-agente privo di circuit breaker espliciti fallisce a cascata. L'output di un agente diventa l'input del successivo, e la validazione indipendente fra i due passaggi manca quasi sempre.

Decisioni per il prossimo planning cycle

Per un CTO la conseguenza immediata è un esercizio di inventario. Serve la lista degli agenti attivi, del piano di controllo che li ospita e delle risorse che ciascuno tocca con le proprie credenziali.

Per un Head of Engineering la scelta riguarda i confini di esecuzione. Un agente merita un'identità dedicata, un ambito di permessi ristretto e un punto di validazione fra una chiamata e la successiva.

Per un CFO il conto cambia poco sull'investimento e parecchio sul rischio residuo. La piattaforma gestita sposta il costo dell'hardening sul fornitore e, insieme, sposta la capacità di dimostrare quel controllo davanti a un auditor.

Per un comitato di procurement la leva esiste e va usata al rinnovo. Tre clausole valgono la trattativa: notifica entro un termine definito per i CVE che toccano il piano di controllo, accesso ai log di audit del tenant con retention concordata, diritto a un rapporto post-incidente con la finestra temporale di esposizione.

Trappola architetturale oppure vantaggio competitivo

La risposta resta articolata. Azure AI Foundry rimane una piattaforma production-grade, e la gestione di questa falla lo conferma: punteggio massimo, rimedio applicato a monte, zero interruzioni per i clienti, ricercatore esterno accreditato.

Il lock-in architetturale, invece, si paga in visibilità. Chi costruisce agenti dentro un piano di controllo gestito delega la security posture a un soggetto terzo e la verifica per via documentale.

Lo scambio risulta ragionevole per la maggior parte delle imprese. Diventa technical debt quando l'architettura poggia su un fornitore unico per modello, orchestrazione, identità e dati, poiché in quella configurazione un difetto del piano di controllo attraversa l'intera catena in un colpo solo.

La decisione concreta per il prossimo planning cycle sta nella separazione dei livelli. Identità degli agenti gestita fuori dalla piattaforma che li esegue, log replicati in un sistema indipendente, un secondo percorso di deployment mantenuto caldo. Fault tolerance significa questo: la piattaforma cade, il controllo resta.