Una cadena de exploits publicada por SSD Secure Disclosure apunta a una vía especialmente peligrosa: en determinados dispositivos con firmware de módem de Unisoc, una llamada VoLTE puede usarse para alcanzar acceso total kernel en Android. El detalle crítico es que los investigadores no reportan una solución por parte del fabricante del chipset, y hoy los usuarios deben confiar en que los fabricantes de sus teléfonos implementen correcciones en firmware.
El informe describe un proceso en dos etapas. La primera, revelada antes en el tiempo, se centra en lograr ejecución de código en el módem. La segunda etapa, la que se publicó en agosto de 2026, convierte ese punto de partida en una capacidad mucho más amplia: ejecución con impacto a nivel de kernel dentro del sistema Android.
La cadena de dos etapas detrás del acceso total kernel
De acuerdo con la publicación del 17 de agosto de 2026, la investigación continúa desde un hallazgo anterior realizado en marzo de 2026. En aquel momento se comunicó una ejecución remota de código en el mismo tipo de firmware. Para completar el recorrido hasta el acceso total kernel, la cadena requiere condiciones adicionales: el atacante debe controlar una red celular privada 4G y la víctima debe responder a una llamada de video entrante.
En otras palabras, no basta con “estar cerca” del objetivo. La vía descrita combina una debilidad en el módem (obtenida mediante la etapa previa) con un escenario operativo donde el objetivo acepta una llamada VoLTE de video, orquestada desde infraestructura del atacante.
De la etapa previa al control del módem
La etapa inicial, divulgada en marzo de 2026, se asocia a un video SIP malformado. Tras esa primera fase, el atacante necesita ya tener una “huella” a nivel de módem: ejecutar código dentro del entorno del módem permite activar la siguiente parte del ataque.
Los investigadores no mencionan un identificador CVE para esta familia de problemas en el momento de la publicación, aunque sí indican que la escalada de privilegios se clasifica como CWE-1189, relacionada con aislamiento incorrecto de recursos compartidos en sistemas sobre chip.
Qué hace posible la escalada hasta el kernel
El componente más relevante de la cadena es el modo en que la escalada de privilegios se realiza desde el contexto del módem hacia memoria crítica del sistema. Según el informe, una vez que el código ya está ejecutándose en el módem, el paso de escalada funciona al escribir una configuración de acceso completo hacia la ARM Memory Protection Unit (MPU) del módem mediante registros de coprocesador.
El resultado práctico que describen es que el atacante puede mapear el espacio de direcciones físico de 32 bits como legible, escribible y ejecutable desde el contexto del módem. Ese mapeo incluye páginas donde reside el kernel de Android.
En el fondo, el informe señala un supuesto arquitectónico: existe un espacio de memoria físico compartido entre el procesador del módem y el procesador de aplicaciones dentro del SoC, y no habría una barrera de hardware que impida que el código del contexto del módem modifique memoria del kernel.
Confirmación por indicios en logs del sistema
Para validar la ejecución, los investigadores indican que confirmaron la ejecución de código a nivel kernel en un dispositivo de prueba observando salida de registros del kernel donde se aprecia que el payload inyectado se ejecutó.
Además, el informe recalca que el funcionamiento completo de la cadena no depende solo de la vulnerabilidad final: requiere tanto el “punto de entrada” conseguido en la etapa de marzo como una infraestructura VoLTE controlada por el atacante y una respuesta del usuario a la llamada entrante.
En qué dispositivos y chipsets se observó el problema
Los investigadores sostienen que la vulnerabilidad vive en el firmware del módem compartido por al menos tres chipsets Unisoc. Entre los ejemplos mencionados se incluyen:
- T606, presente en el Motorola E13.
- T612, presente en el Realme C33.
- T7250, presente en el Xiaomi Redmi A5.
Para las verificaciones, señalan confirmaciones en un Motorola E13 con un parche de seguridad de febrero de 2025 y en un Xiaomi Redmi A5 con un parche de enero de 2026. Eso sugiere que los parches aplicados hasta entonces no neutralizaron la condición necesaria para lograr el acceso total kernel.
Clasificación, ausencia de CVE y falta de parche
En el momento de la publicación, la escalada descrita se encuadra bajo CWE-1189. Los autores indican que no se asignó un CVE (al menos hasta esa fecha de publicación).
Más importante aún para el usuario final: el boletín de seguridad de Android de agosto de 2026 no cubre esta vulnerabilidad de escalada. Además, el informe menciona que tampoco existe, según lo revisado, un boletín específico del fabricante del chipset que aborde el problema.
Los investigadores también afirman que intentaron comunicarse con el proveedor por múltiples canales (como correo y redes sociales profesionales) sin obtener respuesta.
Qué necesita un atacante (y qué significa para la prevención)
La cadena no es “un botón” que funcione en cualquier circunstancia. Para alcanzar el acceso total kernel, el atacante debe:
- Obtener ejecución o control en el módem mediante la vulnerabilidad previa (revelada en marzo de 2026).
- Contar con infraestructura VoLTE controlada (en el informe se menciona la necesidad de una red celular privada 4G).
- Lograr que la víctima responda una llamada de video entrante.
Para su prueba de concepto, el equipo construyó un entorno apoyado en componentes de red 4G de código abierto, radio definida por software para la interfaz de radio y tarjetas SIM especializadas. En términos prácticos, esto sugiere que el actor malicioso debe tener capacidad técnica y acceso a infraestructura.
Aun así, el riesgo existe: si un dispositivo es vulnerable, la combinación de fallo arquitectónico y condiciones operativas puede permitir una toma de control muy profunda.
Mitigaciones y rol del fabricante del dispositivo
El artículo remarca que los propietarios de dispositivos no disponen de parche o mitigación directa en el momento de la divulgación. La vía de corrección, según el razonamiento del informe, podría requerir ajustes a nivel de firmware que cambien la forma en que se maneja el aislamiento de memoria y la MPU.
Sin embargo, los autores señalan que no se ha comprometido una actualización de ese tipo por parte del proveedor del chipset.
En este contexto, lo más concreto que puede hacer un usuario es mantenerse al día con las actualizaciones del fabricante del teléfono. Si la corrección llega, normalmente lo hará a través de un update de firmware o parches que integren el componente del módem.
Investigaciones relacionadas: hallazgos previos en la misma arquitectura
La cadena descrita se suma a otra investigación independiente publicada por Kaspersky ICS CERT en noviembre de 2025. Ese trabajo documentó la misma “condición arquitectónica” en un chipset distinto, el UIS7862A, asociado a unidades de cabecera en vehículos.
Tras ganar ejecución de código en el módem con una vulnerabilidad distinta, el equipo de Kaspersky también logró llegar y modificar el kernel en ejecución explotando el espacio de direcciones compartido entre módem y procesador de aplicaciones.
Además, el informe recuerda un enfoque distinto de movimiento lateral descrito por Kaspersky: un recorrido que involucra un periférico DMA oculto, presentado como un problema a nivel de hardware que no se solucionaría solo con actualización de software. En cambio, la ruta del equipo de SSD en esta nueva cadena apunta a un enfoque direccionable desde firmware, aunque sin actualización confirmada.
Finalmente, se menciona un caso coordinado de vulnerabilidades de módem descubierto por Check Point Research en 2022 (CVE-2022-20210), que sí fue parchado y distribuido vía Android Security Bulletin. La publicación comparativa destaca que las dos vulnerabilidades divulgadas recientemente no tienen esa misma garantía.
Conclusión: vigila actualizaciones y entiende el riesgo real
La investigación de SSD Secure Disclosure describe un camino que, bajo condiciones específicas, puede terminar en acceso total kernel desde el firmware del módem en dispositivos con chipsets Unisoc. Aunque el escenario requiere control de infraestructura y respuesta del usuario a una llamada entrante, el impacto potencial es considerable: acceso a memoria y ejecución relacionada con el kernel de Android.
Por ahora, no existe un parche confirmado del fabricante de chips ni cobertura directa en el boletín mencionado. La mejor acción para usuarios y equipos de TI es mantener los dispositivos actualizados con releases del fabricante del teléfono y estar atentos a avisos de seguridad que incluyan cambios de firmware del módem.
Fuente: https://thehackernews.com/2026/08/unisoc-volte-video-call-exploit-chain.html
