En el dinámico panorama de la infraestructura moderna, donde Kubernetes se erige como el orquestador por excelencia y herramientas como HashiCorp Consul gestionan servicios y configuraciones críticas, la seguridad de cada componente es primordial. Recientemente, HashiCorp ha emitido una alerta crucial sobre una vulnerabilidad de bypass de autorización en su integración Consul-k8s, identificada como CVE-2026-110720. Este fallo podría permitir a un atacante obtener privilegios elevados de Consul desde un namespace de Kubernetes ajeno al despliegue de Consul, creando una brecha significativa en los límites de acceso previstos.
Análisis Técnico de la Vulnerabilidad
La esencia de esta vulnerabilidad reside en un defecto en las reglas de enlace de ACL (Access Control List) que HashiCorp Consul-k8s establece automáticamente. Cuando la gestión automática de ACL del sistema está habilitada (global.acls.manageSystemACLs=true), Consul-k8s configura la autenticación de Kubernetes y las reglas de enlace para que sus componentes puedan obtener tokens de Consul. Idealmente, estas reglas deberían vincular cada ServiceAccount de Kubernetes del componente con su rol de Consul correspondiente.
Sin embargo, las reglas afectadas no limitaban consistentemente la autenticación a las ServiceAccounts ubicadas dentro del mismo namespace de Kubernetes que aloja el despliegue de Consul. Esta restricción ausente permite que una identidad de otro namespace se autentique como un componente de Consul y, consecuentemente, adquiera los privilegios asociados a dicho componente. Esto no es una simple falla de verificación de token, sino una ruta de acceso que atraviesa un límite de seguridad intencionado.
Las versiones afectadas de Consul-k8s abarcan desde la 0.42.0 hasta la 2.0.4. HashiCorp ha publicado correcciones en las versiones 2.1.0 y 1.8.18, instando a los usuarios a actualizar sus sistemas.
Condiciones de Explotación y Alcance
Es importante destacar que la explotación de CVE-2026-110720 no es trivial ni accesible para cualquier usuario no autenticado en internet. Requiere condiciones muy específicas que limitan su alcance:
- Permisos de Kubernetes: Un atacante debe poseer permisos en Kubernetes para crear una
ServiceAccounty obtener su token en un namespace distinto. - Acceso a la API de Consul: El atacante debe tener acceso de red a la API de Consul.
La gravedad de los privilegios obtenidos dependerá directamente del componente de Consul que el atacante logre suplantar. HashiCorp aclara que una explotación exitosa no garantiza necesariamente acceso administrativo total. Hasta la fecha, no se ha proporcionado código de explotación público ni se han confirmado detalles de ataques en el mundo real, lo que subraya la importancia de una respuesta proactiva por parte de los equipos de IT y SRE.
Identificación de Sistemas Afectados
La clave para determinar si su entorno es vulnerable radica en dos factores: la versión de Consul-k8s instalada y la configuración de las ACL del sistema. Los despliegues con la gestión de ACL del sistema deshabilitada (es decir, global.acls.manageSystemACLs=false) no son vulnerables a este problema.
Para verificar si su despliegue podría estar en riesgo, los equipos deben revisar:
- Versión de Consul-k8s: Compruebe que no se encuentre en el rango afectado (0.42.0 a 2.0.4).
- Configuración de ACL: Examine si la gestión de ACL del sistema está activa. Esto generalmente se configura en el archivo de valores de Helm o en la configuración de la instalación de Consul-k8s.
Por ejemplo, en un despliegue de Helm, esta configuración se encontraría de la siguiente manera:
global:
acls:
manageSystemACLs: true
Si manageSystemACLs está establecido en true y la versión es vulnerable, su sistema está expuesto.
Recomendaciones y Mitigación
Ante esta vulnerabilidad, la acción más crítica es la actualización inmediata. HashiCorp aconseja a sus clientes evaluar su riesgo y actualizar a las versiones seguras:
- Consul-k8s 2.1.0
- Consul-k8s 1.8.18 (para ramas de versiones anteriores)
Adicionalmente, se recomienda:
- Revisión de Configuración: Verifique proactivamente la configuración de
global.acls.manageSystemACLsen todos sus entornos. Si no es estrictamente necesaria la gestión automática de ACL del sistema, considere deshabilitarla. - Principios de Mínimo Privilegio: Asegúrese de que las
ServiceAccountsy sus roles asociados en Kubernetes tengan solo los permisos necesarios, incluso en namespaces ajenos al despliegue de Consul. - Segmentación de Red: Restrinja el acceso a la API de Consul únicamente a las fuentes confiables y componentes que realmente lo requieran.
- Monitoreo Continuo: Implemente un monitoreo robusto sobre los logs de autenticación y actividad de Consul para detectar cualquier intento de acceso inusual o no autorizado.
Conclusión
La vulnerabilidad CVE-2026-110720 en HashiCorp Consul-k8s es un recordatorio contundente de la complejidad de la seguridad en entornos distribuidos como Kubernetes. Un pequeño desajuste en las reglas de autorización puede crear una puerta trasera para la escalada de privilegios, socavando la confianza en la segmentación de namespaces. La pronta aplicación de parches, combinada con una revisión rigurosa de las configuraciones y una postura de seguridad proactiva, es esencial para proteger la integridad de sus infraestructuras críticas. Agradecemos al investigador de seguridad Elias Hasas (conocido como zer0d4y5 en GitHub) por el descubrimiento y la divulgación responsable de este fallo.
