Se han detectado dos fallos críticos en ArangoDB (versiones hasta la 3.12.10.1) que permiten a un atacante externo evadir los controles de inicio de sesión, leer o modificar datos de la base de datos y, finalmente, lograr la ejecución de código remoto con privilegios de root en el servidor anfitrión. Este riesgo es especialmente grave para bases de datos expuestas a internet y despliegues en contenedores, ya que el ataque no requiere contraseñas robadas ni interacción del usuario.

Dos fallos críticos en ArangoDB pueden permitir que alguien externo evite los controles de inicio de sesión, lea o altere los datos de la base de datos y, posteriormente, obtenga la ejecución de código a nivel de root en el host subyacente.

Los problemas afectan a las instalaciones hasta la versión 3.12.10.1, lo que crea un riesgo grave para las bases de datos expuestas a internet y los despliegues de contenedores.

El ataque no depende de contraseñas robadas, de que un usuario haga clic o de una cadena de exploits compleja. Una solicitud cuidadosamente codificada puede confundir a dos partes del servidor sobre si una ruta de la interfaz de programación de aplicaciones (API) protegida es pública.

Incidentes similares de evasión de autenticación empresarial muestran cómo este tipo de fallo puede abrir el acceso a infraestructuras críticas. Analistas de Remedio identificaron los fallos mientras revisaban la superficie de ataque HTTP de ArangoDB.

Remedio indicó en un informe que ambos errores derivan de que el servidor confía en la información suministrada en la solicitud al decidir qué puede hacer quien realiza la llamada.

Fallos críticos de ArangoDB permiten la evasión de autenticación

El primer fallo se rastrea como GHSA-rrgq-978q-36mq y recibió una puntuación CVSS 3.1 de 9.8. En el modo de autenticación predeterminado de solo sistema de ArangoDB, las rutas que comienzan con /_ deben requerir un inicio de sesión, mientras que otras rutas se tratan como rutas de aplicación públicas.

Los investigadores descubrieron que la comprobación de autenticación examina la URL bruta, pero el código de enrutamiento interpreta posteriormente una versión decodificada.

Sustituir el guion bajo en /_api por su forma codificada en URL, %5f, hace que el primer componente vea una ruta con apariencia pública mientras que el enrutador llega al punto final de la API restringida. Ese pequeño desacuerdo en el análisis es suficiente para saltarse la puerta de inicio de sesión.

Una solicitud sin credenciales puede llegar a acciones protegidas de la base de datos, permitiendo el acceso administrativo sin credenciales en todas las colecciones y bases de datos. Los investigadores demostraron la recuperación del hash de la contraseña de la cuenta root, que utiliza una ronda de SHA-256 y un salt de 32 bits.

La configuración de tareas permite la ejecución de root

El segundo problema, GHSA-rvhw-4hpw-9vrx, afecta a la interfaz HTTP de ArangoDB para la programación de tareas en segundo plano de JavaScript.

Tiene una puntuación CVSS 3.1 de 9.9 porque un usuario con permiso de escritura en la base de datos puede establecer el campo de solicitud isSystem en true y forzar una tarea hacia el contexto de ejecución interno y altamente privilegiado del servidor.

Normalmente, ese contexto está reservado para el propio servidor. La API interna de JavaScript comprueba si quien realiza la llamada es realmente interno antes de permitir tareas del sistema, pero el manejador HTTP no aplicaba la misma protección.

El resultado es un valor booleano controlado por el cliente que actúa como límite entre el trabajo en entorno aislado (sandbox) y los privilegios a nivel de host. Una vez que una tarea se ejecuta en ese contexto, puede leer o escribir archivos en el host y realizar solicitudes web salientes.

En la imagen oficial del contenedor, el proceso arangod se ejecuta como root, por lo que el acceso a archivos puede exponer secretos como /etc/shadow, claves privadas TLS, material de firma del clúster o variables de entorno que contienen la contraseña de root.

El permiso de escritura de archivos también crea una ruta práctica hacia la ejecución remota de código como root. Un atacante podría colocar una clave SSH autorizada, alterar una tarea programada o modificar un archivo de servicio que se ejecute más tarde.

Las solicitudes salientes podrían, además, llegar a servicios internos o puntos finales de metadatos de la nube, expandiendo el compromiso más allá del host de la base de datos.

Los fallos pueden encadenarse: el primer error puede exponer el hash de la contraseña de root, y el segundo puede utilizar el acceso de escritura autenticado a la base de datos para escapar hacia el entorno de tareas privilegiado.

Esta combinación hace que el informe sea importante para los equipos que vigilan fallos críticos de ejecución remota de código en sistemas que albergan datos valiosos.

ArangoDB recibió los informes el 23 de agosto de 2026 y lanzó las correcciones el 31 de agosto en la versión 3.12.11. Los avisos se publicaron el 6 de septiembre, mientras que los identificadores CVE aún estaban pendientes.

Si utilizas la versión 3.12.10.1 o anterior, debes actualizar inmediatamente, restringir la exposición de la base de datos a redes confiables, rotar las credenciales potencialmente expuestas e investigar la creación de tareas inesperadas o la actividad de la API.

La lección general es sencilla: los componentes seguros pueden fallar cuando interpretan la misma solicitud de manera diferente. Los desarrolladores deben normalizar y autorizar las solicitudes una sola vez, aplicar la misma decisión en todos los manejadores y nunca permitir que la entrada del cliente reclame privilegios a nivel de sistema.

Las lecciones en los informes de vulnerabilidades críticas parcheadas muestran por qué las actualizaciones rápidas y la reducción de la exposición son esenciales cuando un fallo puede conducir directamente al control administrativo.