Unisoc modem RCE: dos CVEs encadenadas que convierten una videollamada VoLTE en control total del kernel Android

La cadena de exploit que no necesita que el usuario instale nada

El 17 de agosto de 2026, SSD Secure Disclosure publicó la segunda fase de una cadena de explotación que afecta al firmware de módem de Unisoc. La primera fase se publicó en marzo de 2026. Combinadas, las dos fases convierten una videollamada VoLTE maliciosa en ejecución de código a nivel de kernel de Android, sin parche disponible y sin respuesta del fabricante.

El caso lo cubrieron Swati Khandelwal en The Hacker News, HackNews, varios analistas en LinkedIn y Mallory. Lo que hace único a este caso no es solo la profundidad técnica —acceso al kernel desde el módem es territorio reservado a investigación de élite—, sino el hecho de que el vector inicial es una videollamada VoLTE, algo que cualquier usuario de móvil contesta a diario sin pensar en ello. La cadena convierte una acción trivial del usuario en compromiso total del dispositivo.

Lo más preocupante del caso es lo que refleja sobre la industria. SSD Secure Disclosure intentó contactar con Unisoc por múltiples canales —email y LinkedIn— sin recibir respuesta. La divulgación del fallo en marzo de 2026 tampoco obtuvo respuesta. El patrón es conocido: el silencio del fabricante cuando el problema está en componentes de bajo nivel del SoC.

Anatomía técnica: de la videollamada al kernel

La cadena tiene dos etapas claramente diferenciadas, publicadas por SSD Secure Disclosure en marzo y agosto de 2026 respectivamente. El investigador independiente detrás del hallazgo usa el handle 0x50594d.

### Etapa uno — RCE en el firmware del módem vía SIP

La primera fase, divulgada en marzo de 2026, es una vulnerabilidad de ejecución remota de código en el firmware del módem de Unisoc. El vector es una videollamada SIP malformada. Cuando el dispositivo objetivo recibe la videollamada, el firmware del módem procesa los datos SIP entrantes y la vulnerabilidad permite la ejecución de código arbitrario en el contexto del procesador del módem.

Esta fase por sí sola ya es grave —el atacante tiene control sobre el firmware del módem, que en la mayoría de dispositivos es una zona opaca para el sistema operativo principal—, pero es la fase uno de una cadena. Por sí sola, la ejecución en el módem no compromete directamente al sistema operativo Android que corre sobre el procesador de aplicaciones.

### Etapa dos — escalada desde el módem al kernel de Android

La segunda fase, publicada el 17 de agosto de 2026, es la que lleva la cadena hasta sus consecuencias finales. La vulnerabilidad está clasificada como CWE-1189: Improper Isolation of Shared Resources on System-on-a-Chip. No se le ha asignado CVE todavía y Unisoc no ha emitido ningún boletín de seguridad que la cubra.

La raíz técnica del problema es que el procesador del módem y el procesador de aplicaciones (donde corre Android) comparten el mismo espacio de memoria física dentro del SoC de Unisoc, sin una frontera impuesta por hardware que impida que código ejecutándose en el módem modifique la memoria del kernel de Android.

El ataque explota esta arquitectura de la siguiente manera. Una vez que el atacante tiene ejecución de código en el módem (gracias a la etapa uno), reconfigura la unidad de protección de memoria ARM (MPU) del módem escribiendo en registros del coprocesador. La nueva configuración mapea todo el espacio de direcciones físicas de 32 bits como legible, escribible y ejecutable desde el contexto del módem, incluyendo las páginas donde reside el kernel de Android.

Con esa configuración, el código ejecutándose en el módem puede leer, escribir y ejecutar memoria del kernel. Los investigadores de SSD lo confirmaron experimentalmente observando en los logs del kernel de Android cómo su payload inyectado se ejecutaba en el contexto del kernel.

### Chipsets y dispositivos afectados

Los investigadores confirmaron la cadena en dispositivos con tres chipsets específicos:

- Unisoc T606, presente en el Motorola E13 - Unisoc T612, presente en el Realme C33 - Unisoc T7250, presente en el Xiaomi Redmi A5

Las pruebas se realizaron con un Motorola E13 con el parche de seguridad de febrero de 2025 y un Xiaomi Redmi A5 con el parche de seguridad de enero de 2026. Esto confirma que incluso dispositivos con parches relativamente recientes son vulnerables.

### Requisitos para la explotación

La cadena completa no es trivial de ejecutar. Requiere tres condiciones simultáneas:

1. Que el atacante controle una red 4G privada. Los investigadores construyeron su entorno de prueba usando una red 4G de código abierto, un software-defined radio para la interfaz radio 4G, y SIM cards especializadas. 2. Que el dispositivo objetivo esté dentro del alcance de esa red 4G controlada por el atacante. Esto descarta ataques masivos a escala de internet y limita el escenario a operadores estatales, espionaje corporativo, o escenarios de ataque dirigido físico. 3. Que la víctima conteste la videollamada VoLTE entrante. Si la víctima no contesta, la cadena no progresa.

Estas tres condiciones hacen que el caso no sea una amenaza de explotación masiva, pero sí un escenario creíble para atacantes con recursos —operadores de inteligencia, atacantes de APT, campañas de espionaje corporativo dirigido—.

Por qué este caso es un caso de estudio para DevSecOps

Razón uno — la cadena cruza capas de aislamiento que se asumían seguras. El módem y el sistema operativo están conceptualmente separados en cualquier modelo de seguridad móvil moderno. La cadena de Unisoc demuestra que esa separación es ilusoria cuando el fabricante del SoC no implementa correctamente el aislamiento entre procesadores.

Razón dos — no hay parche disponible. El boletín de seguridad de Android de agosto de 2026, publicado antes que la divulgación de SSD, no cubre la vulnerabilidad de etapa dos. Unisoc no ha emitido ningún boletín de seguridad que la cubra. Para los dispositivos afectados, la única "mitigación" es esperar a que el fabricante del dispositivo (Motorola, Realme, Xiaomi) distribuya un firmware actualizado que incluya la corrección del firmware de Unisoc — algo que puede no llegar nunca.

Razón tres — el fabricante no responde a la divulgación responsable. SSD intentó contactar a Unisoc por email y LinkedIn sin respuesta. La divulgación de marzo de 2026 ya tenía el mismo problema. El patrón de silencio del fabricante es un riesgo en sí mismo: indica que otras vulnerabilidades similares pueden existir y no se divulgarán porque el canal de divulgación responsable no funciona.

Razón cuatro — la amenaza es creíble para escenarios de ataque dirigido. Aunque la cadena no es apta para ataques masivos, los requisitos (red 4G controlada, proximidad física, víctima que conteste) están al alcance de operadores de inteligencia, atacantes de APT y campañas de espionaje corporativo. Dispositivos en riesgo incluyen teléfonos de ejecutivos, periodistas, disidentes, funcionarios y operadores de infraestructura crítica que viajen a regiones con infraestructura de telecomunicaciones comprometida.

El playbook DevSecOps para esta semana

### Fase 1 — Inventario de exposición (días 1 a 3)

El primer movimiento es saber qué dispositivos en tu organización están en riesgo.

- Identificar todos los dispositivos móviles en el inventario corporativo que usen chipsets Unisoc. La lista de chipsets vulnerables confirmada por SSD incluye T606, T612 y T7250. Verificar también otros modelos Unisoc que puedan compartir la misma arquitectura. - Para cada dispositivo identificado, documentar el modelo exacto, el chipset, la versión de firmware del módem y el nivel de parche de seguridad de Android. - Verificar si el dispositivo tiene actualizaciones recientes del firmware del módem. Algunos fabricantes publican actualizaciones del firmware del módem independientemente de los parches de seguridad de Android. - Identificar a los usuarios de esos dispositivos. Los dispositivos Unisoc suelen ser modelos de gama media y baja, frecuentemente asignados a personal operativo, técnicos de campo, o como dispositivos secundarios. Determinar qué nivel de riesgo representa cada usuario.

### Fase 2 — Evaluación de riesgo (días 3 a 7)

Para cada dispositivo identificado, evaluar el riesgo en función del perfil del usuario y del entorno operativo.

- Usuarios de alto riesgo: ejecutivos, personal con acceso a información sensible, periodistas, disidentes, funcionarios que operen en regiones con infraestructura de telecomunicaciones comprometida. Estos dispositivos deberían reemplazarse o recibir protecciones adicionales. - Usuarios de riesgo medio: personal técnico, operaciones que pueden ser blanco de espionaje corporativo. Evaluar necesidad de reemplazo según el caso. - Usuarios de riesgo bajo: personal operativo general. Documentar el riesgo y mantener vigilancia sobre actualizaciones de firmware. - Para los usuarios de alto riesgo que deban mantener sus dispositivos Unisoc por motivos operativos, considerar el uso de comunicaciones alternativas (llamadas por aplicaciones con cifrado de extremo a extremo sobre datos móviles, no VoLTE) para reducir la superficie de ataque.

### Fase 3 — Mitigaciones temporales (días 7 a 14)

- Desactivar VoLTE en los dispositivos afectados si el operador lo permite. La cadena requiere una videollamada VoLTE entrante; sin VoLTE, la cadena no puede ejecutarse. La mitigación reduce la calidad de las llamadas pero elimina el vector. - Considerar el uso de SIMs de operadores que no permitan el hand-over a redes falsas fácilmente. Algunos operadores implementan protecciones adicionales contra IMS catchers y redes falsas. - Para usuarios de alto riesgo, proporcionar dispositivos alternativos con chipsets de Qualcomm o MediaTek que tengan mejor historial de respuesta a divulgaciones de seguridad y arquitecturas de aislamiento más maduras. - Si la organización opera su propia infraestructura de telecomunicaciones o PBX corporativo, evaluar si las configuraciones permiten redirigir llamadas VoLTE a redes no confiables.

### Fase 4 — Vigilancia y respuesta (continuo)

- Monitorear boletines de seguridad de Unisoc y de los fabricantes de dispositivos para detectar cuándo se publica un firmware actualizado. - Suscribirse a feeds de seguridad de Unisoc y de los fabricantes afectados. - Documentar los dispositivos vulnerables en el registro de riesgos para futuras auditorías. - Coordinar con el equipo de respuesta a incidentes para que conozca el vector de ataque y pueda reconocer indicadores de compromiso si aparecen. - Si un usuario reporta comportamientos anómalos en un dispositivo Unisoc después de recibir videollamadas sospechosas, tratar el dispositivo como posiblemente comprometido y aislarlo de la red corporativa.

Errores sistemáticos que cometen los equipos

Error uno — confiar en el aislamiento módem-sistema operativo como garantía de seguridad. El modelo de seguridad móvil moderno asume que el módem y el sistema operativo están separados. Esa separación es lógica y de software, pero no siempre está reforzada por hardware. Cuando el fabricante del SoC no implementa correctamente el aislamiento, la separación es ilusoria.

Error dos — ignorar dispositivos de gama baja y media. La gestión de dispositivos móviles suele centrarse en los modelos flagship de gama alta. Los dispositivos Unisoc son modelos de gama media y baja, frecuentemente asignados a personal operativo o usados como dispositivos secundarios. La superficie de ataque existe incluso en los dispositivos que nadie está mirando.

Error tres — subestimar la amenaza de atacantes con recursos. La cadena Unisoc no es apta para ataques masivos, pero es perfectamente creíble para escenarios de ataque dirigido. Si tu modelo de amenaza excluye atacantes con recursos, este caso lo invalida.

Error cuatro — confiar en el firmware del módem como caja negra inmutable. El firmware del módem es actualizable, pero muchos usuarios y organizaciones nunca actualizan el firmware del módem aunque sí actualicen el sistema operativo. Eso significa que incluso después de un parche, muchos dispositivos quedan expuestos.

El párrafo para liderazgo

Si necesitas el párrafo para un comité de seguridad: SSD Secure Disclosure publicó el 17 de agosto de 2026 una cadena de exploit de dos etapas que permite ejecución remota de código a nivel de kernel de Android en dispositivos con chipsets Unisoc a través de una videollamada VoLTE maliciosa. La primera etapa es un RCE en el firmware del módem divulgado en marzo de 2026. La segunda etapa es una vulnerabilidad de aislamiento entre procesadores (CWE-1189) sin CVE asignado y sin parche. Unisoc no ha respondido a la divulgación. La explotación requiere que el atacante controle una red 4G privada y que la víctima conteste la videollamada, lo que limita el escenario a atacantes con recursos pero lo hace creíble para campañas de espionaje dirigido. Los chipsets confirmados vulnerables incluyen Unisoc T606, T612 y T7250. La mitigación inmediata pasa por inventariar los dispositivos Unisoc en la organización, evaluar el riesgo según el perfil del usuario, desactivar VoLTE donde sea posible y considerar el reemplazo de dispositivos para usuarios de alto riesgo.

Cambios estructurales después de este incidente

Cambio uno — Unisoc como fabricante de alto riesgo en el threat model. Si tu inventario trata los chipsets Unisoc como equivalentes a Qualcomm o MediaTek, este caso lo invalida. Los chipsets Unisoc merecen un nivel adicional de escrutinio en cualquier organización que maneje información sensible.

Cambio dos — revisión de la gestión de dispositivos de gama baja. La gestión de dispositivos móviles suele centrarse en los flagships. Este caso documenta que los dispositivos de gama baja y media son vectores de ataque creíbles para escenarios de alto riesgo.

Cambio tres — VoLTE como vector a evaluar en el threat model de movilidad. VoLTE es la opción por defecto en la mayoría de operadores modernos. Tratar VoLTE como vector de ataque y evaluar mitigaciones (desactivación selectiva, alternativas de comunicación cifrada) es una práctica que la mayoría de organizaciones no han incorporado todavía.

Cambio cuatro — proceso de divulgación responsable como criterio de采购. Si tu organización compra dispositivos para personal de alto riesgo, el historial de respuesta a divulgaciones del fabricante del SoC debería ser un criterio de selección. Unisoc ha demostrado en este caso que no responde a divulgación responsable, lo que es un criterio de descalificación para ese perfil de uso.

Fuentes verificadas

- The Hacker News, "Unisoc VoLTE Video Call Exploit Chain Can Give Attackers Full Android Kernel Access", Swati Khandelwal, 17 de agosto de 2026. https://thehackernews.com/2026/08/unisoc-volte-video-call-exploit-chain.html - HackNews, "Unisoc VoLTE Video Call Exploit Chain Can Give Attackers Full Android Kernel Access", agosto de 2026. https://hacklido.com/news/unisoc-volte-video-call-exploit-chain-can-give-attackers-full-android-kernel-access - SSD Secure Disclosure, advisory publicado el 17 de agosto de 2026 (citado en las fuentes anteriores). - Mallory, "Unisoc VoLTE Video Call Chain Enables Full Android Kernel Access", agosto de 2026. https://mallory.ai/stories/01a00fda-193c-73ef-acec-4c357e6743b6

Recomendaciones de cierre

Inventaría cada dispositivo con chipset Unisoc en tu organización. Evalúa el riesgo según el perfil del usuario. Desactiva VoLTE donde sea posible como mitigación temporal. Considera reemplazar dispositivos Unisoc para usuarios de alto riesgo. Y finalmente, incorpora al fabricante del SoC como criterio de selección en futuras adquisiciones de dispositivos móviles. La diferencia entre esos dos marcos es lo que separa a las organizaciones que contienen un incidente de espionaje dirigido de las que descubren el compromiso cuando el daño ya está hecho.