Aggiornamenti Android settembre 2026, corrette 180 vulnerabilità: cosa fare subito

Il primo settembre 2026, con pubblicazione effettiva dell’8 settembre, Google ha rilasciato l’Android Security Bulletin mensile e i numeri parlano da soli: 180 vulnerabilità corrette in un singolo aggiornamento, il totale più alto registrato in un bollettino mensile Android nel corso del 2026.

Il confronto con i bollettini precedenti è significativo: a giugno si era arrivati a 124 CVE e ora settembre segna un’ulteriore accelerazione che merita attenzione non solo per la quantità, ma soprattutto per la qualità delle vulnerabilità corrette.

Il bollettino è, come sempre, strutturato su due livelli di patch: il livello 2026-09-01 copre 95 vulnerabilità nei componenti Android Runtime, Framework, System, Setup Wizard e nei moduli Project Mainline; il livello 2026-09-05 aggiunge altri 85 fix che coprono il kernel Linux, Android TV e i componenti forniti dai produttori di chipset (Arm, MediaTek, Qualcomm, Unisoc e Imagination Technologies).

La notizia più rilevante è la concentrazione di vulnerabilità Remote Code Execution (RCE) di gravità critica nel componente System: sono otto, tutte con caratteristiche che in un contesto Enterprise configurano scenari di rischio ad alto impatto.

A queste si aggiungono cinque falle critiche nel kernel, inclusa una RCE nel sottosistema di Inter-Process Communication.

Non ci sono vulnerabilità zero-day confermati in exploitation attiva, il che distingue questo bollettino da quello di giugno, ma la densità e la gravità delle vulnerabilità corrette giustifica la massima priorità nell’applicazione degli aggiornamenti.

Le 8 vulnerabilità critiche che ridefiniscono la superficie d’attacco

Chiunque si occupi di sicurezza informatica sa bene che una delle minacce più insidiose è rappresentata dalle vulnerabilità di tipo Remote Code Execution senza interazione da parte dell’utente.

Nell’Android Security Bulletin del mese di settembre 2026, Google ha corretto otto vulnerabilità Remote Code Execution classificate come critiche nel componente System, che è il cuore operativo di Android:

• CVE-2026-28604, interessa Android 14, 15, 16, 16 QPR2, 17;
• CVE-2026-28618, interessa Android 16, 16 QPR2, 17;
• CVE-2026-28639, interessa Android 14, 15, 16, 16 QPR2, 17;
• CVE-2026-28662, interessa Android 16, 16 QPR2, 17 (componente Wi-Fi stack);
• CVE-2026-49882, interessa Android 14, 15, 16, 16 QPR2, 17;
• CVE-2026-49884, interessa Android 14, 15, 16, 16 QPR2, 17;
• CVE-2026-49919, interessa Android 14, 15, 16, 16 QPR2, 17;
• CVE-2026-49921, interessa Android 14, 15, 16, 16 QPR2, 17.

Tutte e otto condividono le stesse caratteristiche di rischio dichiarate da Google: nessun privilegio di esecuzione aggiuntivo richiesto, nessuna interazione dell’utente necessaria. Questo significa che un attaccante in grado di sfruttare una di queste vulnerabilità può eseguire codice arbitrario sul dispositivo bersaglio senza che la vittima debba aprire un file, cliccare su un link o avviare un’applicazione.

Vale la pena soffermarsi sulla vulnerabilità CVE-2026-28662, che colpisce lo stack Wi-Fi di Android. Le vulnerabilità nel sottosistema Wi-Fi sono storicamente tra le più sfruttate in scenari di attacco in prossimità fisica: un attaccante che si trova nella stessa rete wireless o che usa un access point rogue può tentare l’exploitation senza alcuna interazione della vittima.

In contesti aziendali con reti Wi-Fi condivise (uffici open space, sale conferenze, hotspot pubblici), questo tipo di falla ha un’amplificazione del rischio che va ben oltre il perimetro del singolo dispositivo.

Escalation di privilegi critica: il percorso verso il controllo totale

Insieme alle otto RCE, il componente System presenta anche dodici vulnerabilità di Elevation of Privilege (EoP) classificate come critiche: CVE-2026-27280, CVE-2026-28590, CVE-2026-33636, CVE-2026-45515, CVE-2026-45531, CVE-2026-49879, CVE-2026-49918, CVE-2026-49927, CVE-2026-55277, CVE-2026-55285, CVE-2026-58820 e CVE-2026-58823.

La compresenza di RCE critiche e EoP critiche nello stesso componente è la premessa tecnica per un attacco a catena completa: un attaccante che sfrutta prima una vulnerabilità RCE per ottenere esecuzione di codice remota e poi una EoP per elevarsi ai privilegi di sistema può arrivare al controllo totale del dispositivo senza mai interagire con l’utente.

Questo tipo di kill chain è quello impiegato tipicamente dagli operatori di spyware avanzato e dagli attori APT (Advanced Persistent Threat) che prendono di mira profili ad alto valore come dirigenti, responsabili di processi critici e figure con accesso a sistemi OT/ICS.

Il componente System include anche tre Denial of Service critici: CVE-2026-28653, CVE-2026-49926, CVE-2026-55256. In un contesto aziendale, un DoS riuscito su un dispositivo mobile può avere ricadute operative non trascurabili, specialmente se quel dispositivo è usato per autenticazioni MFA, accesso a VPN o comunicazioni critiche.

Il componente Framework: tre CVE critiche e una RCE High

Il componente Framework, che gestisce le API e i servizi applicativi di Android, contribuisce al bollettino con anch’esso un pacchetto significativo di vulnerabilità critiche:

• CVE-2026-28666 e CVE-2026-55273 sono entrambe vulnerabilità di Elevation of Privilege classificate Critical, capaci di consentire un’escalation remota di privilegi senza interazione utente. La prima colpisce Android 14, 15, 16, 16 QPR2, 17; la seconda le versioni più recenti, 16, 16 QPR2, 17.
• CVE-2026-49932 è invece una vulnerabilità Denial of Service critica nel Framework, che interessa l’intera gamma da Android 14 ad Android 17. Un DoS a livello di Framework può avere impatti particolarmente dirompenti perché coinvolge i servizi di sistema che le applicazioni usano per comunicare tra loro.

Il Framework presenta, inoltre, una RCE classificata con indice di gravità elevato (CVE-2026-28609), ventisei vulnerabilità EoP, cinque Information Disclosure High e quattro DoS, tutte con indice di gravità elevato. La quantità di EoP ad alta severità nel Framework, combinata con le vulnerabilità critiche nel componente System, rende questo bollettino particolarmente insidioso per chi valuta il rischio aggregato a livello di dispositivo.

Kernel Linux e componenti hardware: la supply chain della sicurezza mobile

Il secondo livello di patch dell’Android Security Bulletin del mese di settembre 2026 (2026-09-05) porta con sé alcune delle vulnerabilità tecnicamente più complesse del bollettino.

Nel kernel Linux, Google ha corretto:

• CVE-2026-31629: EoP Critical nel sottosistema NFC (Near Field Communication). Il protocollo NFC è ampiamente usato per pagamenti contactless e per l’autenticazione tramite smart card. Una vulnerabilità EoP nel driver NFC del kernel consente a un’applicazione con accesso NFC di elevare i propri privilegi al livello del kernel, con accesso potenzialmente completo alle risorse di sistema.
• CVE-2026-58846, CVE-2026-58848, CVE-2026-58941: tre EoP Critical nel sottosistema Protected Kernel-Based Virtual Machine (pKVM). Il pKVM è il componente che gestisce l’isolamento hardware tra le macchine virtuali su Android: è, in sostanza, il meccanismo che dovrebbe garantire che un’app compromessa non possa accedere ai dati di un’altra app o del sistema operativo ospite. Tre vulnerabilità critiche in questo componente rappresentano un attacco diretto alla fondamenta dell’architettura di sicurezza multi-tenant di Android moderno.
• CVE-2026-52993: RCE Critical nel sottosistema Transparent Inter-Process Communication (TIPC), identificata come vulnerabilità nei kernel components. TIPC è un protocollo di comunicazione inter-processo pensato per sistemi distribuiti e cluster. Una RCE a livello di kernel components tramite TIPC può consentire a un attaccante di eseguire codice con privilegi kernel senza interazione dell’utente, il che rappresenta uno dei tipi di vulnerabilità più gravi nell’intero panorama della sicurezza mobile.

I chipset di terze parti: Arm Mali, MediaTek, Unisoc e Qualcomm

La vastità del bollettino dell’Android Security Bulletin del mese di settembre 2026 si spiega anche con il numero eccezionale di fix per i componenti hardware di terze parti:

• Arm Mali GPU: sei vulnerabilità High (CVE-2026-0001, CVE-2026-5729, CVE-2026-7476, CVE-2026-7477, CVE-2026-12285, CVE-2026-12387). I driver GPU Mali sono presenti su un’amplissima gamma di dispositivi Android, dai flagship ai mid-range. Vulnerabilità in questi driver possono consentire escalation di privilegi a livello kernel tramite l’interfaccia grafica.
• Imagination Technologies PowerVR-GPU: venticinque vulnerabilità High, un numero eccezionalmente alto per un singolo componente hardware in un singolo bollettino. Il PowerVR è diffuso su SoC embedded e su dispositivi IoT oltre che su smartphone di fascia bassa. L’entità di questo pacchetto di fix suggerisce un’attività di audit interno significativa da parte di Imagination Technologies.
• MediaTek: diciannove vulnerabilità High che coprono i componenti Modem, HEVC decoder, APUSYS (AI Processing Unit), Geniezone, Display e VDEC. In particolare, le sei falle nel componente Modem MediaTek (CVE-2026-20457, CVE-2026-20458, CVE-2026-20459, CVE-2026-20460, CVE-2026-20461, CVE-2026-20479, CVE-2026-20500, CVE-2026-20503, CVE-2026-20504) confermano una tendenza preoccupante: il modem cellulare, che gestisce le comunicazioni radio e opera con accesso privilegiato all’hardware, continua a essere un vettore d’attacco di primo piano, specialmente in scenari che includono IMSI catcher o reti radiomobili malevole.
• Unisoc: sette vulnerabilità High, tutte nel componente Modem. I chipset Unisoc sono diffusi su dispositivi economici di fascia bassa, spesso distribuiti nei paesi in via di sviluppo ma anche presenti nella fascia consumer italiana ed europea. Questi dispositivi ricevono aggiornamenti meno frequenti e sono spesso fuori dal perimetro gestito delle flotte aziendali.
• Qualcomm: cinque vulnerabilità High nei componenti open source (tutte nel sottosistema Security, CVE-2026-24087 attraverso CVE-2026-24092), più undici vulnerabilità nei closed-source components di cui una Critical (CVE-2026-25289). Come già sottolineato nei bollettini precedenti, le vulnerabilità nei closed-source Qualcomm non possono essere verificate indipendentemente né analizzate in dettaglio, il che complica la valutazione del rischio specifico per i dispositivi basati su questi chipset.

Patch management: le finestre temporali non sono opzionali

La natura di questo bollettino – nessuna zero-day in exploitation attiva, ma densità elevatissima di RCE critiche – suggerisce un approccio operativo preciso: non c’è l’urgenza della zero-day, ma c’è la certezza che le informazioni tecniche su queste vulnerabilità sono ora pubbliche e che i tempi di sviluppo degli exploit si sono ridotti drasticamente nel corso del 2026.

Le organizzazioni con una soluzione MDM/UEM devono agire su tre fronti in parallelo:

Inventario e prioritizzazione

Occorre verificare immediatamente il security patch level di tutti i dispositivi Android aziendali e segmentarli per urgenza.

I dispositivi che eseguono versioni da Android 14 ad Android 17 sono tutti esposti in misura significativa. I dispositivi con versioni precedenti non ricevono patch da questo bollettino, ma restano esposti a tutte le vulnerabilità dei bollettini precedenti e sono già da considerare fuori perimetro.

Enforcement delle policy

Configurare le policy MDM/UEM perché i dispositivi che non raggiungono il livello 2026-09-05 entro la finestra di patching definita vengano automaticamente isolati dall’accesso alle risorse aziendali critiche (VPN, email aziendale, applicazioni business-critical).

Questo meccanismo di “conditional access” è uno strumento standard nelle piattaforme MDM moderne e dovrebbe essere attivo, non solo configurato.

Documentazione per gli audit

generare e conservare i report di conformità del patch management. In un contesto NIS2, queste evidenze possono essere richieste in sede di audit come dimostrazione delle attività di gestione delle vulnerabilità (articolo 21, paragrafo 2, lettera e della direttiva).

Un registro strutturato che mostri la percentuale di dispositivi conformi nel tempo, con le date di applicazione delle patch, è un elemento di compliance documentale non trascurabile.

I nuovi rischi per i dispositivi mobile aziendali

Ci sono altri due importanti aspetti sulla sicurezza dei dispositivi mobili aziendali che l’Android Security Bulletin per il mese di settembre 2026 porta all’attenzione degli addetti ai lavori.

L’elemento Wi-Fi: un rischio da contestualizzare geograficamente

La presenza di CVE-2026-28662, la RCE critical nel Wi-Fi stack, merita una riflessione aggiuntiva per le organizzazioni che operano in ambienti con reti wireless condivise o che dispongono di policy BYOD.

In uno scenario di attacco realistico, un threat actor che si trova nella stessa rete Wi-Fi di un dipendente o che configura un access point gemello (evil twin) potrebbe tentare lo sfruttamento di questa vulnerabilità prima che la patch sia disponibile o applicata. Le contromisure non si esauriscono nella patch, ma includono:

• Rafforzare le policy di connessione Wi-Fi sui dispositivi aziendali, consentendo solo reti certificate via profili MDM.
• Abilitare il Private DNS con DNS-over-HTTPS su tutti i dispositivi mobili aziendali per ridurre l’efficacia degli attacchi che sfruttano la manipolazione DNS in reti Wi-Fi malevole.
• Valutare l’adozione di soluzioni Mobile Threat Defense (MTD) con capacità di rilevamento degli access point rogue, specialmente per i profili ad alto rischio.

Kernel e pKVM: il rischio per i dispositivi moderni con virtualizzazione

Le tre vulnerabilità critical nel sottosistema pKVM (CVE-2026-58846, CVE-2026-58848, CVE-2026-58941) richiedono un’attenzione particolare per le organizzazioni che hanno adottato i dispositivi Android più recenti come parte della loro strategia di sicurezza mobile.

Il pKVM è un elemento cardine della sicurezza hardware su Android 13 e successivi: è il componente che consente di isolare i dati sensibili come le chiavi crittografiche del keystore in un ambiente separato dal sistema operativo principale. Se questo isolamento viene compromesso, le garanzie di sicurezza hardware su cui si basa, ad esempio, il modello di attestazione dei dispositivi Android Enterprise vengono messe in discussione.

Per le organizzazioni che usano attestazione hardware per il controllo dell’accesso condizionale (scenario comune nelle architetture Zero Trust), l’applicazione delle patch al kernel è quindi non solo un requisito di sicurezza generale, ma un prerequisito per la tenuta dell’intera architettura di trust.

Il contesto NIS2 e DORA: i dispositivi mobili entrano nel perimetro

Il bollettino di settembre 2026 arriva in un momento in cui le autorità di supervisione NIS2 in tutta Europa stanno completando i primi cicli di verifica della conformità. Per i soggetti essenziali e importanti, la domanda non è più “dobbiamo gestire i dispositivi mobili?” ma “come dimostriamo che li gestiamo adeguatamente?”.

Alcune verifiche che i consulenti dovrebbero portare all’attenzione dei loro clienti alla luce di questo bollettino:

Per i soggetti NIS2

Il bollettino di settembre copre vulnerabilità nei componenti che gestiscono NFC, Wi-Fi, comunicazioni inter-processo e virtualizzazione del kernel.

Questi non sono componenti “periferici”, sono quelli che gestiscono le comunicazioni di rete, l’autenticazione e l’isolamento dei dati su qualsiasi dispositivo moderno.

Un vulnerability management program che non copre i dispositivi mobili con la stessa sistematicità degli endpoint tradizionali non è compliant con la direttiva.

Per i soggetti DORA nel settore finanziario

La concentrazione di vulnerabilità critiche nei modem (MediaTek, Unisoc) è particolarmente rilevante per le organizzazioni che usano dispositivi mobili per operazioni bancarie, autenticazioni MFA su SMS o comunicazioni con infrastrutture di trading.

Il modem di un dispositivo aziendale non patchato è un vettore di attacco che può bypassa i controlli perimetrali tradizionali.

Per le PMI fuori perimetro NIS2 diretto

Anche le organizzazioni non direttamente soggette alla direttiva dovrebbero considerare che la crescente frequenza e gravità dei bollettini Android è un indicatore di un trend strutturale, non di un’anomalia congiunturale.

Investire in un processo minimale ma sistematico di patch management mobile è oggi un requisito di igiene cyber, non un differenziale competitivo.

Conclusioni

L’Android Security Bulletin di settembre 2026 è, per volumetria e gravità, il più impegnativo del 2026 finora. Centottanta vulnerabilità, otto RCE critiche nel componente System, cinque vulnerabilità critiche nel kernel e un numero eccezionale di fix per i componenti hardware di Imagination Technologies e MediaTek: il quadro che emerge è quello di un ecosistema ancora profondamente esposto, nonostante i progressi significativi compiuti da Google nell’architettura di sicurezza di Android negli ultimi anni.

L’assenza di zero-day in exploitation attiva confermata è un elemento positivo, ma non deve diventare un alibi per rallentare i tempi di aggiornamento.

Le vulnerabilità descritte in questo bollettino sono ora pubbliche, le loro caratteristiche tecniche sono note e la distanza tra la pubblicazione di un bollettino e lo sviluppo di exploit funzionanti si misura, nel 2026, in giorni o settimane non in mesi.

Per le organizzazioni che gestiscono flotte di dispositivi mobili nell’ambito di un percorso di conformità NIS2 o DORA, settembre 2026 è un test concreto della maturità del loro processo di vulnerability management mobile.

Un test che conviene prepararsi a superare prima che arrivi il controllo dell’autorità di supervisione o, ancora peggio, un attacco informatico alle proprie infrastrutture.