Google ha publicado el Boletín de Seguridad de Android correspondiente a septiembre de 2026, que corrige un amplio conjunto de vulnerabilidades que afectan a diferentes componentes del sistema operativo Android.
Entre los fallos solucionados se encuentran varias vulnerabilidades calificadas como críticas que pueden permitir ejecución remota de código (RCE), elevación de privilegios y denegación de servicio. Las vulnerabilidades afectan, dependiendo del componente, a Android 14, Android 15, Android 16, Android 16 QPR2 y Android 17.
Google señala que la vulnerabilidad de mayor gravedad del boletín afecta al componente System y podría permitir la ejecución remota de código sin necesidad de privilegios adicionales. Además, no requiere interacción del usuario para su explotación, circunstancia que incrementa significativamente el riesgo asociado.
El boletín establece dos niveles de parche, 2026-09-01 y 2026-09-05. Los dispositivos que dispongan del nivel de parche de seguridad 2026-09-05 o posterior incorporan las correcciones aplicables para todas las vulnerabilidades recogidas en el boletín de septiembre.
Se recomienda a usuarios, empresas y administraciones públicas actualizar los dispositivos Android tan pronto como el fabricante correspondiente distribuya las actualizaciones de seguridad.
¿Por qué son especialmente relevantes estas vulnerabilidades?
Los teléfonos inteligentes y tabletas se han convertido en activos de acceso directo a información personal y corporativa. Un dispositivo móvil puede almacenar credenciales, tokens de autenticación, correo electrónico, documentación, conversaciones, certificados, información personal y acceso a aplicaciones y servicios en la nube.
Por este motivo, una vulnerabilidad que permita ejecutar código de forma remota o elevar privilegios no debe analizarse únicamente como un problema del propio terminal.
En un entorno corporativo, un dispositivo comprometido puede convertirse en un punto de acceso a identidades, información y servicios de la organización.
La relevancia del boletín de septiembre se incrementa por la combinación de diferentes clases de vulnerabilidades. Un atacante puede intentar encadenar fallos de seguridad para superar sucesivamente diferentes mecanismos de protección. Por ejemplo, una vulnerabilidad que facilite la ejecución inicial de código podría combinarse, en determinadas circunstancias, con otra que permita elevar privilegios y aumentar posteriormente el control sobre el dispositivo.
Esto no significa que Google haya confirmado públicamente la existencia de una cadena concreta que combine las vulnerabilidades del boletín, pero constituye un escenario de riesgo que debe contemplarse en la gestión de dispositivos móviles.
Vulnerabilidades críticas de ejecución remota de código
Uno de los principales grupos de vulnerabilidades corregidas se encuentra en el componente System de Android.
Google clasifica como críticas ocho vulnerabilidades de ejecución remota de código:
- CVE-2026-28604
- CVE-2026-28618
- CVE-2026-28639
- CVE-2026-28662
- CVE-2026-49882
- CVE-2026-49884
- CVE-2026-49919
- CVE-2026-49921
La afectación concreta varía según la versión de Android. Varias de ellas afectan a Android 14, 15, 16, 16 QPR2 y 17, mientras que otras se encuentran limitadas a determinadas versiones.
El escenario de mayor gravedad identificado por Google podría permitir ejecución remota de código sin necesidad de privilegios adicionales ni interacción del usuario.
Desde una perspectiva técnica, una RCE permite que un atacante consiga que un sistema vulnerable ejecute código no previsto. Su impacto final dependerá del componente comprometido, de los privilegios asociados al proceso y de las medidas de protección presentes en el dispositivo.
Vulnerabilidad crítica en componentes del kernel
El nivel de parche 2026-09-05 incluye además CVE-2026-52993, una vulnerabilidad crítica de ejecución remota de código que afecta a componentes del kernel relacionados con Transparent Inter-Process Communication.
El kernel constituye una de las capas fundamentales del sistema operativo y gestiona funciones esenciales, como el acceso al hardware, la memoria y la comunicación entre componentes.
Por este motivo, las vulnerabilidades que afectan a esta capa presentan especial interés desde el punto de vista de seguridad.
El mismo boletín incluye también vulnerabilidades críticas de elevación de privilegios que afectan a componentes del kernel relacionados con NFC y Protected Kernel-Based Virtual Machine (pKVM), entre ellas CVE-2026-31629, CVE-2026-58846, CVE-2026-58848 y CVE-2026-58941.
Elevación de privilegios y denegación de servicio
El boletín no se limita a vulnerabilidades de ejecución remota de código.
Google también ha corregido vulnerabilidades críticas de elevación de privilegios (EoP) en los componentes Framework y System.
Entre las vulnerabilidades críticas del Framework se encuentran:
- CVE-2026-28666, elevación de privilegios.
- CVE-2026-55273, elevación de privilegios.
- CVE-2026-49932, denegación de servicio.
Google indica que el escenario más grave dentro de Framework podría permitir una elevación remota de privilegios sin necesidad de privilegios adicionales ni interacción del usuario.
Por su parte, el componente System contiene un número significativo de vulnerabilidades críticas adicionales de elevación de privilegios y denegación de servicio.
Las vulnerabilidades de elevación de privilegios son especialmente relevantes porque pueden permitir que un atacante que ya haya conseguido algún grado de acceso aumente sus capacidades dentro del dispositivo.
En una cadena de ataque, este tipo de fallo podría utilizarse para intentar superar restricciones de seguridad, acceder a recursos adicionales o ampliar el alcance del compromiso.
Dos niveles de parche: 2026-09-01 y 2026-09-05
El boletín de Android diferencia entre dos niveles de parche.
El nivel 2026-09-01 incorpora las correcciones correspondientes al núcleo de Android, incluyendo vulnerabilidades de Android Runtime, Framework, System y determinados componentes actualizables mediante Google Play System.
El nivel 2026-09-05 amplía la cobertura e incorpora además las correcciones aplicables a otros componentes, como Android TV, kernel y componentes de diferentes fabricantes de hardware.
Por tanto, desde el punto de vista de gestión de vulnerabilidades, no basta con comprobar que el dispositivo recibió “una actualización de septiembre”.
La organización debe verificar el nivel concreto de parche instalado.
Google establece que un dispositivo con nivel de parche 2026-09-05 o posterior incorpora todas las correcciones aplicables incluidas en el boletín de septiembre.
Componentes de terceros
El boletín también incluye correcciones relacionadas con componentes suministrados por diferentes fabricantes.
Entre ellos se encuentran componentes de Arm, Imagination Technologies, MediaTek, Unisoc y Qualcomm, además de elementos relacionados con GPU, módems y otros subsistemas.
Esto refleja una característica importante del ecosistema Android: la seguridad final de un dispositivo no depende exclusivamente del código mantenido directamente por Google.
El terminal integra componentes del sistema operativo, kernel, controladores, firmware y elementos suministrados por diferentes fabricantes. La disponibilidad efectiva de las correcciones para un modelo concreto depende, por tanto, del fabricante y de la política de soporte del dispositivo.
¿Qué deben hacer los usuarios?
Los usuarios de dispositivos Android deberían comprobar cuanto antes si existe una actualización disponible.
De forma general, puede consultarse el nivel de parche desde las opciones de Ajustes → Seguridad y privacidad, aunque la ubicación exacta puede variar según el fabricante y la versión del sistema operativo.
Se recomienda:
- Instalar las actualizaciones de Android disponibles.
- Comprobar que el nivel de parche de seguridad sea 2026-09-05 o posterior, cuando el fabricante lo haya distribuido para el dispositivo.
- Mantener actualizadas las aplicaciones y las actualizaciones del sistema de Google Play.
- Mantener habilitado Google Play Protect en los dispositivos compatibles.
- Evitar la instalación de aplicaciones procedentes de fuentes no confiables.
- Revisar periódicamente los permisos concedidos a las aplicaciones.
- Sustituir dispositivos que hayan dejado de recibir actualizaciones de seguridad cuando se utilicen para acceder a información o servicios sensibles.
Google señala que las protecciones de la plataforma y Google Play Protect dificultan la explotación de numerosas vulnerabilidades y permiten detectar aplicaciones potencialmente dañinas. No obstante, estas medidas constituyen capas adicionales de defensa y no sustituyen la instalación de las actualizaciones de seguridad.
Recomendaciones para empresas y administraciones públicas
En organizaciones que permitan dispositivos Android corporativos o personales con acceso a recursos internos, la respuesta debería abordarse desde la gestión integral de la movilidad y no limitarse a enviar una recomendación de actualización a los usuarios.
Se recomienda:
- Inventariar los dispositivos Android con acceso a información, aplicaciones o servicios corporativos.
- Identificar fabricante, modelo, versión de Android y nivel de parche de seguridad.
- Utilizar soluciones MDM/UEM para comprobar de forma centralizada el estado de actualización de los dispositivos gestionados.
- Establecer como referencia el nivel de parche 2026-09-05 o posterior, teniendo en cuenta la disponibilidad de la actualización para cada fabricante y modelo.
- Definir políticas de cumplimiento que impidan o restrinjan el acceso a recursos corporativos desde dispositivos que permanezcan por debajo del nivel mínimo establecido.
- Aplicar controles de Conditional Access cuando la infraestructura de identidad y movilidad lo permita.
- Identificar dispositivos que hayan alcanzado su fin de soporte (EOL) y definir un plan de sustitución.
- Revisar especialmente los dispositivos utilizados por perfiles privilegiados, administradores, personal directivo y usuarios con acceso a información sensible.
- Mantener actualizadas las soluciones MDM/UEM, EDR móvil y mecanismos de protección frente a amenazas móviles cuando estén implantados.
- Controlar la instalación de aplicaciones desde fuentes externas y limitar el sideloading en dispositivos corporativos cuando no exista una necesidad justificada.
- Mantener registros que permitan demostrar el nivel de cumplimiento del parque móvil y la gestión realizada ante vulnerabilidades críticas.
Perspectiva GRC: el parcheado móvil también es gestión del riesgo
Desde una perspectiva de Gobierno, Riesgo y Cumplimiento (GRC), este boletín pone de manifiesto un aspecto que puede quedar infravalorado: los dispositivos móviles forman parte del perímetro de seguridad de la organización.
El riesgo no debe medirse exclusivamente por el número o la puntuación técnica de las vulnerabilidades. También deben considerarse factores como:
Exposición. Qué dispositivos están afectados y a qué sistemas corporativos pueden acceder.
Criticidad del usuario. No representa el mismo riesgo un dispositivo sin acceso corporativo que el utilizado por un administrador de sistemas o un miembro de la dirección.
Sensibilidad de la información. Debe determinarse qué datos pueden almacenarse, visualizarse o procesarse desde el terminal.
Capacidad de actualización. Algunos fabricantes distribuyen los parches rápidamente, mientras que otros pueden retrasarlos o haber finalizado el soporte del modelo.
Controles compensatorios. MDM/UEM, acceso condicional, MFA, aislamiento de aplicaciones corporativas, Mobile Threat Defense y otras medidas pueden reducir el riesgo mientras se completa el despliegue.
Riesgo residual. Cuando un dispositivo no puede actualizarse, la organización debe decidir si el riesgo puede aceptarse temporalmente, necesita controles adicionales o exige retirar el dispositivo del acceso corporativo.
Para administraciones públicas y empresas con un parque móvil significativo, estas decisiones deberían integrarse en los procedimientos ordinarios de gestión de activos, vulnerabilidades, riesgos y excepciones de seguridad.
Gestión recomendada de dispositivos que no puedan actualizarse
No todos los fabricantes distribuyen las actualizaciones simultáneamente. Esto puede generar un periodo durante el cual un dispositivo afectado todavía no dispone del parche correspondiente.
En ese escenario, la ausencia temporal de una actualización no debería interpretarse automáticamente como aceptación del riesgo.
Las organizaciones deberían identificar estos dispositivos y aplicar un tratamiento basado en riesgo. Dependiendo de su criticidad, pueden adoptarse medidas como limitar temporalmente el acceso a determinadas aplicaciones, restringir el tratamiento de información sensible, reforzar la monitorización o retirar el dispositivo del acceso corporativo hasta que se encuentre actualizado.
Cuando el fabricante haya finalizado definitivamente el soporte de seguridad, debería evaluarse la sustitución del dispositivo, especialmente cuando se utilice para acceder a sistemas o información corporativa.
Priorización recomendada
La actualización debería tratarse con prioridad alta o urgente en aquellos dispositivos que:
- Tengan disponible el parche correspondiente.
- Accedan a correo electrónico, documentación o aplicaciones corporativas.
- Gestionen información sensible o datos personales.
- Pertenezcan a usuarios privilegiados o perfiles de especial exposición.
- Permitan acceso remoto a infraestructura o herramientas administrativas.
- No dispongan de controles compensatorios suficientes.
La combinación de vulnerabilidades críticas, posibilidad de ejecución remota de código sin interacción del usuario y afectación de componentes de bajo nivel justifica acelerar el proceso de actualización respecto del ciclo ordinario de parcheado.
Técnicas MITRE ATT&CK potencialmente relacionadas
Dependiendo del vector concreto y de la forma en que se explote cada vulnerabilidad, un escenario de compromiso podría relacionarse con diferentes técnicas de MITRE ATT&CK.
Entre ellas podría encontrarse T1203 – Exploitation for Client Execution, cuando un atacante aprovecha una vulnerabilidad de software para conseguir ejecución de código en el dispositivo.
Las vulnerabilidades de elevación de privilegios podrían facilitar posteriormente técnicas relacionadas con T1068 – Exploitation for Privilege Escalation.
Estas asociaciones representan posibles escenarios técnicos derivados de la naturaleza de las vulnerabilidades. No significan que Google haya confirmado públicamente que las vulnerabilidades del boletín estén siendo utilizadas mediante estas técnicas ni que exista una cadena de ataque concreta que las combine.
El boletín de seguridad de Android de septiembre de 2026 debe considerarse relevante tanto para usuarios particulares como para organizaciones.
La existencia de múltiples vulnerabilidades críticas capaces de provocar ejecución remota de código, elevación de privilegios y denegación de servicio, algunas sin necesidad de interacción del usuario, hace recomendable reducir el tiempo entre la disponibilidad de las actualizaciones y su instalación efectiva.
Para empresas y administraciones públicas, el principal aprendizaje va más allá de este boletín concreto: un dispositivo móvil sin soporte o con un nivel de parche insuficiente constituye un activo de riesgo que debe ser identificado, gestionado y, cuando sea necesario, restringido o sustituido.
La gestión de vulnerabilidades móviles debe formar parte de los mismos procesos de gobierno de seguridad aplicados al resto de endpoints corporativos.
