La falla di autorizzazione 9.9 dell'Azure SRE Agent avrebbe potuto consentire a un chiamante di ereditarne l'identità

CVE-2026-62830 è una vulnerabilità di autorizzazione mancante in Azure SRE Agent, l'agente basato sull'IA di Microsoft per i team di affidabilità dei siti Azure, che gestisce gli incidenti, interroga la telemetria e, se configurato, esegue interventi di correzione. Microsoft l'ha divulgata nell'agosto 2026 e l'ha valutata 9,9 su 10 — Critica — secondo il CVSS 3.1. Qualsiasi tenant Azure che eseguiva l'agente rientrava nell'ambito della vulnerabilità; l'archivio degli incidenti non registra alcuna vittima confermata né alcuno sfruttamento. La descrizione di Microsoft della vulnerabilità è una sola frase: "L'autorizzazione mancante in Azure SRE Agent consente a un attaccante autorizzato di elevare i privilegi sulla rete." Il servizio è stato corretto lato server e Microsoft afferma che i clienti non avevano nulla da applicare. La voce completa, con i suoi gradi di gravità e attendibilità, si trova nell'Orca AI Incident Archive insieme agli incidenti vicini di questa serie.

Cosa Microsoft ha pubblicato e cosa ha tralasciato

La voce della Guida agli aggiornamenti di sicurezza di Microsoft per CVE-2026-62830 documenta un'elevazione di privilegi in Azure SRE Agent, debolezza CWE-862 (autorizzazione mancante), un punteggio di base di 9,9 e un punteggio temporale di 8,6. Il vettore — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:U/RL:O/RC:C — descrive un attacco di rete che richiede solo privilegi bassi, nessuna interazione dell'utente e produce un impatto elevato su riservatezza, integrità e disponibilità. Microsoft attribuisce la scoperta al ricercatore di sicurezza wtm di Offensi nella sezione dei ringraziamenti dell'avviso.

Due parti di quel vettore raccontano la storia. La metrica Scope è Changed (S:C), che la documentazione sulle metriche di Microsoft stessa definisce come un caso in cui il componente vulnerabile e il componente interessato sono diversi e gestiti da autorità di sicurezza diverse. Le metriche temporali sono Unproven exploit code, Official fix e Confirmed, motivo per cui il punteggio temporale è inferiore a quello base.

Le FAQ dell'avviso spiegano perché esiste un 9.9 senza link per il download: "Questa vulnerabilità è già stata completamente mitigata da Microsoft. Non vi è alcuna azione da intraprendere per gli utenti di questo servizio. Lo scopo di questo CVE è fornire maggiore trasparenza." Microsoft classifica il prodotto come un servizio esclusivamente ospitato, motivo per cui la voce non riporta alcun numero di build né alcun intervallo di versioni interessate.

La tabella di sfruttabilità è chiara quanto la FAQ. Divulgato pubblicamente: No. Sfruttato: No. Valutazione di sfruttamento: Meno probabile. Ciò che l'avviso non descrive è il flusso on-behalf-of, l'identità gestita o i runbook. Né fornisce un intervallo di versioni: il CPE è il prodotto senza versione, e l'unica versione interessata elencata è un trattino. Tutto ciò che un lettore vorrebbe sapere sul meccanismo deve venire da qualche altra parte, e quel altrove è per lo più la voce dell'archivio stesso.

Che cos’è l’agente, e perché la sua identità è ciò che vale la pena raggiungere

Azure SRE Agent non è un chatbot appiccicato a una dashboard. La documentazione di Microsoft su Azure SRE Agent descrive un agente che si connette a risorse Azure, strumenti di osservabilità, piattaforme per la gestione degli incidenti e repository di codice sorgente, raccoglie segnali, correla i deployment, propone misure di mitigazione e — a seconda della modalità di esecuzione impostata dal cliente — le esegue. In modalità Review un amministratore approva le azioni di scrittura; in modalità Autonomous l'agente le applica senza attendere. La sua portata si estende tramite skill e runbook, operazioni Azure CLI, agenti personalizzati, strumenti Python, connettori MCP e hook dell'agente.

La stessa documentazione riporta il fatto che rende interessante la CVE: "L'agente si autentica con un'identità gestita e opera nell'ambito del controllo degli accessi basato sui ruoli di Azure (RBAC)." Un'identità gestita è un'identità Entra assegnata a un servizio, e ciò che può fare è esattamente ciò che consentono le sue assegnazioni di ruolo. L'autorità dell'agente non è quindi una proprietà del codice dell'agente, bensì dei ruoli associati a tale identità — ed è proprio il confine che un controllo di autorizzazione mancante non riuscirebbe a proteggere.

Una scrittura tecnica separata, la voce di HackTricks Cloud sull'escalation dei privilegi di Azure SRE Agent, descrive la versione strutturale di questo problema senza citare CVE-2026-62830. Elenca operazioni del piano di controllo che consentono a un chiamante di guidare un agente — aprire un thread, approvare una correzione proposta, riassociare la configurazione dell'agente, ripuntare un connettore dati — e inquadra il risultato come un confused deputy: il chiamante non ha bisogno delle autorizzazioni dell'agente, ma solo di un modo per indurre l'agente a usarle. Quella voce non riguarda questa CVE e non deve essere letta come una sua conferma. È utile per lo stesso motivo per cui lo è il punteggio: mostra dove risiede realmente l'autorità.

Il meccanismo: ciò che l'archivio descrive e ciò che il fornitore conferma

La voce dell'archivio descrive la vulnerabilità come un errore in quello che chiama flusso OBO (on-behalf-of) con ambito modificato. Un flusso on-behalf-of è uno scambio di token in cui un servizio sostituisce le credenziali di un chiamante con un token che gli consente di chiamare un servizio downstream come quel chiamante. Se il controllo dell'autorità durante tale scambio fallisce, secondo l'archivio la chiamata downstream può ripiegare sull'identità gestita con ambito tenant dell'agente stesso invece che sull'identità del chiamante. Un chiamante autenticato ma con privilegi limitati erediterebbe quindi le autorizzazioni dell'entità servizio dell'agente e potrebbe modificare runbook, telemetria e infrastruttura, non solo l'agente, ma ogni risorsa Azure su cui l'identità gestita detiene un ruolo.

Quella descrizione è coerente con tutto ciò che Microsoft ha effettivamente pubblicato, e non compare in ciò che Microsoft ha pubblicato. Il testo del fornitore conferma tre elementi: il controllo di autorizzazione era assente, il chiamante necessita solo di privilegi bassi e l'impatto attraversa un confine di autorità di sicurezza. Non conferma lo scambio di token, l'ereditarietà dell'identità, né gli esempi di runbook e telemetria. La voce dell'archivio è la fonte per questi elementi, e l'archivio è un dataset secondario, non il fornitore.

Una ricerca di reportage indipendente fa emergere lo stesso paragrafo in più di un luogo: il titolo sul flusso OBO e sul raggio d'impatto appare distribuito in syndication su forkast.news e su Yahoo Tech, tra gli altri. La syndication rende quella copertura un'unica fonte, non diverse. Nessun organo di informazione esaminato per questo articolo ha pubblicato la propria telemetria, una proof of concept o una riproduzione del meccanismo.

Che cosa è stabilito, che cosa è descritto e che cosa non è mai stato affermato

L'archivio assegna a questo record il grado A — ben documentato, le fonti primarie concordano — e non lo contrassegna come contestato. Non registra alcun danno nel mondo reale. Tale grado riguarda i fatti essenziali del record, e questi concordano tra le fonti; non è un'affermazione secondo cui ogni frase della voce sia stata riprodotta in modo indipendente.

• Stabilito dal fornitore. CVE-2026-62830 riguarda Azure SRE Agent, corrisponde a CWE-862 (autorizzazione mancante), ha un punteggio base CVSS 3.1 di 9,9 e un punteggio temporale di 8,6, non ha richiesto alcuna azione da parte del cliente, non è stato divulgato pubblicamente e non è stato registrato come sfruttato.

• Stabilito da reportistica e arricchimento indipendenti sulla sicurezza.Il riepilogo del Patch Tuesday di agosto 2026 di Cisco Talos elenca la CVE con lo stesso 9,9 e la stessa debolezza di autorizzazione mancante, e la colloca nella valutazione di sfruttamento «meno probabile» di Microsoft. La valutazione SSVC di CISA, registrata tramite NVD, valuta lo sfruttamento come assente, l'automatizzabilità come no e l'impatto tecnico come totale. L'arricchimento di OpenCVE elenca un punteggio EPSS di 0,00778 e registra che la CVE non è presente nel catalogo Known Exploited Vulnerabilities di CISA.

• Descritto, non confermato in modo indipendente. Il fallimento dello scambio di token OBO, l'ereditarietà dell'identità gestita dell'agente e le conseguenze su runbook, telemetria e infrastruttura provengono dalla voce dell'archivio e dalla copertura secondaria diffusa tramite syndication. L'avviso di Microsoft non li menziona. Sono la parte più utile della documentazione e la meno documentata di essa.

• Non stabilito da nessuna parte. Nessuno sfruttamento, nessuna vittima, nessuna proof of concept pubblica, nessun numero di build e nessun intervallo di versioni interessate. La riga di sfruttabilità di Microsoft — divulgato pubblicamente No, sfruttato No, meno probabile — è la cosa più vicina a un rapporto sullo stato che esista.

• Manca la copertura dei media mainstream. Le ricerche di questa CVE sulla stampa tecnologica e di sicurezza generalista non hanno prodotto alcun articolo di The Register, BleepingComputer, SecurityWeek o Help Net Security. La sua presenza pubblica si limita all'avviso del fornitore, ai database delle vulnerabilità, a un riepilogo del Patch Tuesday e all'articolo sindacato. Per un 9,9 è insolito, ed è un dato di fatto sulla documentazione più che un giudizio sul rischio.

La correzione, e i controlli che le sopravvivono

Poiché Azure SRE Agent è un servizio ospitato, la correzione è stata applicata da parte di Microsoft. Non c'è alcun aggiornamento da installare, né un numero di build da confrontare con un inventario, e non esiste modo per un cliente di confermare dall'esterno che un tenant fosse protetto prima di una determinata data. La posizione di Microsoft è che non è richiesta alcuna azione e, per quanto riguarda la vulnerabilità stessa, tale posizione è corretta.

La voce dell'archivio aggiunge indicazioni che l'avviso non specifica: verificare le assegnazioni di identità gestite, rivedere RBAC rispetto a ciò di cui l'agente ha effettivamente bisogno e monitorare l'escalation anomala dei privilegi. Queste indicazioni sono dell'archivio, non una citazione di Microsoft.

La conseguenza pratica discende dall'architettura più che dalla raccomandazione di qualsiasi fonte, quindi considerala un'inferenza. Se l'autorità dell'agente coincide con le sue assegnazioni di ruolo, allora i controlli duraturi sono la portata di tali assegnazioni e la conservazione dei log del control plane che ne dimostrerebbero l'utilizzo. Una correzione lato servizio chiude il percorso; non riduce retroattivamente un'identità gestita che è stata sovra-provisionata e non può aiutare un'organizzazione che non ha conservato i log. Entrambe queste cose sono ancora di proprietà del cliente dopo che il CVE è stato chiuso.

Dove si colloca nel lotto di agosto 2026

Il riepilogo di Talos rende inevitabile il confronto. Quel mese elenca anche CVE-2026-59118 in Copilot Cowork, un'escalation di privilegi tramite autorizzazione impropria con punteggio 9.3, e CVE-2026-56162 in Azure SQL Database, un'escalation di privilegi con punteggio 10.0. L'unica vulnerabilità che Talos segnala come sfruttata in the wild quel mese non era nessuna delle due: era CVE-2026-68820, in Windows AFD for WinSock. Le voci relative ai prodotti AI nell'elenco di Talos sono bug di autorizzazione, e questa è la forma specifica del rischio che questo record documenta.

Niente di tutto ciò rende CVE-2026-62830 una violazione. È un CVE di trasparenza per un servizio già corretto, pubblicato affinché i clienti possano vedere cosa non andava e verificare le proprie configurazioni. Il valore del record è la domanda di configurazione che lascia aperta — cosa poteva raggiungere l'identità dell'agente e se qualcuno si sarebbe accorto del suo utilizzo — non una patch da pianificare.