Google ha pubblicato l’Android Security Bulletin mensile, un documento che questa volta merita un’attenzione superiore alla media. Il bollettino descrive 124 vulnerabilità di sicurezza che interessano il sistema operativo Android, distribuite come sempre su due livelli di patch (2026-06-01 e 2026-06-05), e copre componenti che vanno dal Framework di sistema fino ai driver proprietari di Qualcomm, MediaTek, Unisoc e Imagination Technologies.
La notizia che domina, però, è un’altra: tra le vulnerabilità corrette figura la CVE-2025-48595, una falla classificata come High severity (CVSS 8.4) nel componente Framework di Android, per la quale Google ha confermato l’esistenza di “indicazioni di sfruttamento limitato e mirato in the wild”. In altri termini, al momento del rilascio del bollettino, qualcuno stava già usando questa vulnerabilità contro bersagli reali.
Non si tratta di una notizia insolita nel panorama Android (le zero-day in exploitation attiva compaiono periodicamente nei bollettini mensili di Google) ma la frequenza con cui questo avviene e la tipologia di attacchi associati dovrebbe spingere qualsiasi responsabile della sicurezza aziendale a una riflessione seria sui processi di patch management per i dispositivi mobili.
Indice degli argomenti
Anatomia di una zero-day nel Framework Android
La CVE-2025-48595 è una vulnerabilità di tipo Elevation of Privilege (EoP) che risiede nel componente Framework di Android. La causa radice è un integer overflow in più posizioni del codice, che può portare all’esecuzione di codice arbitrario con privilegi elevati a partire da un processo non privilegiato.
Le caratteristiche che rendono questa falla particolarmente pericolosa sono due e vanno lette insieme:
- nessun privilegio di esecuzione aggiuntivo richiesto: l’attaccante non ha bisogno di partire da una posizione già privilegiata nel sistema;
- nessuna interazione dell’utente necessaria: la vittima non deve cliccare su nulla, aprire alcun file, installare alcuna applicazione. La vulnerabilità può essere sfruttata in modo completamente silenzioso.
Questa combinazione è la firma tecnica degli attacchi zero-click, ovvero quegli attacchi particolarmente temuti nell’industria della sicurezza perché non lasciano all’utente finale alcuna finestra di reazione.
Le versioni di Android interessate sono 14, 15, 16 e 16 QPR2 (Quarterly Platform Release 2), il che significa che praticamente tutti i dispositivi moderni con software aggiornato erano esposti fino all’arrivo delle patch.
Il profilo degli attaccanti e le vittime probabili
Google non ha fornito dettagli sugli autori degli attacchi o sui bersagli colpiti, il che è prassi consolidata. Tuttavia, il profilo tecnico della vulnerabilità (zero-click ed escalation di privilegi remota) coincide precisamente con le capacità richieste dagli operatori di spyware commerciale, come quelli già documentati in passato nei casi Pegasus, Predator e similari.
Questi strumenti vengono venduti a governi e agenzie di intelligence, spesso con targeting molto selettivo che include giornalisti, attivisti, dirigenti aziendali e funzionari di alto profilo.
Per un consulente che opera in contesti Enterprise, questo dato è rilevante: anche se la propria organizzazione non è un bersaglio di spionaggio statuale, la natura della vulnerabilità e la velocità con cui gli exploit vengono adattati e riutilizzati impone tempi di risposta rapidi.
Il quadro completo: le altre vulnerabilità del bollettino
L’Android Security Bulletin del mese di giugno 2026 interviene, come dicevamo, su un totale di 124 vulnerabilità. Di seguito, analizziamo le principali.
Il componente Framework (patch level 2026-06-01)
Il Framework è il componente più colpito di questo bollettino, con 32 vulnerabilità risolte. Di queste, due sono classificate Critical: CVE-2025-65018 (EoP remoto, Critical) e CVE-2025-64720 (DoS, Critical), entrambe con impatto su Android 14, 15, 16 e 16 QPR2.
Le restanti vulnerabilità nel Framework si distribuiscono tra escalation di privilegi (EoP), information disclosure (ID) e denial of service (DoS), tutte con severità High.
Particolarmente degna di nota è la presenza di quattro vulnerabilità di Information Disclosure nel Framework: CVE-2026-0016, CVE-2026-0036, CVE-2026-0056 e CVE-2026-28586. In un contesto aziendale, la divulgazione non autorizzata di informazioni da un dispositivo mobile può avere impatti diretti sulla conformità al GDPR e, in alcuni settori, alla direttiva NIS2, soprattutto quando si tratta di dispositivi che accedono a reti operative o a sistemi di controllo industriale.
Il componente System (patch level 2026-06-01)
Il componente System presenta un elenco ancora più preoccupante, con ben 10 vulnerabilità Critical e una vulnerabilità di tipo Remote Code Execution (RCE) classificata High (CVE-2026-0059) che può portare all’esecuzione remota di codice senza privilegi aggiuntivi e senza interazione dell’utente.
Tra le vulnerabilità critiche di tipo EoP spiccano CVE-2026-0043, CVE-2026-0097, CVE-2026-21352 e CVE-2026-21353, mentre il gruppo delle vulnerabilità critiche di tipo DoS include CVE-2025-64505, CVE-2026-0039, CVE-2026-0040, CVE-2026-0041, CVE-2026-0042, CVE-2026-0044, CVE-2026-0051, CVE-2026-0052 e CVE-2026-0080.
Una vulnerabilità RCE nel componente System, abbinata a più escalation di privilegi nello stesso componente, configura una kill chain potenzialmente completa: un attaccante in grado di concatenare queste vulnerabilità potrebbe passare dall’accesso remoto iniziale al controllo totale del dispositivo senza mai richiedere l’interazione dell’utente.
Il patch level 2026-06-05 per le componenti di terze parti
Il secondo livello di patch, il 2026-06-05 security patch level, copre vulnerabilità nei componenti del Kernel Linux e in quelli forniti da produttori di chipset terzi. Nel dettaglio:
- Kernel Linux: CVE-2025-40214, una vulnerabilità EoP nel sottosistema di rete (Net) con severità High.
- Imagination Technologies (PowerVR-GPU): tre CVE (CVE-2026-21736, CVE-2026-22163, CVE-2026-22167), tutte High, che interessano la GPU PowerVR integrata in alcuni SoC ARM. Importante soprattutto per dispositivi IoT e sistemi embedded che impiegano questa architettura.
- MediaTek: undici vulnerabilità High, concentrate su Modem, Geniezone e Preloader. Le falle nel modem sono storicamente le più sensibili perché un attaccante che si trova sulla stessa rete radio (ad esempio in scenari di IMSI catcher) potrebbe sfruttarle senza alcuna azione della vittima.
- Unisoc: sedici vulnerabilità High nel componente Modem, diffuso prevalentemente su dispositivi economici di fascia bassa. La superficie d’attacco è ampia perché questi dispositivi sono spesso meno presidiati dal punto di vista del patch management aziendale.
- Qualcomm: due vulnerabilità High nei componenti Display (CVE-2026-24085, CVE-2026-24089) nelle componenti open source, più un elenco significativo di vulnerabilità nei closed-source components di Qualcomm, tre delle quali classificate Critical (CVE-2025-47392, CVE-2026-25276, CVE-2026-25277). I componenti closed-source Qualcomm, per loro natura, non possono essere ispezionati pubblicamente, il che rende più complessa la valutazione del rischio specifico.
Gestione del rischio: cosa devono fare le aziende
Il primo principio è semplice ma spesso disatteso nelle organizzazioni: applicare le patch entro finestre temporali definite e documentate, differenziate per livello di rischio. Questo bollettino contiene vulnerabilità in exploitation attiva, il che impone la massima priorità.
Dal punto di vista operativo, le aziende che dispongono di una soluzione MDM (Mobile Device Management) o UEM (Unified Endpoint Management) devono:
- Verificare immediatamente il livello di patch corrente su tutti i dispositivi Android aziendali, con attenzione specifica ai dispositivi BYOD che accedono a risorse aziendali.
- Configurare policy di enforcement che blocchino l’accesso alle risorse aziendali (VPN, email, applicazioni critiche) per i dispositivi che non raggiungono il security patch level 2026-06-05 entro la finestra di patching stabilita.
- Generare e conservare i report di conformità, che possono essere richiesti in sede di audit NIS2 come evidenza delle attività di vulnerability management (articolo 21, paragrafo 2, lettera e della direttiva).
Il problema dei dispositivi non aggiornabili
Uno dei nodi più critici nella gestione dei dispositivi mobili aziendali è la presenza di dispositivi che non ricevono più aggiornamenti di sicurezza: Android con versioni precedenti alla 14 non è coperto da questo bollettino, ma resta esposto a tutte le vulnerabilità non corrette nei bollettini precedenti.
La raccomandazione è netta: i dispositivi Android senza supporto attivo del produttore non devono accedere a reti o applicazioni aziendali critiche. In un contesto NIS2, questo non è solo una best practice: è parte integrante del requisito di gestione del rischio per i soggetti essenziali e importanti che gestiscono flotte di dispositivi mobili.
Zero-click e spyware: il rischio per i profili ad alto valore
Per le organizzazioni che gestiscono figure con accesso a informazioni sensibili, ossia dirigenti, responsabili di processi critici, personale con accesso a sistemi OT/ICS o a infrastrutture NIS2-rilevanti, la presenza di vulnerabilità zero-day con capacità zero-click richiede misure aggiuntive rispetto al semplice patching:
- Implementare Mobile Threat Defense (MTD) su tutti i dispositivi dei profili ad alto rischio, con capacità di detection comportamentale e network-level, non solo signature-based.
- Valutare l’adozione di dispositivi con certificazioni di sicurezza elevate (es. Android Enterprise Recommended, Samsung Knox, dispositivi con profilo di sicurezza hardware rafforzato) per le figure più esposte.
- Considerare la segmentazione dei flussi di dati tra dispositivi personali e aziendali attraverso containerizzazione, anche in assenza di MDM completo.
Log, monitoring e incident response
Un aspetto spesso trascurato è che la presenza di una vulnerabilità zero-day in exploitation attiva cambia il livello di priorità anche per le attività di threat hunting e monitoring. Anche per le organizzazioni che applicano le patch rapidamente, è opportuno:
- Verificare nei log di accesso e nei sistemi SIEM se vi siano stati comportamenti anomali sui dispositivi mobili nelle settimane precedenti all’applicazione delle patch, cercando indicatori tipici di compromise da spyware (connessioni a C2 inusuali, accessi anomali a dati di localizzazione, attivazioni non autorizzate di microfono/fotocamera).
- Rivedere i log di Google Play Protect e, dove disponibile, i report di Mobile Threat Defense, alla ricerca di applicazioni potenzialmente dannose installate da fonti non ufficiali.
- Aggiornare i playbook di incident response per includere scenari specifici di compromissione di dispositivi mobili, con procedura di forensics e isolamento appropriata.
Il contesto NIS2: i dispositivi mobili come attack surface trascurata
La direttiva NIS2 impone ai soggetti in scope un approccio sistematico alla gestione della sicurezza delle reti e dei sistemi informativi. I dispositivi mobili rientrano pienamente in questo perimetro quando vengono usati per accedere a reti aziendali, a sistemi di elaborazione di dati critici o a infrastrutture operative.
Il bollettino di giugno 2026 è un promemoria concreto di un rischio spesso sottovalutato: la superficie d’attacco mobile è immensa, è gestita in parte da soggetti terzi (gli OEM che decidono quando e se rilasciare le patch sui propri dispositivi) e include componenti come i modem Qualcomm, MediaTek e Unisoc su cui l’organizzazione ha un controllo operativo limitato.
Per i consulenti che assistono le organizzazioni nel percorso di conformità NIS2, questo bollettino suggerisce alcune verifiche immediate:
- Asset inventory aggiornato dei dispositivi mobili con versione Android e livello di patch corrente: senza questo dato di base, qualsiasi valutazione del rischio è parziale.
- Processo documentato di vulnerability management per i dispositivi mobili, distinto da quello per endpoint tradizionali, con SLA di patching differenziati per livello di criticità della vulnerabilità.
- Policy di acceptable use aggiornate che definiscano chiaramente cosa accade a un dispositivo non conforme ai requisiti di patch level.
- Valutazione dei fornitori MDM/UEM come parte della supply chain di sicurezza, con verifica che le soluzioni adottate supportino le versioni Android in uso e permettano un enforcement granulare delle policy di aggiornamento.
Cosa fare: le azioni immediate
Di seguito, ecco alcune indicazioni operative per mettere in sicurezza i propri dispositivi mobile.
Per gli amministratori di sistema e i team IT
Verificare il livello di patch su tutti i dispositivi Android aziendali tramite MDM/UEM e forzare l’aggiornamento per tutti i dispositivi che supportano il patch level 2026-06-05.
Per i dispositivi che non ricevono più aggiornamenti dal produttore, valutare immediatamente l’isolamento o la sostituzione se accedono a risorse critiche.
Per i responsabili della sicurezza (CISO, Security Manager)
Avviare una verifica straordinaria sui log degli ultimi 30-60 giorni per i dispositivi di profili ad alto rischio, con particolare attenzione ai segnali di spyware.
Aggiornare la valutazione del rischio mobile nell’ambito del registro dei rischi NIS2, inserendo CVE-2025-48595 come riferimento per le vulnerabilità in exploitation attiva che hanno richiesto remediation prioritaria.
Per i consulenti che assistono le PMI
Le piccole e medie imprese sono spesso prive di MDM e gestiscono i dispositivi mobili in modo informale.
In questo contesto, la raccomandazione minima è di verificare manualmente il livello di patch su ogni dispositivo aziendale che accede a email, VPN o applicazioni di business e attivare gli aggiornamenti automatici su tutti i dispositivi Android, assicurandosi che la funzione non sia stata disabilitata dall’utente o da policy di rete.
Conclusioni
Il bollettino di sicurezza Android di giugno 2026 non è, preso singolarmente, un evento eccezionale. È la norma: ogni mese Google rilascia decine di patch che coprono vulnerabilità di varia gravità e ogni mese la maggior parte delle organizzazioni aggiorna i propri dispositivi senza che accada nulla di rilevante.
Ma CVE-2025-48595 è un segnale diverso. Uno zero-day con capacità zero-click, in exploitation attiva contro bersagli probabilmente selezionati, è la materializzazione concreta di un rischio che spesso viene percepito come astratto: quello di uno strumento di spionaggio silenzioso installato su un dispositivo aziendale senza che nessuno se ne accorga.
Il patch management per i dispositivi mobili non è un’attività accessoria rispetto a quella per server ed endpoint tradizionali. È parte integrante di una strategia di sicurezza matura ed è un requisito esplicito, non una best practice opzionale, per le organizzazioni soggette a NIS2. Trattarlo come tale è la risposta più efficace a bollettini come questo.
