JC Rueda
Ciberseguridad · Aviso

Google Android (telefonía, AOSP) · Caída remota de la telefonía con un SMS, sin interacción

Un investigador independiente ha publicado un fallo en el manejo de mensajes WAP Push de Android que permite cortar a distancia la telefonía de un móvil con solo conocer su número. Según su relato, Google se ha negado a corregirlo.

Publicado Lectura 8 min Ref. Sin CVE CVSS —

Resumen

El 29 de octubre de 2026 el investigador Mark Blaszczyk publicó «SMS of Death». Es un fallo en el componente WapPushOverSms de la pila de telefonía de Android: un SMS de datos malformado hace que se cierre el proceso com.android.phone, sin que la víctima haga nada ni vea mensaje alguno.

Cada mensaje provoca un corte de servicio de 1-2 segundos y cuelga las llamadas activas. El investigador asegura que, si se envían muchos mensajes seguidos, el móvil puede quedar sin telefonía de forma persistente. Según su cronología, Google lo ha clasificado como «no relacionado con la seguridad» y no lo corregirá, por lo que no hay parche ni CVE. No consta explotación activa.

Materias: Android, Telefonía móvil, Denegación de servicio, Zero-click, SMS, Divulgación de vulnerabilidades, Servicios de emergencia

Basta un SMS que el destinatario nunca llega a ver. Según el investigador australiano Mark Blaszczyk, un mensaje WAP Push mal construido hace que se cierre el proceso que gestiona la telefonía en Android. El móvil se queda sin cobertura durante unos segundos y se cortan las llamadas en curso, también las de emergencia. Si los mensajes se repiten, el teléfono puede quedar inutilizado. Google, siempre según el investigador, considera que no es un problema de seguridad y no publicará parche.

Descripción

Qué es

Es una denegación de servicio (DoS: un ataque que no roba datos ni toma el control del dispositivo, pero impide que funcione) que se activa de forma remota y sin interacción (zero-click: la víctima no tiene que abrir, pulsar ni aceptar nada). El vector es un SMS WAP Push. Se trata de un tipo de SMS «de datos», pensado originalmente para enviar configuraciones o avisos de MMS al teléfono, que no aparece en la bandeja de mensajes. Va dirigido al puerto WAP 2948.

El fallo está en la clase WapPushOverSms del marco de telefonía de Android (frameworks/opt/telephony, en el código abierto AOSP). Al cerrarse, se reinicia el proceso del sistema com.android.phone, que gestiona llamadas, SMS y conexión a la red móvil.

A quién afecta

  • Confirmado de forma independiente: hemos revisado la rama principal del código fuente público de AOSP. El fragmento señalado sigue presente: el tamaño de la cabecera se convierte de long a int sin comprobar el signo y después se usa para reservar memoria. El bloque de captura de errores de esa función solo cubre ArrayIndexOutOfBoundsException, no NegativeArraySizeException.
  • Según el investigador (sin verificación independiente): lo reprodujo en todos sus intentos en un Pixel 9 con el firmware de abril de 2026 y en varios Samsung Galaxy (incluida la serie A). Como el código procede de AOSP, es razonable pensar que afecta a la mayoría de versiones y fabricantes que no hayan modificado ese componente, pero no se ha publicado una lista oficial de versiones afectadas.
  • No hay versión corregida. No hay CVE asignado ni aviso de Google, y el fallo no aparece en los boletines de seguridad de Android.

Clasificación técnica orientativa (no oficial): CWE-681 (conversión incorrecta entre tipos numéricos), con CWE-20 (validación de entrada insuficiente) como causa relacionada.

Mecánica

El fallo: un número que se vuelve negativo

Cuando llega un WAP Push, la función decodeWapPdu() lee de la cabecera del mensaje un campo de longitud. Ese campo está codificado como uintvar, un entero sin signo de longitud variable, y la función lo obtiene como un número de 64 bits (long). Después lo convierte a un entero de 32 bits con signo (int) sin comprobar su rango:

int headerLength = (int) pduDecoder.getValue32();
...
byte[] header = new byte[headerLength];

Si el atacante pone en ese campo un valor de 231 o más, la conversión lo transforma en un número negativo. Al intentar crear una tabla de tamaño negativo, Java lanza una NegativeArraySizeException. Nadie captura esa excepción, así que el proceso com.android.phone se cierra y el sistema lo reinicia.

Requisitos y efectos

  • Requisitos del atacante: conocer el número de teléfono de la víctima y poder enviar SMS de datos. El investigador ha publicado una aplicación de prueba de concepto que lo hace desde otro Android.
  • Efecto de un mensaje: el móvil se queda sin servicio 1-2 segundos y se cortan las llamadas activas, también las de emergencia. El mensaje no aparece en la aplicación de Mensajes ni se ve el remitente.
  • Reenvío por el operador: como el teléfono se cierra antes de confirmar la recepción, la red puede volver a entregar el mensaje. El investigador dice haber sufrido cortes intermitentes durante hasta una semana por un solo envío. Esto depende de cómo gestione los reintentos cada operador.
  • Efecto persistente (según el investigador): con unos 20-30 mensajes seguidos, los cierres coinciden con las escrituras en la base de datos SQLite donde se guardan los SMS y pueden corromperla. A partir de ahí el proceso de telefonía falla en cada arranque. El investigador describe que el restablecimiento de fábrica solo ayudó temporalmente. Para recuperarse tuvo que pasar la SIM física a un dispositivo que no fuera Android, para que el operador diera los mensajes por entregados, y después borrar los registros con ADB, la herramienta de depuración de Android. Con eSIM sería más difícil. Este escenario persistente no se ha verificado de forma independiente.

El fallo no permite ejecutar código, leer datos ni tomar el control del terminal. Su impacto es la disponibilidad, aunque en la función más sensible del teléfono: poder llamar.

Respuesta del creador

Google

Google no ha publicado ningún comunicado ni aviso. Todo lo que se sabe de su postura procede de la cronología del investigador, que no hemos podido contrastar porque los tickets del Issue Tracker no son públicos:

  • 5 de mayo de 2026: el investigador comunica el fallo a través del programa de recompensas de Android y Google Devices (ticket 509520497) y propone una corrección.
  • 20 de junio de 2026: Google lo cierra como «Won't Fix (Infeasible)» porque no sería una vulnerabilidad de seguridad. Las dos apelaciones posteriores se cierran como «no reproducible» y «duplicado».
  • Julio de 2026: el caso se reabre y se revisa de nuevo («4 engineers will have evaluated the report»).
  • 29 de octubre de 2026: decisión final. Google mantiene «Won't Fix» y lo considera un Non-Security Issue (NSI) que «no alcanza el umbral de gravedad». Ese mismo día el investigador lo publica todo.

Las propias directrices de gravedad de Android distinguen tres casos. La denegación de servicio remota temporal (un cuelgue o reinicio) es de gravedad Moderada. La que deja sin servicio celular hasta que intervenga el usuario es Alta. La persistente que exige restablecer de fábrica es Crítica. El investigador sostiene que su caso encaja en las categorías superiores. Google, por lo visto, no aceptó que el escenario persistente quedara acreditado o que tuviera esa gravedad. La discrepancia sigue abierta y solo conocemos la versión de una de las partes.

Autoridades y terceros

No consta en el catálogo KEV de CISA (vulnerabilidades explotadas activamente), ni en NVD, ni en avisos de INCIBE-CERT. Tampoco hemos encontrado declaraciones de operadores ni de otros fabricantes como Samsung. El investigador menciona la normativa australiana de llamadas de emergencia (ACMA), que obliga a los operadores a bloquear terminales que no pueden llamar al 000, y la presenta como agravante. Es una interpretación suya, no una postura de los reguladores. No hay noticias de explotación en ataques reales.

Parches y mitigaciones

Estado de la corrección

  • No hay parche publicado ni previsto por Google. No hay versión corregida de Android ni CVE.
  • El investigador propone una corrección de una línea: comprobar que el valor leído no es negativo ni mayor que el propio mensaje antes de convertirlo, y devolver un error en ese caso. Los fabricantes (Samsung, Xiaomi, etc.) o las distribuciones derivadas de AOSP podrían aplicarla por su cuenta. No consta que ninguno lo haya hecho.

Mitigaciones posibles

  • Operadores de telefonía: son los que mejor pueden contenerlo a corto plazo, filtrando en red (con cortafuegos de SMS) los WAP Push dirigidos al puerto 2948 con cabeceras de longitud imposibles. No consta que ningún operador lo haya anunciado.
  • Usuarios: Android no ofrece un ajuste general para bloquear los WAP Push entrantes, así que no hay una mitigación real del lado del usuario. Si el teléfono pierde la cobertura de forma repetida o cuelga llamadas sin motivo, contacte con su operador. Ante una emergencia, tenga a mano otra vía de llamada: otro terminal, un fijo o un dispositivo que no sea Android.
  • Empresas con flotas Android (MDM): vigilen los cierres de com.android.phone en los registros y las incidencias de cobertura. Pidan a su operador y a su fabricante su posición por escrito.
  • Recuperación (según el investigador): si el terminal no se recupera tras reiniciarlo, puede ser necesario mover la SIM física a un dispositivo que no sea Android para que el operador deje de reenviar el mensaje y, después, limpiar la base de datos de SMS. Hágalo con apoyo técnico.

Nota legal

Hay una prueba de concepto pública, lo que facilita el uso indebido. Utilizarla contra terminales ajenos sin autorización puede constituir un delito. En España podría encajar, entre otros, en el art. 264 bis del Código Penal, que castiga la obstaculización grave de sistemas informáticos ajenos, y en los delitos que protegen el acceso a los servicios de emergencia.

Fuentes