SMS of Death: denegación de servicio Android sin interacción (CVE-2026-58882)

TL;DR

• Un SMS WAP Push malformado provoca el fallo del proceso de telefonía de Android y corta cualquier llamada en curso, incluidas las llamadas a servicios de emergencia, sin ningún toque ni mensaje visible. El investigador Mark B lo divulgó con una prueba de concepto funcional el 29 de octubre de 2026.
• La falla se reproduce desde Android 12 hasta Android 16, y Google publicó la corrección solo para Android 14 a 17, en la actualización de seguridad de octubre de 2026. Los dispositivos con Android 12 y 13, el 18 por ciento del tráfico web Android mundial en octubre de 2026, no reciben corrección.
• El impacto es una denegación de servicio, no una ejecución de código: el teléfono falla, se reinicia y puede entrar en un bucle que termina en un restablecimiento de fábrica. BleepingComputer informa del identificador CVE-2026-58882; los registros CVE públicos no lo incluían al 2 de noviembre de 2026, y la falla no está en el catálogo KEV de CISA a esa misma fecha.
• Actualice todo dispositivo compatible al nivel de parche de octubre de 2026 o posterior. En Android 12 y 13 no existe parche; planifique el reemplazo o la retirada de los dispositivos que no puedan salir de esas versiones.

¿Está afectado?

Está expuesto cuando se cumplen todas estas condiciones:

• El dispositivo ejecuta Android 12 a Android 17. El investigador reprodujo el fallo desde Android 12 hasta Android 16 en un Pixel 9 y varios modelos Samsung, y el código afectado se incluye en cada una de esas versiones.
• El dispositivo no ha recibido la actualización de seguridad de octubre de 2026. La corrección de Google cubre Android 14 a 17; los dispositivos con el nivel de parche de octubre de 2026 o posterior están protegidos.
• El atacante conoce, o puede adivinar, el número del objetivo. No se necesita nada más: ninguna aplicación instalada, ninguna interacción y ningún acceso previo.

El investigador informa de que el fallo se reproduce en el 100 por ciento de los dispositivos probados. Android 12 y 13 representaban el 18.01 por ciento del tráfico web Android mundial en octubre de 2026, y esos dispositivos ejecutan el mismo código de telefonía sin ruta de parche.

Compruebe la versión de Android y el nivel de parche de seguridad de cada dispositivo gestionado:

adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.security_patch

El primer comando muestra la versión de Android, por ejemplo 14. El segundo muestra la fecha del parche, por ejemplo 2026-10-08; cualquier fecha del 2026-10-01 o posterior significa que la actualización de octubre llegó al dispositivo.

¿Cómo corregirlo?

Actualice todo dispositivo con Android 14 a 17 al nivel de parche de octubre de 2026 o posterior:

1. Abra Configuración, luego Seguridad y privacidad, y busque la actualización de seguridad de octubre de 2026; instálela y reinicie el teléfono.
2. Verifique que el dispositivo lleva la corrección: adb shell getprop ro.build.version.security_patch debe mostrar una fecha del 2026-10-01 o posterior. La disponibilidad depende del fabricante y del operador, y puede hacer falta un reinicio para terminar la instalación.
3. Vuelva a comprobar el inventario: todo dispositivo con Android 12 o 13 no tiene ruta de parche, y todo nivel de parche anterior a octubre de 2026 sigue siendo vulnerable.

No existe solución alternativa para los dispositivos sin parchear. El mensaje se procesa antes de llegar a cualquier bandeja visible, así que ninguna aplicación de bloqueo de SMS, ningún cambio de permiso y ningún hábito de modo avión lo detiene. Para los dispositivos ya afectados, los pasos de recuperación de «¿Cómo sé si fui comprometido?» borran los mensajes envenenados mediante ADB; no impiden los nuevos.

¿Cuál es la causa raíz?

Una longitud de cabecera WSP llega como un valor de 64 bits y se convierte a un entero de 32 bits con signo sin ninguna comprobación de rango. El valor truncado sirve después como tamaño de un arreglo. La falla está en decodeWapPdu de WapPushOverSms, el componente que convierte los mensajes cortos WAP Push entrantes en intents de Android, en la parte frameworks/opt/telephony de la plataforma.

La decodificación lee la longitud de cabecera como un uintvar, un entero del protocolo WSP de como máximo 5 bytes, y lo recibe como un long de Java:

// WapPushOverSms.java:217  header length read as long, cast with no bounds check
int headerLength = (int) pduDecoder.getValue32();

Más adelante, el mismo valor dimensiona el búfer de cabecera:

// WapPushOverSms.java:244  the cast value is used as an array size
byte[] header = new byte[headerLength];

Un mensaje manipulado declara un uintvar de 5 bytes con valor 88 80 80 80 00, que se decodifica como el long 2147483648. Convertido a un int de 32 bits con signo, eso es -2147483648. Asignar new byte[-2147483648] lanza una NegativeArraySizeException en el hilo principal de telefonía, y el proceso muere:

E AndroidRuntime: FATAL EXCEPTION: main
E AndroidRuntime: Process: com.android.phone
E AndroidRuntime: java.lang.NegativeArraySizeException: -2147483648
E AndroidRuntime:   at ...WapPushOverSms.decodeWapPdu(WapPushOverSms.java:244)

El código anterior a la corrección solo capturaba ArrayIndexOutOfBoundsException alrededor de esta decodificación, de modo que la NegativeArraySizeException escapaba y mataba com.android.phone, el proceso que gestiona las llamadas, la conexión con el módem y los SMS.

¿Cómo se explota?

La prueba de concepto es pública, con código fuente y una aplicación instalable, y todo el ataque es un mensaje corto:

1. El atacante envía un data SMS, no un mensaje de texto, al puerto 2948 del objetivo, el puerto WAP Push. La carga útil son 8 bytes: 01 06 88 80 80 80 00 BE, un identificador de transacción, un tipo de PDU push, la longitud de cabecera envenenada y un tipo de contenido.
2. Android entrega el mensaje a la pila de telefonía antes de cualquier bandeja visible. InboundSmsHandler.processMessagePart lo pasa a WapPushOverSms.decodeWapPdu, que interpreta la longitud de cabecera uintvar como 2147483648 y la convierte en -2147483648.
3. La asignación new byte[-2147483648] lanza una excepción en el hilo principal de telefonía. com.android.phone falla, y toda llamada en curso termina con la causa de desconexión CS_DEATH.
4. Android reinicia el proceso de telefonía, lo que cuesta de 1 a 2 segundos sin servicio. Como el SMS nunca fue reconocido, el operador lo reenvía y el fallo se repite. El investigador midió cortes intermitentes durante hasta una semana con un solo mensaje.
5. El mensaje envenenado permanece en cola en la base de datos bruta de SMS, así que se reintenta en cada arranque. Unos 20 mensajes dejaron los dispositivos de prueba inutilizables durante períodos prolongados; un dispositivo con Android 12 entró en un ciclo de reinicio en recuperación cada 90 segundos aproximadamente que terminó en un restablecimiento de fábrica.

La aplicación de prueba de concepto en GitHub envía el mensaje manipulado desde un segundo teléfono Android. El investigador la publicó con la advertencia de que es un arma funcional y limitó su licencia a pruebas autorizadas.

¿Cómo fluye el ataque?

Un único data SMS de 8 bytes al puerto 2948 provoca el fallo de la telefonía mediante la conversión sin comprobación, y el mensaje en cola hace que el fallo vuelva.

¿Qué puede hacer un atacante?

El impacto demostrado es una denegación persistente del servicio celular del teléfono, y nada en la divulgación afirma una ejecución de código:

• Toda llamada en curso se corta cuando muere el proceso, incluida una llamada a servicios de emergencia, y el teléfono no puede realizar llamadas de forma fiable mientras dura el ataque o el bucle resultante.
• Cada fallo cuesta de 1 a 2 segundos de apagón telefónico. La reentrega del operador convierte un mensaje en fallos repetidos; un solo mensaje mantuvo un dispositivo de prueba fallando de forma intermitente durante una semana.
• Unos 20 mensajes dejaron dispositivos inutilizables, y en un Android 12 los mensajes en cola provocaron un bucle de reinicio en recuperación cada 90 segundos. La recuperación documentada por el investigador exigía un procedimiento de limpieza ADB o un restablecimiento de fábrica completo.
• La víctima no ve nada: el data SMS nunca aparece en Mensajes y el número del remitente nunca se muestra, lo que también dificulta la atribución posterior del ataque.

Las condiciones son mínimas: el atacante solo necesita el número de teléfono. No se requiere aplicación, permiso, interacción ni posición de red.

¿Por qué funciona la corrección?

La corrección de Google es el commit 735d9672603fa206c4b43cb668c1aa273db70b97, «Fix remote DoS in decodeWapPdu», escrito el 15 de junio de 2026 y publicado en la actualización de seguridad de octubre de 2026. No añade la comprobación de rango que propuso el investigador; impide que el fallo sea mortal y que el mensaje lo sobreviva:

// WapPushOverSms.java: widen the catch to cover NegativeArraySizeException
-        } catch (ArrayIndexOutOfBoundsException aie) {
+        } catch (RuntimeException e) {

// InboundSmsHandler.java: a failed decode now deletes the poison message
-                    if (processMessagePart(inboundSmsTracker)) {
+                    boolean success = false;
+                    if (inboundSmsTracker != null) {
+                        try {
+                            success = processMessagePart(inboundSmsTracker);
+                        } catch (RuntimeException e) {
+                            loge("Exception delivering message part", e);
+                            deleteFromRawTable(inboundSmsTracker.getDeleteWhere(),
+                                    inboundSmsTracker.getDeleteWhereArgs(), MARK_DELETED);
+                        }
+                    }

NegativeArraySizeException es una RuntimeException, de modo que el catch ampliado absorbe el fallo de asignación y marca el mensaje como error genérico. El cambio complementario en InboundSmsHandler borra el mensaje de la base bruta cuando la entrega lanza una excepción, lo que rompe tanto el bucle de reentrega del operador como el bucle de reintento en el arranque. El commit lleva la marca EXEMPT CVE_FIX de Google y añade pruebas para una longitud de cabecera de 4294967295.

La corrección estrecha el problema en lugar de eliminar su causa. La conversión sin comprobación permanece en el código, y la cabecera malformada se rechaza río abajo en lugar de validarse en el análisis. Eso basta para detener el fallo en Android 14 a 17, y deja la misma conversión sin parchear en Android 12 y 13.

¿Cómo sé si fui comprometido?

Un ataque que no se completó puede no dejar rastro, y uno exitoso deja un teléfono que no para de fallar. Las señales de la propia falla son inequívocas:

adb logcat -d | grep -i "NegativeArraySizeException"

Una aparición de NegativeArraySizeException: -2147483648 bajo com.android.phone es la firma de este fallo de decodificación. Los mensajes envenenados están en la base bruta de SMS, que ninguna aplicación normal de SMS muestra. Liste las filas WAP Push y sus remitentes:

adb shell content query --uri content://sms/raw --projection _id:address:destination_port:date:deleted

Las filas con destination_port=134020, la codificación del puerto WAP Push 2948 en la base bruta, de remitentes que no puede justificar son los mensajes que hay que borrar. La recuperación siguiente fue aportada por @sakisdog y documentada en el repositorio de la prueba de concepto; debe ejecutarse en la ventana tras el arranque del teléfono:

adb shell cmd appops set com.android.shell WRITE_SMS allow
adb shell "content delete --uri content://sms/raw --where \"address='<SENDER>'\""
adb shell cmd appops set com.android.shell WRITE_SMS default

Sustituya <SENDER> por la dirección de la consulta anterior. Si el bucle no se puede romper, el último recurso borra todos los SMS y MMS y restablece los ajustes de APN: adb shell pm clear com.android.providers.telephony. No elija «wipe data» en el aviso de recuperación salvo que quiera un restablecimiento de fábrica.

Cronología

• 2026-05-05: Mark B informa de la falla al programa de recompensas por vulnerabilidades de Android y dispositivos de Google.
• 2026-06-15: un ingeniero de Android escribe la corrección 735d9672603fa206c4b43cb668c1aa273db70b97 en el marco de telefonía.
• 2026-10-01: Google publica el boletín de seguridad de octubre de 2026, cuyos niveles de parche son 2026-10-01 y 2026-10-08. La corrección llega para Android 14 a 17 con esta actualización; la falla no figura en el boletín.
• 2026-10-29: Mark B publica el análisis técnico, la aplicación de prueba de concepto y su código fuente, y @sakisdog documenta la recuperación por ADB.
• 2026-11-02: los registros CVE públicos todavía no incluyen el identificador informado CVE-2026-58882, y la falla no está en el catálogo KEV de CISA.

FAQ

¿Es esto una ejecución remota de código?

No. El impacto demostrado es un fallo de proceso y la denegación del servicio de telefonía que le sigue. Ninguna fuente de la divulgación afirma una ejecución de código, y el propio commit de corrección de Google titula la falla como denegación de servicio remota.

¿Aparece el mensaje en la aplicación Mensajes?

No. El ataque es un data SMS al puerto 2948, y Android lo procesa en la pila de telefonía antes de llegar a cualquier bandeja. La víctima nunca ve el contenido ni el número del remitente, lo que también dificulta la atribución posterior del ataque.

¿Por qué Android 12 y 13 no están corregidos?

Las actualizaciones de seguridad del marco se envían a las versiones compatibles, lo que para esta falla significa Android 14 a 17. Los dispositivos con Android 12 y 13 ejecutan el mismo código de telefonía pero están fuera de esa ventana de actualización. Salvo que un fabricante integre el cambio de forma retroactiva, esos dispositivos seguirán vulnerables el resto de su vida útil.

¿Cómo sé que el número de CVE es correcto?

Considérelo informado, no confirmado. BleepingComputer nombra CVE-2026-58882, y el commit de corrección de Google lleva su marca EXEMPT CVE_FIX, lo que confirma que se asignó un CVE. Al 2 de noviembre de 2026, la base pública de CVE y la NVD todavía no incluyen el registro, así que el número puede cambiar cuando se publique.

¿Puede un operador bloquear estos mensajes?

Ningún material publicado describe un filtro del lado del operador. El valor malformado vive dentro de la cabecera WAP Push de un data SMS ordinario, así que el bloqueo tendría que dirigirse a ese puerto o a esa codificación. Ningún filtraje de ese tipo se describe en las fuentes. La única protección del dispositivo es el nivel de parche de octubre de 2026.

¿Qué debe hacer un parque de dispositivos esta semana?

Actualice todo dispositivo con Android 14 a 17 al nivel de parche de octubre de 2026, inventarie las versiones que informen Android 12 o 13, y planifique su reemplazo o retirada. Esos dispositivos no pueden recibir la corrección, y el ataque solo necesita sus números de teléfono.

Referencias

• Análisis técnico «SMS of Death», con causa raíz, impacto y prueba de concepto: https://smsofdeath.com/ (publicado el 29 de octubre de 2026; comprobado el 2 de noviembre de 2026)
• Aplicación y código fuente de la prueba de concepto, y la discusión de la recuperación por ADB: https://github.com/MarkBlah/smsofdeath (publicados el 29 de octubre de 2026; comprobados el 2 de noviembre de 2026)
• Commit de corrección de Android 735d9672603fa206c4b43cb668c1aa273db70b97, «RESTRICT AUTOMERGE: Fix remote DoS in decodeWapPdu»: https://android.googlesource.com/platform/frameworks/opt/telephony/+/735d9672603fa206c4b43cb668c1aa273db70b97 (escrito el 15 de junio de 2026; comprobado el 2 de noviembre de 2026)
• Código fuente de WapPushOverSms.java en el commit de corrección, líneas 217 y 244: https://android.googlesource.com/platform/frameworks/opt/telephony/+/735d9672603fa206c4b43cb668c1aa273db70b97/src/java/com/android/internal/telephony/WapPushOverSms.java (comprobado el 2 de noviembre de 2026)
• Boletín de seguridad de Android, octubre de 2026: https://source.android.com/docs/security/bulletin/2026/2026-10-01 (publicado en octubre de 2026; comprobado el 2 de noviembre de 2026)
• BleepingComputer, «New Android SMS of Death exploit can remotely crash unpatched phones», fuente del identificador CVE-2026-58882: https://www.bleepingcomputer.com/news/security/new-android-sms-of-death-exploit-can-remotely-crash-unpatched-phones/ (publicado el 31 de octubre de 2026; comprobado el 2 de noviembre de 2026)
• Statcounter Global Stats, participación mundial de versiones de Android, octubre de 2026: https://gs.statcounter.com/android-version-market-share/worldwide (comprobado el 2 de noviembre de 2026)
• Catálogo KEV de CISA, feed comprobado para CVE-2026-58882: https://www.cisa.gov/known-exploited-vulnerabilities-catalog (comprobado el 2 de noviembre de 2026)