Android, SMS of Death blocca chiamate e soccorsi senza un clic

🛡️ Executive Summary

• SMS of Death sfrutta un errore nel framework telefonico di Android per interrompere le chiamate tramite un SMS invisibile, senza interazione dell’utente.
• Il ricercatore Mark B ha riprodotto crash persistenti su Android 12–16, con possibili riavvii ripetuti e interruzioni delle comunicazioni di emergenza.
• Google ha introdotto una correzione nell’aggiornamento di ottobre 2026 per Android 14–17, mentre i dispositivi più vecchi possono rimanere esposti.

Una vulnerabilità nel sistema di gestione degli SMS di Android permette di interrompere da remoto le telefonate, comprese quelle verso i servizi di emergenza, senza che la vittima debba aprire un messaggio o compiere alcuna operazione. Il problema, denominato SMS of Death, è stato documentato dal ricercatore Mark B, che ha dimostrato come un singolo messaggio WAP Push malformato possa provocare il crash del processo com.android.phone, responsabile di funzioni essenziali della telefonia. La vulnerabilità interessa il framework Android e può provocare una condizione persistente di denial of service, rendendo il dispositivo temporaneamente o ripetutamente inutilizzabile. Google ha sviluppato una correzione distribuita con gli aggiornamenti di sicurezza di ottobre 2026, ma rimane il problema degli smartphone esclusi dal supporto software.

SMS of Death sfrutta un errore nella gestione degli SMS WAP Push

Il difetto si trova nel componente WapPushOverSms, appartenente al framework telefonico di Android e incaricato di elaborare particolari messaggi dati trasportati attraverso la rete SMS. Nella ricerca originale SMS of Death, divulgata pubblicamente il 29 ottobre 2026 dopo una prima segnalazione effettuata il 5 maggio, Mark B individua il problema nella funzione decodeWapPdu(), che interpreta la lunghezza delle intestazioni WSP attraverso un valore numerico codificato nel formato uintvar. Il valore viene inizialmente letto come intero a 64 bit e successivamente convertito in un intero con segno a 32 bit senza verificare che rientri nell’intervallo ammesso. La conversione può trasformare una lunghezza apparentemente valida in un numero negativo. Quando il programma utilizza questo valore per allocare un array di byte, Java genera una NegativeArraySizeException che, nelle versioni vulnerabili, non viene gestita correttamente. L’eccezione raggiunge il thread di gestione dei messaggi e provoca la terminazione di com.android.phone, interrompendo le funzioni telefoniche mentre Android tenta di riavviare il servizio. La particolarità della vulnerabilità consiste nel fatto che l’elaborazione avviene prima di qualsiasi interazione con l’utente. Il messaggio non compare nella casella SMS e non produce una normale notifica. È quindi sufficiente raggiungere il numero telefonico della vittima attraverso il vettore descritto dal ricercatore, senza installare applicazioni e senza ottenere preventivamente accesso al dispositivo. Il problema riguarda la disponibilità del servizio e non dimostra, di per sé, la possibilità di eseguire codice arbitrario o sottrarre informazioni personali.

Leggi anche: Telegram Android, una chiamata vocale può eseguire codice: patch

Un messaggio invisibile può provocare crash e riavvii persistenti

I test descritti dal ricercatore hanno coinvolto differenti smartphone Google Pixel e Samsung Galaxy, con riproduzione del crash su dispositivi Android 12–16. Il primo effetto è l’interruzione delle chiamate attive, seguita da una temporanea indisponibilità del servizio telefonico, stimata in circa uno o due secondi per messaggio nelle condizioni sperimentali. L’effetto diventa più problematico quando intervengono i meccanismi di ritrasmissione: se il messaggio non viene riconosciuto correttamente come elaborato, può essere nuovamente consegnato dall’operatore e provocare un altro crash.Secondo Mark B, in alcune prove un singolo messaggio ha determinato interruzioni intermittenti protratte fino a una settimana, mentre l’invio ripetuto di circa venti messaggi ha reso il dispositivo inutilizzabile per un periodo prolungato. Questi risultati descrivono le condizioni osservate nei test, non un comportamento necessariamente identico su tutti gli operatori e i modelli Android. Il rischio più significativo emerge quando il messaggio rimane memorizzato nella coda dei messaggi in ingresso e viene elaborato nuovamente dopo ogni riavvio. Una testimonianza tecnica pubblicata nel repository documenta proprio questa situazione su Android 12: il dispositivo continuava a riavviarsi, attivando il meccanismo di protezione RescueParty, mentre il servizio telefonico incontrava ripetutamente lo stesso errore. Il sistema poteva arrivare alla schermata di ripristino con richiesta di cancellazione dei dati, non perché l’attacco avesse necessariamente distrutto le informazioni, ma perché Android non riusciva a interrompere autonomamente il ciclo di crash. Il risultato è un denial of service persistente, più difficile da risolvere rispetto al semplice arresto di un’applicazione.

Google corregge il difetto nel framework Android di ottobre 2026

La correzione sviluppata da Google è documentata nel commit 735d967 del progetto Android, preparato il 15 giugno 2026 e successivamente integrato nel codice. La modifica interviene su due componenti: WapPushOverSms.java, che deve gestire le eccezioni generate durante la decodifica, e InboundSmsHandler.java, responsabile dell’elaborazione dei messaggi in ingresso e della gestione delle relative informazioni temporanee. È particolarmente significativa la scelta implementativa. Il ricercatore aveva proposto di verificare preventivamente la lunghezza dell’intestazione, impedendo che un valore fuori intervallo venisse utilizzato per dimensionare un array. Google ha invece ampliato la gestione delle eccezioni, passando dal trattamento specifico di ArrayIndexOutOfBoundsException a quello più generale di RuntimeException, e ha aggiunto un meccanismo per eliminare dalla coda il messaggio che provoca l’errore. La prima modifica impedisce che l’eccezione interrompa il processo telefonico; la seconda evita che lo stesso contenuto venga continuamente rielaborato, alimentando un ciclo di crash. La patch comprende anche test automatici dedicati alle intestazioni malformate, alle lunghezze incompatibili con il messaggio e alle eccezioni inattese. Secondo la documentazione del ricercatore, la correzione è stata distribuita con il ciclo di sicurezza di ottobre 2026 per Android 14–17. La disponibilità effettiva sui singoli smartphone dipende comunque dai pacchetti rilasciati dai rispettivi produttori. La distinzione è importante: la presenza della modifica nel codice Android non garantisce automaticamente che ogni dispositivo commercializzato abbia già ricevuto l’aggiornamento, come dimostrano anche i precedenti interventi sulle vulnerabilità critiche del framework e del sistema Android.

Le chiamate di emergenza trasformano il bug in un problema di sicurezza pubblica

L’aspetto più delicato di SMS of Death riguarda la possibilità di compromettere l’accesso alle comunicazioni telefoniche durante un’emergenza. I test indicano che il crash di com.android.phone può interrompere anche le chiamate verso i numeri di soccorso. In Australia, dove il numero di emergenza è 000, il ricercatore ha collegato questo scenario agli obblighi di accessibilità previsti dalla normativa sulle telecomunicazioni, sottolineando che la disponibilità delle chiamate di emergenza costituisce una funzione essenziale e non una semplice caratteristica commerciale. Il quadro normativo australiano impone agli operatori specifici interventi nei confronti dei dispositivi che non possono accedere ai servizi di emergenza, soprattutto in seguito alla dismissione delle reti 3G. Tuttavia, non risulta dimostrato che un attacco SMS of Death provochi automaticamente il blocco amministrativo permanente dello smartphone da parte dell’operatore: il malfunzionamento indotto dal messaggio e le procedure regolamentari di esclusione dei terminali sono fenomeni distinti. Per l’Italia, dove il 112 costituisce il numero unico europeo di emergenza, la conseguenza potenziale è comunque rilevante. Uno smartphone sottoposto a crash ripetuti potrebbe non garantire la continuità di una chiamata già avviata o il corretto funzionamento della telefonia durante una situazione critica. Non sono però documentati test specifici sulle reti mobili italiane né incidenti confermati che abbiano coinvolto comunicazioni al 112. Il rischio deve quindi essere considerato tecnicamente plausibile sulla base dei test disponibili, senza trasformarlo nella prova di un’interruzione già avvenuta nei servizi di soccorso nazionali.

Android 12 e 13 rimangono il problema: aggiornamenti e recupero dei dispositivi

La divulgazione pubblica del 29 ottobre arriva dopo la distribuzione della correzione, ma lascia aperta la questione dei dispositivi che utilizzano versioni Android non più comprese nel normale ciclo di aggiornamenti. Android 12 e Android 13 contengono il percorso di codice vulnerabile descritto dal ricercatore e non risultano destinatari della stessa correzione distribuita nel ciclo di ottobre per Android 14–17. L’eventuale protezione dipende quindi dalla presenza di aggiornamenti specifici del produttore, backport o versioni alternative del sistema che abbiano integrato il fix. Per gli utenti la misura principale consiste nel verificare, dalle impostazioni dello smartphone, il livello delle patch di sicurezza Android e installare l’aggiornamento disponibile attraverso i canali ufficiali. Chi utilizza dispositivi aziendali dovrebbe controllare il patch level effettivo dell’intera flotta, prestando particolare attenzione ai terminali più vecchi ancora impiegati per comunicazioni operative, autenticazione e reperibilità. La vulnerabilità non richiede che la vittima utilizzi un’app di messaggistica particolare, perché interessa direttamente un componente del sistema operativo. Il recupero di un dispositivo già entrato nel ciclo di riavvii può richiedere interventi tecnici. Nella segnalazione GitHub relativa ad Android 12, il ricercatore indipendente identificato come sakisdog ha documentato una procedura tramite Android Debug Bridge (ADB) che permette, quando le condizioni di accesso lo consentono, di eliminare selettivamente i messaggi difettosi dalla coda senza ripristinare integralmente lo smartphone. È una soluzione riservata a utenti esperti, che richiede accesso autorizzato al dispositivo e non rappresenta una procedura universale.

Continua con:

Google stringe la sicurezza Android: zero-click Pixel sfruttata e recupero account col volto

WeWorm prende il controllo di WeChat con una chiamata zero-click su iPhone e Android

La disponibilità pubblica di una proof of concept funzionante aumenta la necessità di aggiornare i dispositivi ancora esposti, pur in assenza di prove di campagne criminali reali attribuite a questa vulnerabilità. SMS of Death dimostra soprattutto quanto un errore apparentemente circoscritto nella gestione delle dimensioni di un messaggio possa compromettere una funzione fondamentale dello smartphone. Non servono necessariamente spyware sofisticati, privilegi amministrativi o una compromissione completa del sistema: quando il difetto interessa direttamente la telefonia, anche un denial of service può trasformarsi in un problema concreto di sicurezza personale e continuità delle comunicazioni.