Los investigadores de seguridad Sam Curry y Shubham Shah han demostrado que podían tomar el control de cualquier cuenta de cliente de dos fabricantes de automóviles, y con ella abrir las puertas y arrancar el motor de sus coches conectados, gracias a una consola de administración de ForgeRock que seguía usando la contraseña por defecto admin:admin. Las dos marcas, que los investigadores no identifican, corrigieron el fallo unas dos horas después de recibir el aviso.
Las claves del fallo de ForgeRock en coches conectados en 20 segundos
- Curry y Shah accedieron a cuentas de clientes de dos fabricantes sin nombre.
- La entrada fue una consola de ForgeRock con la contraseña por defecto.
- Podían abrir, arrancar y localizar coches en Estados Unidos, Canadá y Australia.
- Las marcas lo corrigieron en unas dos horas.
El caso no se debe a un fallo en el coche ni a un error de programación de ForgeRock, la plataforma de gestión de identidades que hoy pertenece a Ping Identity y se comercializa como PingIDM. Es un problema de despliegue: una herramienta de administración que la propia guía de endurecimiento del fabricante pide eliminar o proteger antes de pasar a producción seguía activa y con las credenciales de serie. Por eso no hay identificador CVE ni aviso oficial del fabricante del software.
De la consola olvidada a las llaves del coche
Las aplicaciones móviles de ambas marcas autenticaban a los clientes mediante ForgeRock. Esta plataforma funciona en dos partes: una gestiona el inicio de sesión y otra, llamada OpenIDM, guarda los registros de los clientes. OpenIDM incluye una consola de administración basada en Apache Felix, accesible en la ruta /system/console, y en los servidores de los dos fabricantes estaba presente con el usuario y la contraseña por defecto.
La consola no estaba expuesta directamente a internet. Según el análisis recogido por The Hacker News, los investigadores sortearon el bloqueo con barras codificadas y caracteres adicionales en la ruta, de forma que el cortafuegos de aplicaciones web (WAF) interpretaba la petición como un archivo estático mientras el servidor la enviaba a la consola. Una vez dentro, usaron el programador de tareas integrado para ejecutar scripts, lo que les dio ejecución de comandos en el servidor de identidades.
Desde ahí llegaron a los registros de clientes, cambiaron el correo y la contraseña de una cuenta de prueba, iniciaron sesión por la aplicación normal y obtuvieron tokens de acceso válidos. Con ellos abrieron las puertas y arrancaron el motor de un coche de prueba, con el propietario junto al vehículo, y después lo apagaron y cerraron. Los investigadores explican que la sesión daba el mismo control que la aplicación del dueño: ubicación y telemetría, cierre y apertura de puertas y arranque o parada remota del motor.
Había un detalle especialmente delicado: cambiar el correo y la contraseña no cerraba la sesión del propietario en su móvil, y los investigadores podían desviar las alertas de la cuenta lejos del teléfono del dueño. Tras las pruebas restauraron los datos originales.
Credenciales dentro de la app y MFA sorteado en Australia
Shah publicó aparte una segunda cadena de ataque contra la operación australiana de una de las marcas. Allí la puerta de entrada fue otra: unas credenciales de administrador de la plataforma de identidades olvidadas dentro de un archivo JavaScript de la aplicación Android que descargaba cualquier cliente. Según contaron los investigadores a iTnews, esas credenciales estaban pensadas para un entorno de pruebas, pero funcionaban contra producción y el directorio real de clientes.
Con ese acceso podían restablecer la contraseña de cualquier usuario y saltarse la autenticación multifactor (MFA) mediante una concesión de contraseña de OAuth, para después generar un token de la aplicación y enviar la orden de apertura. Uniendo ambos ataques, afirman que podían mandar órdenes de apertura y arranque a coches de estas marcas en Estados Unidos, Canadá y Australia. Las fuentes consultadas no dan fecha de corrección para los sistemas australianos.
Las pruebas completas se hicieron en febrero de 2026 en Estados Unidos, con coches propios y de propietarios que dieron su consentimiento, aunque los detalles no se han hecho públicos hasta noviembre. No consta que nadie más explotara el fallo, pero tampoco hay información pública que lo descarte.
Lo que deben revisar quienes usan PingIDM
Curry y Shah llevan años encontrando fallos de este tipo en las plataformas web que hay detrás de las aplicaciones de los coches, más que en los propios vehículos. Ya habían demostrado accesos remotos a modelos de Honda, Kia y Subaru, y un estudio de 2023 sobre 16 fabricantes encontró debilidades parecidas en autorización y aplicaciones web.
Para cualquier organización que use ForgeRock o PingIDM, no solo fabricantes de coches, las comprobaciones son claras: buscar la consola de Apache Felix en /system/console y eliminarla o cambiar su contraseña, no confiar en reglas de ruta del WAF para ocultar páginas de administración y aplicar la guía de endurecimiento para producción del fabricante. También conviene revisar que ninguna aplicación distribuida a clientes lleve credenciales internas, aunque sean de un entorno de pruebas.
Preguntas frecuentes
¿Qué fabricantes de coches estaban afectados?
Los investigadores no los han identificado. Solo indican que eran dos marcas que usaban ForgeRock para autenticar a los clientes de sus aplicaciones.
¿Está corregido el fallo?
Sí en Estados Unidos: ambas marcas lo corrigieron unas dos horas después del aviso. No se ha publicado la fecha de corrección de los sistemas australianos.
¿Es una vulnerabilidad de ForgeRock?
No. Es un error de configuración en el despliegue: la consola de administración debía eliminarse o protegerse antes de pasar a producción. No hay CVE asignado.
¿Qué podían hacer los atacantes con el acceso?
Lo mismo que el propietario desde la aplicación: ver la ubicación y la telemetría, abrir y cerrar puertas y arrancar o apagar el motor a distancia.
Fuentes:
