Microsoft Authenticator per Android: il "confused deputy" che consegnava token aziendali a chiunque

Microsoft ha assegnato CVE-2026-80097 a una vulnerabilità di elevata gravità in Microsoft Authenticator per Android che permetteva a qualsiasi app installata sul dispositivo di rubare token di accesso agli account di lavoro. I dettagli tecnici, pubblicati da Enclave il 23 ottobre 2026, rivelano un errore di progettazione nell'activity esportata AccountChooserActivity: il broker di autenticazione vedeva l'identità reale del chiamante ma sceglieva di non usarla per decidere chi fidarsi. Il risultato era una porta aperta verso email, file, calendari e — tramite manipolazione delle passkey — una persistenza silenziosa che sopravvive alla rimozione stessa dell'app malevola.

Il meccanismo del "confused deputy": fidarsi delle dichiarazioni, non dell'identità

Il cuore della vulnerabilità risiede in un pattern noto in sicurezza informatica come "confused deputy attack": un componente con privilegi elevati (il "deputato") viene indotto a compiere azioni per conto di un attore che non ha diritto di farle. Nel caso di Microsoft Authenticator, il componente vulnerabile è l'activity Android com.microsoft.identity.client.AccountChooserActivity, esportata e quindi raggiungibile da qualsiasi app installata sul dispositivo senza bisogno di autorizzazioni particolari.

Secondo le ricerche pubblicate da The Hacker News e confermate da Cybersecurity News, questa activity accettava richieste di token incapsulate in un JSON broker_request_v2. Il controllo di sicurezza implementato da Microsoft verificava che il redirect URI e il client ID forniti dall'app richiedente corrispondessero a quelli di un'app Microsoft legittima installata sul dispositivo — tipicamente Microsoft Teams. Tuttavia, questo controllo si limitava a confrontare i metadati dichiarati dall'app richiedente con i metadati pubblicamente leggibili dell'app impersonata. "Authenticator knew which app was really calling. It just never used that information to decide whether to trust it", riporta la ricerca di Enclave citata da The Hacker News.

Il sistema operativo Android fornisce al chiamante l'identità reale del package e dell'UID che ha avviato l'activity. Microsoft Authenticator riceveva questa informazione ma non la utilizzava per validare la corrispondenza con l'identità dichiarata nel JSON. Questo gap tra consapevolezza e enforcement — il broker sapeva chi chiamava ma sceglieva di non agire su questa conoscenza — è ciò che trasforma una potenziale difesa in una vulnerabilità concreta.

Da token Graph a persistenza: l'escalation oltre il furto iniziale

Una volta ottenuti i token tramite l'impersonazione di Teams, l'app malevola accedeva a una gamma estesa di servizi Microsoft 365. I permessi delegati ottenuti, documentati da HWUpgrade e confermati dai test di Enclave, includevano la lettura e scrittura di email (Mail.ReadWrite), l'invio di messaggi (Mail.Send), l'accesso completo ai file in OneDrive e SharePoint (Files.ReadWrite.All), e la gestione del calendario (Calendars.ReadWrite). L'accesso alle chat di Teams è altresì documentato nei test del ricercatore Ofek Levin.

L'impatto non si limitava però all'esfiltrazione in tempo reale. Secondo Help Net Security, l'app malevola poteva impersonare direttamente Microsoft Authenticator stesso per modificare i metodi di accesso dell'account vittima. Questo includeva la creazione di nuove passkey controllate dall'attaccante, che fungevano da metodo di autenticazione aggiuntivo legato all'identità dell'utente. La conseguenza è una forma di persistenza particolarmente insidiosa: anche dopo la rimozione dell'app malevola o l'aggiornamento alla versione patchata, le passkey aggiunte rimanevano valide come metodo di accesso legittimo.

Resta non confermato se l'aggiornamento alla versione 6.2606.4246 revochi automaticamente i token precedentemente rubati o le passkey aggiunte. HWUpgrade solleva il dubbio specifico sulla validità dei refresh token sottratti prima della patch, suggerendo che potrebbero rimanere attivi; Microsoft non ha pubblicato chiarimenti su questo punto.

Divergenza sui requisiti di attacco: con o senza interazione utente?

Un punto di frizione tra le fonti riguarda la necessità di interazione utente per il successo dell'attacco. Microsoft, nell'advisory ufficiale MSRC per CVE-2026-80097, assegna il vettore CVSS UI:R (User Interaction Required) e descrive l'attacco come richiedente che l'utente completi un flusso di autenticazione in Microsoft Authenticator. La citazione ufficiale recita: "An attacker could exploit this vulnerability by installing and running a malicious application on an affected Android device and convincing the user to complete an authentication flow in Microsoft Authenticator".

Enclave, il team di ricerca che ha divulgato la vulnerabilità, sostiene invece che "The app didn't need permissions, and you didn't need to tap anything" — riassunto riportato da Help Net Security. Questa discrepanza non è risolta nel materiale disponibile: può riflettere diverse condizioni di test, varianti del flusso di attacco, o una valutazione diversa di cosa costituisca "interazione" nel contesto di un'activity avviata programmaticamente. La calibrazione della certezza richiede di presentare entrambe le posizioni senza forzarne la ricomposizione.

"Improper authentication in Microsoft Authenticator allows an unauthorized attacker to elevate privileges locally" — Microsoft MSRC, CVE-2026-80097

La patch e il perimetro di esposizione: versioni e aggiornamenti

Microsoft ha rilasciato la correzione in Microsoft Authenticator per Android versione 6.2606.4246, con distribuzione effettiva a partire da luglio 2026 secondo Cybersecurity News. Il punteggio CVSS assegnato ufficialmente è 8.6, con vettore completo CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H, classificazione di severity "Important" e valutazione di exploitabilità "Exploitation Less Likely". Microsoft dichiara che la vulnerabilità non è stata sfruttata in attacchi reali noti.

Il CVE-2026-80097 è stato assegnato da Microsoft l'8 settembre 2026. La natura della vulnerabilità è codificata come CWE-287 (Improper Authentication). Non emergono nel dossier informazioni su varianti simili in altri identity broker mobile Microsoft o su estensione quantitativa della popolazione di dispositivi effettivamente esposti.

La fonte non specifica se la patch implementi ora la validazione dell'identità reale del chiamante tramite package/UID o se adotti un diverso meccanismo di restrizione dell'accesso all'activity. Questo dettaglio architetturale rientra nei limiti del materiale raccolto.

Cosa fare adesso

• Verificare che i dispositivi Android aziendali con Microsoft Authenticator siano aggiornati alla versione 6.2606.4246 o successiva, distribuendo l'aggiornamento tramite MDM con priorità sui profili di lavoro.
• Controllare i log di accesso Microsoft Graph per attività anomala su account che utilizzano Authenticator su Android, con attenzione a picchi di accesso da applicazioni client non standard.
• Rivedere i metodi di accesso registrati per gli account aziendali interessati, verificando la presenza di passkey aggiunte in periodi sospetti o non documentati.
• Limitare il sideloading di applicazioni sui dispositivi Android aziendali, data la assenza di requisiti di permessi speciali per l'exploit della vulnerabilità.

Perché il design dei broker OAuth mobile continua a sottovalutare l'enforcement

La lezione di CVE-2026-80097 non è quella di un bug di implementazione banale, ma di una scelta architetturale che privilegiava la verifica dei metadati dichiarati rispetto all'identità attestata dal sistema operativo. Nei broker OAuth mobile — componenti sempre più centrali nell'architettura aziendale zero-trust — questa distinzione è critica: il package name è un'affermazione, l'UID è un fatto. La tendenza industriale a trattare il primo come sufficiente riflette una fase di maturità incompleta nel design sicuro delle inter-app communication su piattaforme mobili.

Il caso solleva inoltre una questione di persistenza che trascende la singola vulnerabilità. Quando un identity broker può essere indotto a modificare i propri metodi di accesso, la compromissione diventa strutturale: non più un accesso abusivo da revocare, ma una identità digitale estesa con componenti controllate dall'attaccante. La gestione del ciclo di vita delle passkey — chi può aggiungerle, chi può revocarle, cosa succede quando il broker di origine è compromesso — è un perimetro di governance ancora poco esplorato nelle implementazioni correnti.

Domande frequenti

La vulnerabilità interessa anche Microsoft Authenticator per iOS?

No. Il componente vulnerabile è specifico dell'implementazione Android di Microsoft Authenticator; non emergono indicazioni di problematiche equivalenti nella versione iOS.

L'aggiornamento alla versione patchata revoca automaticamente i token rubati?

Non è confermato dalle fonti disponibili. Resta un punto non chiarito da Microsoft se l'aggiornamento a 6.2606.4246 invalidi i refresh token precedentemente emessi o le eventuali passkey aggiunte dall'attaccante.

Quale tra le fonti ha ragione sull'interazione utente?

Microsoft e Enclave presentano valutazioni divergenti non riconciliate nel dossier. L'advisory ufficiale MSRC include UI:R (interazione richiesta); Enclave descrive test senza interazione. La discrepanza può riflettere condizioni sperimentali diverse.

Fonti

• thehackernews.com
• helpnetsecurity.com
• hwupgrade.it
• cybersecuritynews.com
• msrc.microsoft.com