Un problema di sicurezza in alcune app Microsoft 365 per Android ha potuto mettere a rischio l’accesso agli account aziendali e personali. La soluzione più rapida è aggiornare subito Word, Excel, PowerPoint, Copilot, Loop e OneNote dal Google Play Store e, se il dispositivo è gestito da un’azienda, verificare che i criteri MDM impongano le versioni corrette.
Cosa è successo
In diverse applicazioni Microsoft 365 per Android è rimasta attiva per errore una funzione di debug che avrebbe dovuto essere usata solo durante lo sviluppo. Questa impostazione ha disattivato un controllo fondamentale che serve a limitare la condivisione dei token dell’account solo alle app Microsoft considerate attendibili.
In pratica, un’altra app installata sullo stesso telefono poteva tentare di ottenere il token dell’utente già autenticato e, se riusciva nell’operazione, accedere a email, file, calendario e messaggi come se fosse il proprietario dell’account. L’aspetto più delicato è che tutto questo poteva avvenire senza password, senza schermate di accesso e senza richieste di autorizzazione visibili all’utente.
Perché è importante
Le app Microsoft 365 su Android sono progettate per condividere l’accesso all’account in modo comodo: se un utente accede a Word, non deve rifare l’accesso da zero per PowerPoint o Excel. Questo meccanismo, però, dovrebbe funzionare solo quando la richiesta arriva da un’app Microsoft fidata.
Secondo l’analisi tecnica, proprio questo controllo era stato bypassato da una singola istruzione rimasta nel codice di produzione: setIsDebugMode(true). Il difetto si trovava in un SDK condiviso, quindi lo stesso problema poteva comparire in più applicazioni contemporaneamente.
Quali app sono state coinvolte
La vulnerabilità ha interessato Word, PowerPoint, Excel, Microsoft 365 Copilot, Microsoft Loop e OneNote. Teams non è stato colpito perché, in quel caso, la configurazione del flag risultava diversa e il controllo non era disattivato.
Questo dettaglio fa pensare a un errore di rilascio piuttosto che a una scelta architetturale intenzionale. Poiché le app coinvolte hanno una diffusione molto ampia, il potenziale impatto era elevato soprattutto sui dispositivi Android usati in ambito lavorativo.
Che tipo di token erano esposti
I token coinvolti erano token FOCI, cioè refresh token usati da Microsoft per il single sign-on tra più app della stessa famiglia. Questi token sono particolarmente sensibili perché possono essere rinnovati e riutilizzati nel tempo, mantenendo l’accesso anche oltre una singola sessione.
Dal punto di vista pratico, il traffico generato da questi token può sembrare normale nei log e non necessariamente attirare l’attenzione immediata. Per l’utente, invece, spesso non compare alcun segnale evidente che faccia capire che un’app non autorizzata stia provando a leggere i dati dell’account.
Cosa ha dimostrato la ricerca
È stato realizzato un proof of concept funzionante che mostrava come un’app di terze parti, già presente sul dispositivo, potesse intercettare i token tramite il controllo mancato e usarli per leggere la posta elettronica. In altre parole, il problema non richiedeva un exploit remoto complesso: era sufficiente la presenza di un’app malevola o compromessa sul telefono.
Microsoft classifica questo tipo di debolezza come spoofing locale. Tradotto in modo semplice, significa che il rischio nasce dal fatto che un’app riesce a fingersi un componente fidato sullo stesso dispositivo.
Correzione e versioni interessate
Microsoft ha rilasciato le correzioni l’12 maggio e ha assegnato quattro CVE alle app colpite: CVE-2026-41100 per Microsoft 365 Copilot, CVE-2026-41101 per Word, CVE-2026-41102 per PowerPoint e CVE-2026-42832 per Excel. Tutte sono state classificate come vulnerabilità di spoofing legate a un controllo di accesso improprio, cioè CWE-284.
Per Word su Android, la versione corretta indicata è la 16.0.19822.20190; le versioni precedenti risultano vulnerabili. Le altre app sono state corrette tramite aggiornamenti distribuiti attraverso Google Play.
Loop e OneNote sono stati segnalati come affetti dallo stesso problema, ma non hanno ricevuto un CVE separato nel batch di maggio. Anche in questo caso, l’azione consigliata resta l’aggiornamento alle versioni corrette.
C’è stato un uso attivo della vulnerabilità?
Non risultano indicazioni pubbliche che la falla sia stata sfruttata prima della correzione. Inoltre, nel rilascio di Patch Tuesday di maggio non è stata segnalata come vulnerabilità già nota o in exploitation attiva.
Questo non riduce l’importanza dell’aggiornamento, perché la disponibilità pubblica di un’analisi tecnica può facilitare eventuali tentativi di abuso successivi. Per questo è prudente considerare il problema come rilevante anche quando non esistono prove di sfruttamento pregresso.
Cosa devono fare gli utenti
- Aggiornare immediatamente Word, PowerPoint, Excel, Microsoft 365 Copilot, Loop e OneNote dal Google Play Store.
- Controllare la versione installata e verificare che non sia precedente a quella corretta per le app interessate.
- Su dispositivi aziendali, chiedere al team IT di forzare l’update tramite MDM.
- Se il telefono ha usato build vulnerabili, valutare la revoca dei refresh token e un nuovo accesso forzato.
Il punto più importante è che il patching chiude il problema per il futuro, ma non elimina automaticamente eventuali token già ottenuti da un attaccante prima dell’aggiornamento. Poiché i token FOCI possono sopravvivere più a lungo di una singola installazione dell’app, revocarli può essere una misura prudente nei casi ad alto rischio.
Cosa dovrebbero fare le aziende
Per le organizzazioni che gestiscono flotte Android, la priorità è verificare che i dispositivi non restino su build antecedenti alla versione corretta. È utile anche controllare i registri di autenticazione per individuare accessi sospetti, soprattutto se il dispositivo era condiviso con app di terze parti non controllate.
In ambienti aziendali, la combinazione di aggiornamento, revoca dei token e applicazione di policy MDM riduce in modo significativo la finestra di esposizione. Se un dispositivo è stato esposto a lungo e contiene account sensibili, un reset delle credenziali o una nuova autenticazione completa può essere una scelta più sicura.
Perché questo caso conta anche oltre Android
Questo episodio mostra un rischio frequente nelle applicazioni moderne: una funzione pensata per semplificare l’esperienza utente può diventare pericolosa se resta attiva nel posto sbagliato. Quando più app condividono componenti comuni, un singolo errore di configurazione può propagarsi rapidamente su larga scala.
Il caso evidenzia anche l’importanza di separare con precisione i ruoli tra app affidabili e app di terze parti. Se il controllo di fiducia si rompe, non serve necessariamente una password rubata per compromettere l’account: basta un’app installata localmente sul dispositivo.
Technical Deep Dive
La vulnerabilità ruotava attorno a un controllo di autorizzazione che avrebbe dovuto verificare se la richiesta di token provenisse da un’app Microsoft autorizzata. Invece, la modalità debug lasciata attiva nel codice di produzione faceva saltare questa verifica, consentendo a richieste non fidate di passare come legittime.
Il problema è particolarmente serio perché si colloca nel flusso del token broker e dell’SSO tra app. In uno scenario corretto, un’app client richiede l’accesso, il broker valida identità e attendibilità del chiamante, e solo dopo rilascia o rinnova il token. Se la validazione viene disattivata, il broker non distingue più una richiesta interna legittima da una proveniente da un’app malevola.
L’uso di FOCI refresh token amplifica l’impatto. Questi token sono progettati per supportare l’esperienza multi-app, ma proprio per questo hanno un ciclo di vita più lungo e possono essere riutilizzati per ottenere nuovi accessi senza l’intervento diretto dell’utente. Se sottratti, diventano un punto di persistenza utile all’attaccante.
Dal punto di vista difensivo, il rischio non si limita alla singola app vulnerabile: interessa l’intero modello di fiducia del dispositivo. Un malware già presente sul telefono può provare a sfruttare l’API locale, ottenere token e poi operare con privilegi equivalenti a quelli dell’utente. Per questo la semplice rimozione dell’app vulnerabile non basta sempre; in alcuni casi è necessario invalidare i token, verificare l’integrità del device e rivedere la postura di sicurezza complessiva.
Un altro elemento rilevante è la natura “low-noise” dell’attacco. Poiché le richieste di rinnovo token possono assomigliare a normali operazioni di background, l’abuso può passare inosservato nei controlli di routine se non esistono alert specifici su anomalie di chiamata, device posture o comportamento dell’app chiamante.
Per i team di sicurezza mobile, il caso suggerisce alcune misure pratiche: disabilitare o limitare l’installazione di app non necessarie, imporre aggiornamenti rapidi tramite MDM, monitorare il rischio di app sideloaded o poco affidabili e prevedere la revoca periodica dei token nei contesti più sensibili. In ambienti ad alta criticità, può essere utile anche segmentare gli account utilizzati su mobile rispetto a quelli con accesso privilegiato più ampio.
In sintesi tecnica, si è trattato di un errore di configurazione nel trust boundary tra app e broker di autenticazione, con impatto diretto sul rilascio di token FOCI e sul modello SSO su Android. La correzione elimina il bypass, ma la gestione del rischio residuo dipende dalla capacità di revocare i token già emessi e di verificare che i dispositivi non abbiano ospitato app ostili durante la finestra di esposizione.
Fonte: https://thehackernews.com/2026/06/microsoft-365-android-apps-let-any-app.html
