La vulnerabilidad «SMS of Death» en Android puede interrumpir llamadas y provocar fallos repetidos en los teléfonos

Un mensaje invisible puede interrumpir una llamada telefónica

Un mensaje de texto diseñado especialmente, de solo ocho bytes, puede bloquear el servicio de llamadas en teléfonos Android vulnerables, interrumpir llamadas en curso y, si se envía repetidamente, hacer que el dispositivo tenga dificultades para iniciarse con normalidad. El investigador de seguridad Mark Blaszczyk reveló la vulnerabilidad el 29 de octubre de 2026, después de informar por primera vez a Google el 5 de mayo.

La vulnerabilidad, descrita como SMS of Death e identificada en publicaciones sobre seguridad como CVE-2026-58882, afecta al software que procesa ciertos mensajes entrantes antes de que lleguen a una aplicación de mensajería. El destinatario no tiene que abrir nada, instalar una aplicación ni pulsar un enlace. Según Blaszczyk, el mensaje malicioso no aparece en la bandeja de entrada ni genera una notificación.

Blaszczyk reprodujo el problema en un Google Pixel 9 con el firmware de abril de 2026 y en varios teléfonos Samsung Galaxy, incluidos modelos de la serie Galaxy A. Informó que pudo reproducirlo en todas las pruebas realizadas con esos dispositivos. Un solo mensaje interrumpió el servicio celular durante aproximadamente uno o dos segundos mientras Android reiniciaba el proceso de llamadas.

Blaszczyk, investigador de seguridad independiente, describió el efecto inmediato en el proceso de Android responsable de las funciones telefónicas:

«Un solo SMS WAP Push malformado bloquea com.android.phone en Android e interrumpe las llamadas en curso (incluidas las llamadas de emergencia), sin que la víctima tenga que hacer nada»,

No se han informado ataques fuera de entornos de prueba, y la advertencia sobre posibles interferencias con los servicios de emergencia se basa en la evaluación del investigador. No se ha publicado una lista completa de los teléfonos, las redes de operadores y los países afectados. La preocupación práctica es que una interrupción breve puede cortar una conversación, mientras que las interrupciones repetidas pueden impedir que alguien mantenga una conexión cuando necesita ayuda.

Por qué el mensaje nunca llega a la bandeja de entrada

Android recibe el contenido malicioso mediante WAP Push, un mecanismo antiguo que se usa para enviar datos e instrucciones a través de redes móviles. Entre sus usos legítimos están pedir al teléfono que recupere un mensaje multimedia o aplique los ajustes del operador. A diferencia de un mensaje de texto corriente escrito para que lo lea una persona, este tipo de mensaje se procesa automáticamente mediante el software del sistema.

El componente WapPushOverSms de Android se encarga de ese procesamiento. El fallo se produce en su función de decodificación, cuando el teléfono lee información que indica la longitud de una parte del mensaje. Como el servicio de llamadas encuentra el error antes de que termine el procesamiento habitual, el destinatario no tiene ningún texto visible que pueda revisar o eliminar.

Por eso, el ataque evita el momento en que normalmente las personas deciden si un mensaje parece sospechoso. Ignorar a remitentes desconocidos o negarse a abrir enlaces sirve de poco ante un fallo que se activa durante el procesamiento automático. La protección depende principalmente de corregir el componente del sistema operativo que gestiona el mensaje.

Un número grande se convierte en una longitud negativa

Blaszczyk atribuyó el bloqueo a un error de conversión numérica. Android lee la longitud de la cabecera de un mensaje con un tipo de dato capaz de guardar números grandes y luego convierte ese valor en un entero con signo de 32 bits sin comprobar antes si cabe en ese formato.

En la prueba descrita, el valor 2.147.483.648 se convierte en -2.147.483.648. Un entero con signo de ese tamaño puede representar números positivos solo hasta 2.147.483.647. El valor diseñado para el ataque supera ese límite por poco.

Después, Android intenta reservar espacio para un bloque de datos usando esa longitud negativa. Como una longitud negativa no tiene sentido para esa operación, el software genera un error llamado NegativeArraySizeException. Al no gestionar correctamente el error, el sistema termina com.android.phone.

El mensaje de ocho bytes contiene una secuencia de cinco bytes que proporciona la información problemática sobre la longitud. Su reducido tamaño ayuda a explicar la gravedad del fallo: un mensaje entrante diminuto puede causar una interrupción mucho mayor al provocar un fallo en un proceso central del sistema mientras lo interpreta.

Cómo una interrupción breve se convierte en un fallo recurrente

Por lo general, los operadores móviles esperan que un teléfono confirme la recepción de un mensaje. Si Android se bloquea antes de completar ese intercambio, el operador puede intentar entregarlo de nuevo. Así, un mecanismo pensado para que los mensajes de texto lleguen de manera fiable puede enviar otra vez al teléfono el mismo contenido dañino.

Android también mantiene los mensajes entrantes en una cola de espera mientras los procesa. Blaszczyk dijo que un mensaje malformado puede permanecer allí y volver a procesarse después de un reinicio, lo que crea otra oportunidad para que se produzca el mismo fallo.

Blaszczyk explicó por qué reiniciar el dispositivo puede no poner fin al problema:

«El mensaje malformado permanece en la cola y se vuelve a intentar procesar con cada inicio, por lo que el teléfono puede fallar al arrancar hasta que se elimine»,

Blaszczyk advirtió que unos 20 mensajes podrían dejar un dispositivo inutilizable durante un periodo prolongado. En las pruebas también se describió la llegada rápida de unos 30 mensajes antes de que aparecieran fallos más persistentes. Estas cifras corresponden a las condiciones de las pruebas, no a un umbral exacto que todos los teléfonos alcanzarían.

El investigador atribuyó algunos fallos duraderos a daños en la base de datos SQLite que se usa para almacenar los datos de los SMS entrantes. SQLite es un pequeño sistema de bases de datos que las aplicaciones y los sistemas operativos utilizan para guardar registros estructurados. Si los registros necesarios durante el inicio provocan repetidamente un fallo, el servicio de llamadas puede bloquearse cada vez que el teléfono intenta recuperarse.

Durante las pruebas, los reintentos de entrega del operador causaron problemas intermitentes con las llamadas durante un máximo de una semana, incluida una interrupción atribuida a un solo mensaje malicioso. La combinación de los mensajes que mantiene el operador y los registros almacenados en el teléfono ayuda a explicar por qué los efectos pueden prolongarse más allá de la entrega inicial.

Por qué la pantalla de recuperación puede implicar la pérdida de datos

Android incluye un mecanismo de recuperación automática llamado RescueParty. Cuando un componente crítico falla repetidamente, intenta recuperarlo y puede llevar el teléfono al modo de recuperación después de unos 90 segundos. Entonces, los usuarios pueden encontrar una opción para borrar sus datos.

Restablecer el teléfono a la configuración de fábrica borra los datos y los ajustes locales. Blaszczyk informó que, durante las pruebas, el restablecimiento solo ofreció un alivio temporal, porque el operador podía volver a entregar más tarde los mensajes que seguían pendientes de confirmación. Por tanto, quien opte por borrar el teléfono podría perder información personal y volver a sufrir fallos.

Blaszczyk describió un procedimiento de recuperación mediante Android Debug Bridge, o ADB, una herramienta que permite a una computadora comunicarse con un dispositivo Android para tareas de desarrollo y mantenimiento. El procedimiento consistía en borrar los registros SMS afectados durante un breve periodo en que se podía acceder al teléfono.

La recuperación mediante ADB requiere acceso técnico, y muchos propietarios no habrán configurado previamente la conexión necesaria. El método descrito por el investigador también implicaba trasladar una tarjeta SIM física a un teléfono que no utilizara Android para que se pudieran recibir y confirmar los mensajes pendientes. Advirtió que la recuperación podría ser más difícil si la suscripción móvil utiliza una eSIM.

Ante fallos repetidos, la prioridad concreta es buscar asistencia técnica cualificada antes de seleccionar la opción para borrar los datos. El procedimiento de recuperación descrito implica modificar registros del sistema y ajustes de acceso, por lo que es más complejo que eliminar un mensaje de texto normal.

¿Qué versiones de Android requieren atención?

El principal rango de versiones afectadas que describen los informes técnicos es de Android 12 a Android 16. Algunos informes amplían el alcance hasta Android 17. En las pruebas se mencionaron específicamente dispositivos Pixel y Samsung Galaxy, aunque se sospecha que el problema podría afectar a más teléfonos porque se encuentra en código de telefonía compartido de Android.

La corrección de octubre de 2026 mencionada en los informes cubre Android 14 a Android 17. Los teléfonos que todavía usan Android 12 o Android 13 son el motivo de preocupación más claro en cuanto al soporte: según los informes, esas versiones ya no reciben soporte de seguridad de Google, por lo que sus propietarios dependen de que el fabricante u otro proveedor del sistema operativo publique una corrección.

La versión de Android de un teléfono y el estado de sus actualizaciones de seguridad responden a preguntas diferentes. La versión indica la generación del sistema operativo. La información sobre las actualizaciones de seguridad ayuda a saber cuándo se corrigieron sus vulnerabilidades más recientemente. Dos teléfonos con la misma versión de Android pueden recibir las correcciones en momentos distintos.

Los fabricantes y los operadores influyen en cuándo llegan las actualizaciones a cada modelo. Los propietarios deben revisar la fecha de la actualización de seguridad en Ajustes, generalmente en Información del teléfono, Seguridad o Actualizaciones de software, e instalar la actualización más reciente disponible. Para este fallo, la corrección mencionada está asociada con la actualización de octubre de 2026, aunque es útil consultar la confirmación del fabricante para cada modelo cuando no esté claro cuándo se publicará.

La corrección siguió un camino distinto al de la denuncia

Blaszczyk dijo que, al principio, Google clasificó su denuncia como un problema ajeno a la seguridad y la cerró sin aceptar la medida que él solicitaba. En su relato publicado, describió nuevas apelaciones y una nueva clasificación como asunto no relacionado con la seguridad el 29 de octubre. Mientras tanto, los ingenieros de Android habían estado desarrollando una corrección.

La secuencia descrita distingue entre la gestión de la denuncia del investigador y la incorporación del código a los sistemas de desarrollo y actualización de Android:

• 5 de mayo de 2026: Blaszczyk informó por primera vez de la vulnerabilidad a Google.
• 15 de junio: Google creó una corrección de ingeniería para el fallo en el procesamiento del mensaje.
• Julio: GrapheneOS dijo que recibió el parche mediante versiones preliminares de seguridad y lo implementó ese mes.
• 5 de agosto: Según los informes, la corrección se incorporó al proceso de desarrollo de Google.
• Octubre: El cambio se hizo público en el Proyecto de Código Abierto de Android y se incluyó en las actualizaciones para Android 14 a Android 17.
• 29 de octubre: Blaszczyk publicó sus hallazgos.
• Noviembre: GrapheneOS dijo que se esperaba incluir la vulnerabilidad en el boletín de seguridad de Android.

GrapheneOS planteó que un problema de comunicación interna podría explicar cómo gestionó Google la denuncia. Esa explicación fue una especulación de los desarrolladores del proyecto del sistema operativo. El historial descrito aquí incluye tanto una denuncia rechazada como un cambio de ingeniería destinado a impedir el fallo.

El boletín de noviembre era el siguiente hito de publicación anunciado. GrapheneOS dijo que ya había implementado la corrección en julio; por tanto, la fecha posterior del boletín se refería a la documentación pública de seguridad, no a la primera implementación del parche.

Qué cambia con la corrección

Según los informes, la solución de Google amplía la gestión de excepciones para que Android detecte el error de ejecución y elimine de la cola de espera el mensaje malformado. Así, el procesamiento puede continuar después del registro dañino en lugar de bloquearse repetidamente al encontrarlo.

Blaszczyk había propuesto comprobar si la longitud declarada de la cabecera era válida antes de convertirla. Según los informes, el enfoque de ingeniería adoptado gestiona el fallo y elimina el mensaje que lo provoca. En la práctica, borrar ese registro también resuelve el procesamiento repetido que puede convertir una sola entrega en un problema continuado del servicio.

La corrección está diseñada para actuar cuando encuentra un mensaje malformado. Los aproximadamente 20 mensajes mencionados en las pruebas se refieren a la gravedad de las interrupciones repetidas, no a una cantidad que la solución tenga que esperar para empezar a funcionar.

Que una corrección aparezca en el Proyecto de Código Abierto de Android significa que el código subyacente está disponible para incorporarse al software de Android. Su llegada al teléfono de cada propietario sigue dependiendo de que se prepare y distribuya una actualización adecuada para ese dispositivo. Por eso, además de saber que Google corrigió el código, es importante comprobar el estado de soporte de cada modelo.

Qué pueden hacer ahora los propietarios

Los propietarios de teléfonos con soporte deben instalar la última actualización de seguridad del sistema y consultar las notas de publicación o la información de soporte del fabricante para confirmar que incluye la corrección. Quienes usen Android 12 o Android 13 deben preguntar si su modelo recibirá un parche o se podrá actualizar a una versión de Android con soporte.

Blaszczyk publicó una aplicación de demostración y su código fuente, lo que hace más urgente distribuir el parche cuanto antes. Su publicación incluye una advertencia contra atacar a otras personas, especialmente porque las interferencias con las comunicaciones de emergencia pueden crear un peligro grave.

Los usuarios cuyos teléfonos pierdan repetidamente el servicio celular o se reinicien deben ponerse en contacto con el fabricante del dispositivo o con un servicio técnico cualificado. Si aparece una pantalla de recuperación, es necesario actuar con cuidado cuando se quieren preservar los datos. Quienes necesiten asistencia urgente mientras su teléfono no pueda mantener una llamada deben usar otro teléfono que funcione.

El cambio principal para los propietarios es sencillo: este fallo se produce antes de que haya un mensaje sospechoso que evaluar. En los dispositivos con soporte, la protección más práctica descrita es contar con una actualización de seguridad reciente, distribuida para el teléfono que se esté utilizando.

Puntos clave

• Un SMS WAP Push malformado puede bloquear el servicio de llamadas de Android sin que el destinatario tenga que hacer nada.
• Blaszczyk reprodujo el fallo en un Pixel 9 y en dispositivos Samsung Galaxy; las interrupciones individuales duraron aproximadamente uno o dos segundos.
• El procesamiento repetido y los reintentos de entrega del operador pueden provocar interrupciones prolongadas, fallos repetidos y pantallas de recuperación.
• La corrección de octubre de 2026 mencionada en los informes cubre Android 14 a Android 17. Los propietarios de teléfonos con Android 12 o Android 13 dependen de que los proveedores de sus dispositivos les ofrezcan más soporte.
• No se han informado ataques fuera de las pruebas. El investigador advirtió que las interrupciones de las llamadas podrían afectar al acceso a los servicios de emergencia.
• Restablecer el teléfono a la configuración de fábrica borra los datos y puede ir seguido de nuevos intentos de entrega de mensajes dañinos. La recuperación técnica puede requerir ADB.