Cadena de exploits VoLTE en Unisoc permite a un atacante tomar el control total del kernel de Android
En resumen
Este artículo explica la cadena completa, los chipsets afectados y por qué este caso redefine la conversación sobre la responsabilidad de los fabricantes de silicio en la cadena de suministro móvil.
Contexto: por qué importa Unisoc
Unisoc, antes conocida como Spreadtrum, es un fabricante de chipsets con sede en Shanghái que provee SoCs para teléfonos de marcas como Motorola, Realme y Xiaomi. Según el advisory de SSD, sus chips están presentes en dispositivos vendidos en más de 140 países. Los modelos específicos confirmados como afectados incluyen el Motorola E13 (con el chipset T606), el Realme C33 (T612) y el Xiaomi Redmi A5 (T7250).
Lo importante no es solo la cuota de mercado de Unisoc, sino su posición en el segmento de dispositivos Android de gama baja. Esos teléfonos son la elección por defecto en mercados emergentes, dispositivos secundarios para ejecutivos y, en algunos casos, la única opción para empleados con restricciones presupuestarias. La superficie de ataque no se limita a usuarios individuales: cualquier flota corporativa que use estos dispositivos, intencionalmente o por shadow IT, está en riesgo.
La cadena en dos fases
La divulgación de SSD Secure Disclosure se divide en dos publicaciones distintas:
**Fase 1 (marzo 2026)**: ejecución remota de código en el firmware del módem mediante una llamada VoLTE (Voice over LTE) SIP malformada. La vulnerabilidad permitía al atacante ejecutar código en el contexto del módem simplemente enviando una llamada de video VoLTE manipulada al dispositivo víctima.
**Fase 2 (agosto 2026)**: escalada local de privilegios desde el contexto del módem hasta el kernel de Android. Esta segunda fase es la que se reveló en agosto y es la que convierte la RCE inicial en un compromiso total del dispositivo.
La cadena completa requiere que el atacante cumpla tres condiciones:
1. Controlar una red 4G privada (un core 4G open-source sirve). 2. Disponer de un radio definido por software (SDR) para la interfaz radioeléctrica 4G. 3. Que la víctima conteste la llamada de video VoLTE entrante.
La parte 3 es importante: a diferencia de muchos exploits móviles, este no es completamente silencioso. La víctima debe ver una llamada entrante y decidir contestarla. Sin embargo, ingeniería social dirigida contra un objetivo de alto valor (jefe de seguridad, ejecutivo con dispositivo de gama baja) sigue siendo trivial.
La vulnerabilidad técnica: CWE-1189
La falla de escalada de privilegios está clasificada como CWE-1189, "Improper Isolation of Shared Resources on System-on-a-Chip". El advisory de SSD no asigna un identificador CVE todavía, lo cual es problemático por sí mismo: cualquier herramienta de gestión de vulnerabilidades basada en NVD no detectará esta clase de exposición.
El detalle técnico merece atención. Los SoCs modernos tienen al menos dos procesadores distintos: el procesador de aplicaciones (donde corre Android y el kernel) y el procesador del módem (donde corre el firmware de banda base). En una arquitectura correcta, existen límites de hardware que impiden que el procesador del módem lea o modifique la memoria del procesador de aplicaciones. Esos límites son críticos: la memoria del kernel es donde reside todo el estado del sistema.
El chipset Unisoc afectado comparte el espacio físico de memoria entre el procesador del módem y el procesador de aplicaciones, sin una frontera impuesta por hardware. Eso significa que cualquier código que ya se esté ejecutando en el contexto del módem (gracias a la RCE de la fase 1) puede, en principio, leer y escribir la memoria física que corresponde al kernel de Android.
El exploit de SSD lleva esa capacidad al límite: la escalada funciona reescribiendo la configuración de la Memory Protection Unit (MPU) del procesador ARM del módem. La MPU es el componente de hardware que define qué regiones de memoria son legibles, escribibles y ejecutables. Al reescribir su configuración mediante registros de coprocesador, el exploit 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.
Una vez reconfigurada la MPU, el atacante escribe directamente en la memoria del kernel desde el contexto del módem. Los investigadores de SSD confirmaron la ejecución a nivel de kernel observando logs del kernel de Android que mostraban la salida del payload inyectado.
Por qué no hay parche
Aquí está la parte incómoda. SSD intentó múltiples canales para contactar a Unisoc antes de la divulgación: correo electrónico y LinkedIn. Ninguno recibió respuesta. La divulgación de marzo de 2026 llevó exactamente el mismo comunicado. No existe un advisory de seguridad de Unisoc que cubra esta vulnerabilidad, y el Android Security Bulletin de agosto de 2026 (publicado antes de esta divulgación) tampoco la aborda.
Para los profesionales de seguridad, esto es el peor escenario posible. La política de divulgación coordinada de SSD es estándar: contactar al fabricante, esperar un período razonable, publicar con un advisory que describa el riesgo. Pero cuando el fabricante no responde, la divulgación se convierte en un evento de seguridad pública sin remediación disponible.
Comparación histórica útil: en 2022, Check Point Research descubrió una vulnerabilidad coordinada en módems Unisoc, CVE-2022-20210, que sí fue parcheada y distribuida a través del Android Security Bulletin. El precedente demuestra que Unisoc puede responder cuando quiere. La falta de respuesta en 2026 no es un problema técnico, es un problema organizacional.
Trabajo relacionado de Kaspersky: el patrón se repite
Esta no es la primera vez que la condición arquitectónica de chipsets móviles sin separación de memoria entre módem y procesador de aplicaciones sale a la luz. En noviembre de 2025, Kaspersky ICS CERT publicó una investigación sobre un chip Unisoc diferente, el UIS7862A, presente en unidades de cabeza de vehículos. Después de obtener ejecución de código en el módem mediante una vulnerabilidad separada, el equipo de Kaspersky también logró alcanzar y modificar el kernel de Android en ejecución explotando el espacio de direcciones físicas compartido.
Kaspersky describió uno de sus caminos de movimiento lateral, que involucraba un periférico DMA oculto, como un problema de hardware no solucionable mediante una actualización de software. Eso es importante: incluso si Unisoc quisiera parchar este caso, la ruta DMA mencionada por Kaspersky no es parcheable. La ruta de la MPU que usa SSD es en principio direccionable mediante un cambio de firmware, pero Unisoc no se ha comprometido a hacerlo.
Dispositivos confirmados como vulnerables
El advisory confirma la explotación en los siguientes dispositivos:
- **Motorola E13**: parche de seguridad de febrero de 2025. Confirmado vulnerable. - **Xiaomi Redmi A5**: parche de seguridad de enero de 2026. Confirmado vulnerable.
Un dispositivo con parche de seguridad de enero de 2026 sigue siendo vulnerable, lo cual indica que la falla está en la capa de firmware del módem (que no se actualiza con el Android Security Bulletin mensual) o en la arquitectura de hardware (que no se puede cambiar sin un rediseño del SoC).
Investigadores también mencionan el chipset T612 (Realme C33) como vulnerable, aunque el caso confirmado de prueba es contra el T606 y T7250. Los usuarios de Realme C33 deben asumir el mismo riesgo hasta que Unisoc publique aclaración.
Implicaciones para equipos DevSecOps
**1. Inventario de dispositivos móviles corporativos.** El primer paso es auditar cuántos dispositivos Unisoc hay en tu flota. La forma más directa es consultar el MDM (Intune, Jamf, Kandji, VMware Workspace ONE) y filtrar por modelo. El Motorola E13 y el Xiaomi Redmi A5 son los más comunes; cualquier dispositivo que coincida debe marcarse como alto riesgo.
**2. Segmentación de redes.** Si tienes empleados con dispositivos Unisoc en la flota, asegúrate de que no tengan acceso directo a recursos sensibles desde la red móvil. Forzar VPN corporativa con autenticación fuerte antes de acceder a servicios internos es un control compensatorio viable.
**3. Política de uso aceptable.** Documenta explícitamente qué dispositivos están aprobados para uso corporativo. Los chipsets Unisoc no certificados deben quedar fuera del alcance de datos confidenciales.
**4. Monitoreo de VoLTE entrante.** En dispositivos críticos, considera deshabilitar VoLTE en favor de llamadas CSFB (Circuit-Switched Fallback) o servicios como WhatsApp/Signal que no dependen de la infraestructura SIP del módem. El tradeoff: pérdida de calidad de audio en llamadas.
**5. Plan de respuesta a incidentes.** Si tu organización tiene empleados de alto riesgo (ejecutivos, investigadores, equipos de M&A) con dispositivos Unisoc, desarrolla un plan de respuesta que asuma el compromiso total del dispositivo. Incluye reemplazo inmediato del equipo, rotación de credenciales en todos los servicios a los que el dispositivo tuvo acceso, y revisión forense de la cadena de eventos.
Lo que significa para la industria
El caso Unisoc expone tres problemas sistémicos:
**La cadena de suministro móvil no tiene accountability.** A diferencia del ecosistema de servidores, donde Intel, AMD y ARM responden a CVEs y emiten microcode updates, los fabricantes de chipsets móviles no tienen la misma obligación contractual. Un comprador empresarial puede exigir a su proveedor de servidores parches CVE en plazos definidos; con un fabricante de teléfonos no existe ese contrato.
**El modelo de divulgación coordinada falla cuando el fabricante no responde.** SSD hizo todo correctamente. La política de divulgación responsable requiere contacto, espera y publicación. Pero el modelo asume un fabricante que responde. Cuando no hay respuesta, el resultado es divulgación pública sin remediación, lo que es peor para todos: atacantes obtienen el exploit, defensores no tienen parche.
**Las pruebas de seguridad de firmware móvil son opacas.** En el ecosistema Android, los usuarios confían en el OEM (Motorola, Realme, Xiaomi) para distribuir los parches del proveedor de chipset. Cuando ese proveedor no responde, el OEM queda imposibilitado de actuar. La cadena de dependencia es invisible para el comprador final.
Qué hacer ahora
Si gestionas una flota móvil, las acciones inmediatas son:
- Auditar el inventario MDM en busca de chipsets Unisoc afectados. - Bloquear el acceso a recursos sensibles desde dispositivos identificados. - Desactivar VoLTE en dispositivos críticos como medida temporal. - Documentar la decisión de riesgo en el registro de excepciones de seguridad. - Solicitar a tu OEM confirmación por escrito del estado de exposición.
No hay parche que aplicar. El control está en la capa de gestión, no en la capa técnica.
Llamado a la acción
¿Te interesa profundizar en cómo tu organización debería evaluar el riesgo de proveedores de silicio en flotas móviles? Síguenos en X, Instagram, LinkedIn y YouTube de X-Ops, y en X, Instagram y LinkedIn de Hacker Dreams. Cada semana publicamos un análisis técnico de una vulnerabilidad crítica con contexto accionable para tu equipo DevSecOps. Próximos temas: cadena de exploits en GeoServer zero-day, campaña APT china contra infraestructura VMware, y el estado del patching SAP Commerce Cloud después de CVE-2026-58231.
---
*Fuentes: advisory de SSD Secure Disclosure (ssd-disclosure.com/unisoc-t612-lpe/), divulgación previa de RCE (ssd-disclosure.com/unisoc-t612-rce/), reporte original de The Hacker News, investigación previa de Kaspersky ICS CERT (ics-cert.kaspersky.com).*