RCE crítico en HashiCorp Vault sin parche; OpenBao ya lo ha corregido
Ingenieros de ControlPlane han demostrado una cadena de explotación que permite ejecución remota de código con privilegios root. Vault sigue expuesto mientras la respuesta de HashiCorp se hace esperar.
Un equipo de investigadores de ControlPlane ha documentado una vulnerabilidad de ejecución remota de código (RCE) en el gestor de secretos HashiCorp Vault. Se trata del segundo RCE crítico encontrado en su base de código y, a diferencia de la versión de forks, OpenBao ya ha lanzado parches en las versiones 2.6.3 y 2.7.0. Sin embargo, la versión principal de HashiCorp sigue sin corrección oficial, dejando a los usuarios expuestos en producción.
El mecanismo de ataque no es inmediato ni trivial. Los ingenieros han logrado comprometer un servidor completo encadenando cuatro vulnerabilidades distintas. La cadena comienza con un punto de entrada de API que no requiere autenticación, una falla de saneamiento de entrada que permite inyectar una carga inicial. A partir de ahí, el ataque aprovecha el mecanismo de instantáneas (snapshots) de Raft, diseñado para la consistencia de datos distribuidos, para ejecutar comandos arbitrarios con privilegios de root. Al no haber validación de comandos en ese proceso, el atacante puede sobrescribir binarios críticos o establecer shells inversos persistentes.
La raíz del problema reside en dos omisiones de diseño: la falta de validación estricta en las peticiones no autenticadas y la reutilización insegura del motor de consistencia de Raft para tareas que implican ejecución de comandos. Una vez conseguido el acceso, el atacante puede modificar configuraciones, deshabilitar controles de seguridad y exfiltrar datos, invalidando defensas perimetrales como firewalls o IDS ante una amenaza interna con derechos totales.
El aspecto más preocupante para el equipo de operaciones es la ausencia de un proceso de divulgación coordinada entre IBM, mantenedor de OpenBao, y HashiCorp. Esta falta de colaboración ha retrasado la mitigación oficial en la plataforma dominante del mercado. Mientras tanto, las organizaciones que dependen de Vault quedan a merced de soluciones improvisadas o parches no oficiales que no abordan las causas raíz. La exposición es inmediata: cualquier instancia accesible que no haya aplicado controles de red estrictos está en riesgo de compromiso total.
Para los administradores de sistemas, la recomendación práctica mientras llega el parche de HashiCorp es restablecer la arquitectura de red para limitar el acceso a los endpoints de Vault, asegurarse de que las APIs no están expuestas directamente a internet y monitorizar cualquier actividad anómala en los procesos relacionados con Raft. La situación subraya la fragilidad de depender de un solo proveedor cuando existen forks comunitarios activos que responden con mayor celeridad ante fallos de seguridad críticos.
