El blog de seguridad de Android dio a conocer, mediante un boletín, la detección de una vulnerabilidad de seguridad en Android. La vulnerabilidad CVE-2025-48593, una falla de gravedad crítica que compromete el subsistema Bluetooth en dispositivos que utilizan versiones entre Android 13 y Android 16. Con una puntuación de 9.8 sobre 10, el fallo permite la ejecución remota de código simplemente al procesar paquetes Bluetooth especialmente diseñados, lo que lo convierte en uno de los problemas más serios detectados en los últimos meses.
Aunque Google aún no ha ofrecido una explicación técnica exhaustiva, investigadores independientes coinciden en que esta vulnerabilidad no afecta a la mayoría de los smartphones tradicionales. En realidad, su impacto se concentra en dispositivos Bluetooth que funciona como altavoces o manos libres, incluyendo relojes inteligentes, altavoces inteligentes y sistemas de infoentretenimiento para automóviles. Para explotarla, el atacante requiere un emparejamiento previo, por lo que rechazar solicitudes sospechosas resulta una defensa inmediata, aunque Google indica que la explotación no requiere interacción del usuario, lo que deja abierta la posibilidad de vectores alternativos.
Origen y soluciones
El fallo está relacionado con una condición de use-after-free, generada al manipular la base de datos interna del perfil Bluetooth de manos libres. El problema ocurre cuando se reanudan conexiones o se generan errores durante la negociación de servicios mediante el protocolo SDP, provocando accesos a zonas de memoria ya liberadas. La solución integra nuevas comprobaciones sobre la existencia de la base de datos de detección y una gestión más estricta de la estructura p_disc_db, evitando que siga utilizándose después de ser descartada.
Esta corrección ya ha sido incorporada en el código fuente de LineageOS, lo que confirma su estabilidad y disponibilidad para los fabricantes. Un prototipo de exploit ha demostrado que el fallo puede provocar bloqueos en emuladores de Android, aunque no se han documentado ataques reales en dispositivos comerciales. Aun así, ya existen intentos fraudulentos de vender supuestos exploits funcionales, que en la mayoría de los casos parecen ser malware o estafas.
Otra vulnerabilidad corregida: CVE-2025-48581 en Android 16
El parche de noviembre también introduce una solución para CVE-2025-48581, una vulnerabilidad de elevación de privilegios exclusiva de Android 16. El origen del fallo reside en un error lógico dentro de la función VerifyNoOverlapInSessions, ubicada en apexd.cpp, que puede impedir la instalación de actualizaciones de seguridad y, a la vez, permitir escalación de privilegios locales sin intervención del usuario. Aunque no alcanza la criticidad del fallo Bluetooth, su impacto en la integridad del sistema lo convierte en un problema grave.
Cabe mencionar que todos los dispositivos que reporten un nivel de parche igual o superior al 2025-11-01 están protegidos frente a estas vulnerabilidades, ademas de que Google ya ha enviado el código corregido a AOSP (esto generalmente se realiza en un plazo de 48 horas desde la publicación del boletín). Como es habitual, los socios fabricantes reciben la información al menos un mes antes para preparar actualizaciones adaptadas a sus dispositivos.
Ademas de ello, tambien vale la pena mencionar que el boletín de noviembre también detalla cómo Android segmenta las vulnerabilidades según el componente afectado, y explica que la severidad se calcula asumiendo entornos de desarrollo donde las mitigaciones están deshabilitadas. Además, Google recuerda la importancia de las protecciones adicionales ofrecidas por Google Play Protect, especialmente para quienes instalan aplicaciones fuera de Play Store, y recomienda actualizar siempre a las versiones más recientes del sistema operativo.
La clasificación y documentación de vulnerabilidades en Android
El boletín profundiza en cómo se catalogan las vulnerabilidades, qué significan las abreviaturas como RCE, EoP, ID o DoS, y cómo interpretar los identificadores asociados a socios como Qualcomm, MediaTek, NVIDIA o Broadcom. Estas aclaraciones permiten entender por qué los boletines llegan fragmentados en dos niveles de parche y cómo los fabricantes deben agrupar sus actualizaciones para cumplir los estándares de seguridad.
También se explica que algunos fallos presentan un asterisco en su referencia porque sus detalles no están disponibles públicamente; normalmente, sus correcciones se integran directamente en los binarios más recientes de dispositivos como la familia Pixel.
Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.
Continúar leyendo...