Una llamada que no pide nada

Un teléfono se ilumina con una videollamada entrante por VoLTE, el estándar de voz sobre LTE que hoy transporta la mayoría de las llamadas en las redes modernas. La persona que lo sostiene todavía no ha tocado nada. En algún lugar bajo el sistema operativo, en una parte del chip de la que la mayoría de los propietarios nunca ha oído hablar, el módem ya está procesando por su cuenta la señalización de la videollamada en su propio núcleo de procesador independiente.

Ese núcleo independiente es el objetivo. Los investigadores de seguridad de SSD Secure Disclosure publicaron un aviso el 17 de agosto de 2026 que describe una cadena de exploit funcional contra el Unisoc T612, un chipset presente en una amplia gama de teléfonos Android económicos y de gama media. La vía de entrada pasa por el manejo que hace el módem de la señalización de videollamadas VoLTE, no por el sistema operativo Android que ve el usuario.

The Hacker News, que también cubrió el aviso, resumió la importancia con claridad: no se trata de una debilidad teórica en un artículo de laboratorio, sino de una cadena demostrada en la que un exploit funcional puede llevar de una llamada telefónica al control a nivel de kernel del dispositivo, sin que el usuario necesite abrir una aplicación, pulsar un enlace o conceder ningún permiso más allá de dejar sonar el teléfono.

Dentro de la cadena de tres etapas

Los investigadores describen el exploit como tres etapas enlazadas. La primera es lo que llaman un egg hunter, una técnica que rastrea la memoria en busca de una pequeña carga útil previamente colocada en cuanto el atacante dispone de algún tipo de acceso de escritura, en lugar de necesitar conocer de antemano las direcciones exactas de memoria. Es un paso de reconocimiento que convierte un punto de apoyo estrecho en uno utilizable.

La segunda etapa es la más determinante: una elusión de la MPU del chip, la unidad de protección de memoria, la función de hardware que se supone debe mantener aislado el entorno de ejecución del módem de la memoria sensible. SSD Secure Disclosure afirma que el exploit desactiva esa protección y después escribe directamente shellcode a nivel de kernel, otorgando al atacante acceso físico sin restricciones a la memoria desde dentro del propio entorno de ejecución del módem, una zona que nunca debería haber alcanzado tanto.

La tercera etapa es un trampolín a través de do_sys_open, una función de bajo nivel del kernel usada para abrir archivos, que la cadena reutiliza para pasar del acceso bruto a la memoria al control total del kernel en el lado Android. Encadenadas, las tres etapas llevan a un atacante desde una videollamada VoLTE recibida hasta el control del propio kernel del sistema operativo, algo cercano al máximo nivel de acceso que puede conceder un dispositivo.

Una familia de chips, no un solo teléfono

SSD Secure Disclosure y The Hacker News nombran ambos dos dispositivos confirmados como afectados: el Xiaomi Redmi A5 y el Motorola E13, dos de los teléfonos Android de gama de entrada más vendidos en Europa y más allá. Ambos son exactamente el tipo de dispositivo que una empresa compra al por mayor para un personal que necesita un teléfono que funcione, no un buque insignia.

La exposición no se limita a esos dos modelos. Los chipsets Unisoc representan aproximadamente el 14 por ciento del mercado mundial de sistemas en chip para smartphones, una cuota construida casi en su totalidad sobre dispositivos económicos y de gama media, y el T612 en particular equipa teléfonos vendidos bajo marcas como Honor, Realme, vivo, Samsung y Motorola. No todos los teléfonos con Unisoc usan el T612, pero el alcance de la familia de chips en múltiples marcas importantes significa que la huella práctica es mayor de lo que sugieren dos nombres de modelo.

Esa combinación, un chip muy utilizado en un segmento de mercado poco glamuroso, es precisamente lo que hace que el fallo importe a nivel comercial y no solo académico. Los dispositivos Android económicos y de gama media son la elección por defecto para flotas, reparto, comercio minorista, almacenes y personal de campo, exactamente las categorías de hardware que se compran en volumen y se actualizan con menos frecuencia.

Por qué el proceso normal de parcheo aún no aplica

Aquí está el detalle que separa esta historia de una vulnerabilidad de chip rutinaria: a fecha de esta publicación no se ha asignado ningún identificador CVE al fallo, y Unisoc no ha publicado ningún parche. SSD Secure Disclosure declaró sin rodeos que contactó al fabricante por dos canales distintos, correo electrónico y LinkedIn, y que no ha podido recibir ninguna respuesta. Ese silencio forma ya parte de la propia divulgación.

La gestión de vulnerabilidades corporativa habitual funciona con números CVE. Los escáneres consultan bases de datos de vulnerabilidades conocidas, las listas de verificación de compras hacen referencia a identificadores CVE, y los ciclos de parcheo se miden contra ellos. Un fallo sin CVE simplemente no aparece en ninguna de esas herramientas, lo que significa que una organización puede ejecutar un proceso de gestión de vulnerabilidades plenamente conforme y aún así tener cero visibilidad sobre un exploit de kernel activo y activable de forma remota en su propia flota de dispositivos.

Para una empresa europea con política BYOD, o que entrega teléfonos Android económicos o de gama media a su personal, la respuesta práctica no puede esperar a una alerta de escáner que no tiene nada que escanear. Los equipos de compras y gestión de dispositivos deberían comprobar hoy mismo, por modelo de dispositivo y chipset, si hay hardware Unisoc T612 en uso, en lugar de esperar una entrada CVE que puede no llegar según ningún calendario previsible.

Nada de esto significa que nunca llegará un parche. Significa que, por ahora, la única forma fiable de saber si una flota está expuesta es mirar directamente qué hardware está desplegado, porque el sistema habitual de alerta temprana no tiene nada sobre lo que avisar.