Cuando alguien nos dice que su parque de móviles está al día, la frase suele significar que en Ajustes aparece una fecha reciente. Ayer se publicó un trabajo que convierte esa fecha en una pregunta: Android puede llevar dos niveles de parche en el mismo mes, el segundo es el que cubre el módem, y el teléfono solo muestra el que le hayan puesto.
De entrada, un aviso: mantenemos parques informáticos y vendemos ese servicio, así que la parte donde decimos que hay que inventariar los terminales se lee con la ceja levantada. Lo demás está en documentos públicos que cualquiera puede abrir, y hemos puesto los enlaces al final.
Lo que se publicó el 17 de agosto
SSD Secure Disclosure publicó el segundo tramo de una cadena que empezó en marzo, cuando el mismo investigador enseñó cómo ejecutar código en el firmware del módem de varios chips Unisoc enviando SDP mal formado dentro de la señalización SIP de una videollamada. El tramo de ayer va del módem al sistema: desde el contexto del módem se apaga la protección de la primera región de la unidad de protección de memoria y a partir de ahí hay lectura y escritura sobre memoria física, incluido el código del kernel de Android. La clasificación es CWE-1189, «aislamiento indebido de recursos compartidos en un sistema en chip», y la frase del aviso es tan seca como suena: desde el contexto del módem no hay aislamiento entre la memoria del módem y la del kernel.
Los chips que el aviso de marzo lista como afectados son el T606, el T612, el T616 y el T7250. Para encadenarlo entero hacen falta tres cosas: el fallo de marzo como punto de partida, infraestructura de VoLTE controlada por quien ataca y que la víctima conteste la videollamada. No hay parche ni mitigación publicada, y el propio aviso dice que han intentado contactar con el fabricante «por correo electrónico y LinkedIn» sin recibir respuesta.
Con esos requisitos, esto no es una campaña masiva. Es material de ataque dirigido —exige presencia en la red de radio— contra alguien que interesa mucho. Nosotros nos quedamos con otra cosa, que está en la lista de teléfonos con los que lo probaron.
Las fechas de los tres teléfonos de la prueba
El aviso los enumera con su nivel de parche: un Xiaomi Redmi A5 con 2026-01-01, un Motorola E13 con 2025-02-01 y un Realme C33 con el parche de julio de 2025. Los dos primeros vienen con la fecha completa, y ahí está el detalle que casi nadie mira: ambos terminan en -01.
Ese sufijo no es el día del mes. Es el nivel. Google publica los boletines completos con dos —en 2026 los han llevado los de marzo, abril y junio—, y explica el porqué sin rodeos: «este boletín tiene dos niveles de parche de seguridad para que los socios de Android tengan la flexibilidad de arreglar más rápido un subconjunto de vulnerabilidades que son parecidas en todos los dispositivos Android». El primer nivel, el -01, cubre las secciones Framework y System: lo común a cualquier Android, venga de donde venga el hierro. El segundo, el -05, añade el kernel y los componentes de proveedor. En el boletín de junio de 2026 esa lista es Imagination Technologies, MediaTek, Qualcomm y Unisoc.
Un nivel acabado en -01 es un suelo, no un techo. Por definición de Google declara Framework y System de ese mes más todo lo de los boletines anteriores, componentes de proveedor incluidos; lo que no declara es el kernel ni el módem de ese mes. Y con el Redmi A5 hay un detalle mejor todavía: el boletín de enero de 2026 no llegó a publicar un nivel -01 con contenido propio —solo existe el 2026-01-05—, y sobre esa cadena Google escribe que «en algunos dispositivos con Android 10 o posterior, la actualización del sistema de Google Play tendrá una cadena de fecha que coincide con el nivel de parche 2026-01-01». Es decir: la fecha que enseña ese teléfono puede no venir del boletín en absoluto.
Hay una segunda lectura, más incómoda, en esas mismas fechas. El Motorola E13 de la prueba llevaba el nivel de febrero de 2025: dieciocho meses antes del día en que se publicó el trabajo. El Realme, trece. No sabemos si es que el fabricante dejó de publicar actualizaciones o es que nadie las instaló, y las dos explicaciones tienen el mismo efecto práctico y el mismo dueño: alguien que compró un teléfono y dio por hecho lo demás.
Siete en marzo, dieciséis en junio
Aquí toca ir contra el titular fácil, porque Unisoc no está fuera del sistema: tiene su sección en los boletines de Android igual que Qualcomm y MediaTek. En el boletín de marzo de 2026 hay siete CVE de Unisoc y los siete son del subcomponente Modem, todos con gravedad alta. En el de junio de 2026 son dieciséis, otra vez todos del módem y todos altos. El módem se parchea, aunque no cada mes: en los ocho boletines de 2026 Unisoc aparece en dos, marzo y junio. Va por lotes.
Y por eso mismo el caso de ayer es interesante y no anecdótico. Un fallo con CVE entra en un boletín, tiene fecha, se puede buscar, aparece en cualquier inventario de parcheo y algún día se cierra solo. Un fallo sin CVE, publicado por un tercero y con el fabricante en silencio, no cruza contra ningún catálogo, no dispara ninguna alerta y no tiene una versión que puedas exigirle a nadie. Administrativamente no existe, y lo que no existe no se gestiona.
La solución tiene que pasar por tres manos
En un portátil la cadena es corta: quien hace el sistema operativo y quien hace el equipo. En un móvil hay un escalón más, y es el que manda aquí. Google recoge y publica, pero de los componentes de proveedor dice literalmente que «estas vulnerabilidades afectan a componentes de Unisoc y hay más detalles disponibles directamente de Unisoc» y que «la valoración de gravedad de estos problemas la proporciona directamente Unisoc». Después, el fabricante del teléfono tiene que empaquetar eso en una actualización y publicarla. Tres manos, y basta con que una no se mueva.
Hay un dato del boletín que ayuda a calibrar plazos: Google avisa a sus socios de todos los problemas «al menos un mes antes» de publicarlo. Ese mes es la ventana en la que el fabricante del terminal puede tener la actualización lista el mismo día. Cuando no la tiene, la cuenta ya no se mide en semanas.
Es la misma forma de problema que contábamos con quién puede apagar tus servidores: la empresa que decide sobre tu cacharro no es la que te vendió nada. Allí era el dueño de la sala; aquí es quien fabrica un chip cuyo nombre no aparece en la caja del teléfono. En los dos casos la palanca de presión que uno cree tener —la factura— apunta a quien no puede resolver.
Cómo entra este chip en tu empresa sin que nadie lo decida
Nadie elige un módem. Se elige un precio. Según Counterpoint, Unisoc subió al 15 % del mercado mundial de chipsets de móvil en el cuarto trimestre de 2025, desde el 14 % del mismo trimestre del año anterior, y siguió creciendo en la primera mitad de 2026 mientras Qualcomm y MediaTek enviaban más de un 25 % menos de unidades que un año antes. La explicación de la consultora es de manual de compras: la gama de entrada está migrando a plataformas 4G de Unisoc para abaratar la lista de materiales, y MediaTek acusó el golpe en 5G de gama baja por la crisis de precios de la memoria. Conviene el contexto: el mercado entero de chipsets cayó un 15 % interanual en ese semestre.
Traducido a una empresa mediana: el terminal de ochenta o cien euros que se compra para el operario del almacén, para la furgoneta de reparto, para el fichaje o para el refuerzo de temporada. Ese teléfono casi nunca pasa por una decisión de IT. Entra por una factura de material fungible, se le mete una línea y ya está trabajando. Y como está trabajando, tiene correo.
La otra mitad del asunto es por dónde va ese teléfono. La cadena de ayer necesita que quien ataca controle la infraestructura de VoLTE, y eso empuja la conversación al mismo sitio en el que la dejamos al hablar de la APN privada del operador: la red móvil se contrata como si fuera un cable y en realidad es una red con vecinos, con equipos intermedios y con configuración que alguien decidió por ti.
Antes de que alguien te venda una auditoría
Si la flota son iPhone y gama media de Samsung, esta cadena concreta no te toca y no vamos a fingir lo contrario para vender una revisión. Tampoco te toca si los móviles no llevan nada de la empresa dentro. Y si alguien te ofrece hoy una auditoría de seguridad móvil citando esta noticia, la pregunta correcta es qué va a mirar exactamente, porque contra este fallo no hay parche que aplicar ni ajuste que corregir: solo hay saber qué tienes.
Tampoco recomendaríamos retirar teléfonos en funcionamiento por esto. El escenario pide demasiadas cosas a la vez. Lo que sí recomendaríamos es que el próximo lote se compre mirando cuántos años de actualizaciones promete el fabricante, un dato público que suele estar en la misma página que las megapíxeles de la cámara y al que nadie hace caso.
Cinco cosas que sí valen la pena
- 1.Mira la fecha entera, no el mes. Está en Ajustes → Acerca del teléfono → Versión de Android → Actualización de seguridad de Android. Si acaba en
-01, ese terminal no está declarando nada sobre el módem, el kernel ni la GPU de ese mes. - 2.Y míralo a escala, no teléfono por teléfono. La propiedad se lee con
adb shell getprop ro.build.version.security_patch, y si hay gestión de dispositivos el mismo dato viaja como campo de inventario. Una columna en una hoja vale más que treinta capturas de pantalla. - 3.Añade al inventario de móviles el modelo y la fecha de fin de actualizaciones. La segunda decide cuándo se retira el aparato, y es la que nadie apunta el día de la compra porque ese día parece un dato de folleto.
- 4.Decide quién puede comprar un teléfono que va a llevar correo de empresa. Es una línea en el procedimiento de compras, no una política de seguridad, y si un terminal puede entrar sin pasar por ahí, el resto de esta lista sobra.
- 5.Separa los terminales de tarea de los de persona, y si alguno usa uno de los chips citados y viaja a sitios delicados, apaga VoLTE y VoWiFi en él mientras no haya solución. Un móvil de almacén no necesita buzón ni documentos: lo que no está en el teléfono no se lo lleva quien entre en el teléfono.
La tercera lista
Hace unos días escribíamos, a cuenta de un fallo en la función de compartir pantalla de macOS, que casi toda empresa tiene la lista de sus equipos y casi ninguna la de qué escucha desde fuera. Este caso añade una tercera, la más rara de todas: de qué está hecho lo que tienes. El chip antes que el modelo, y quién publica sus correcciones y hasta cuándo antes que la marca de la caja.
Nadie va a mantener esa lista para cada tostadora de la oficina, y no hace falta. Hace falta para lo que lleva una tarjeta SIM, una dirección IP pública o datos de clientes, que suele ser mucha menos cosa de la que uno teme y bastante más de la que uno recuerda.
Fuentes (verificadas el 18 de agosto de 2026): la cadena publicada el 17 de agosto de 2026, la clasificación CWE-1189, la ausencia de aislamiento entre memoria del módem y del kernel, el apagado de la protección de la primera región (ID 0) de la MPU, los chips T606, T612, T616 y T7250 listados como afectados, los dispositivos de prueba con su nivel de parche (Xiaomi Redmi A5 con 2026-01-01, Motorola E13 con 2025-02-01 y Realme C33 con el parche de julio de 2025), el requisito de infraestructura VoLTE controlada por el atacante y de que la víctima conteste la videollamada, y la frase «hemos intentado ponernos en contacto con el proveedor a través de múltiples canales (correo electrónico y LinkedIn) pero no hemos podido recibir respuesta», de los avisos «UNISOC T612 LPE» y «UNISOC T612 RCE» (SSD Secure Disclosure), con la cobertura de The Hacker News del 17 de agosto de 2026. Los dos niveles de parche y su contenido, la cita «este boletín tiene dos niveles de parche de seguridad para que los socios de Android tengan la flexibilidad de arreglar más rápido un subconjunto de vulnerabilidades que son parecidas en todos los dispositivos Android», el aviso a los socios «al menos un mes antes» de la publicación, las dieciséis entradas de Unisoc del subcomponente Modem con gravedad alta y las frases sobre que los detalles y la valoración de gravedad los proporciona directamente Unisoc, del Android Security Bulletin de junio de 2026; las siete entradas de Unisoc del subcomponente Modem, del boletín de marzo de 2026; y la frase «en algunos dispositivos con Android 10 o posterior, la actualización del sistema de Google Play tendrá una cadena de fecha que coincide con el nivel de parche 2026-01-01», del boletín de enero de 2026, que solo publicó el nivel 2026-01-05 (Android Open Source Project). El recuento de en qué boletines de 2026 aparece Unisoc y en cuáles se publicaron los dos niveles es nuestro, hecho sobre esas mismas páginas. La cuota del 15 % en el cuarto trimestre de 2025 frente al 14 % del año anterior sale del seguimiento trimestral de cuota AP-SoC de Counterpoint Research; el crecimiento de Unisoc en la primera mitad de 2026, la caída de más del 25 % interanual en envíos de Qualcomm y MediaTek, la migración de la gama de entrada a plataformas 4G de Unisoc para abaratar la lista de materiales y la caída del 15 % del mercado, de su análisis del primer semestre de 2026. La lectura del sufijo -01 en los dispositivos de la prueba, el cálculo de los dieciocho y trece meses de retraso, la distinción entre un fallo con CVE y uno sin él, y todas las recomendaciones son nuestras. Las citas en castellano de textos originalmente en inglés son traducción nuestra. No hemos encontrado, a 18 de agosto de 2026, ningún comunicado de Unisoc sobre este trabajo ni un CVE asignado.
¿Sabes de qué están hechos tus terminales?
En el mantenimiento informático que prestamos, el inventario es la fuente de verdad: modelo, versión y fecha en la que cada cosa deja de recibir correcciones. Y el puesto de trabajo moderno incluye decidir qué lleva dentro cada teléfono, no solo cuál se compra.
Hablar con everyWAN