HashiCorp ha lanzado correcciones para una vulnerabilidad de omisión de autorización en Consul-k8s (identificada como CVE-2026-110720). Este fallo podría permitir que un atacante obtenga privilegios elevados de Consul desde otro espacio de nombres de Kubernetes, afectando específicamente a las implementaciones que utilizan la gestión automatizada de listas de control de acceso del sistema. Las versiones parcheadas son Consul-k8s 2.1.0 y 1.8.18.

HashiCorp ha lanzado correcciones para un salto de autorización (authorization bypass) en Consul-k8s que podría permitir que un atacante obtenga privilegios elevados de Consul desde otro espacio de nombres (namespace) de Kubernetes.

Identificado como CVE-2026-110720, el fallo afecta a los despliegues que utilizan la gestión automatizada de listas de control de acceso (ACL) del sistema. HashiCorp reveló el problema el 26 de octubre de 2026 e identificó a Consul-k8s 2.1.0 y 1.8.18 como las versiones parcheadas.

El aviso de seguridad oficial indica que el rango afectado abarca desde las versiones 0.42.0 hasta la 2.0.4, estando la 1.8.18 disponible como versión corregida.

Aunque el titular de este artículo describe la vulnerabilidad como crítica, el boletín no proporciona una calificación de severidad ni una puntuación CVSS. La debilidad reside en el componente de reglas de enlace de ACL que conectan las identidades de Kubernetes con los permisos de Consul.

Cuando la gestión de ACL del sistema está habilitada, Consul-k8s configura la autenticación de Kubernetes y las reglas de enlace para que sus componentes puedan obtener tokens de Consul.

Dichas reglas deberían vincular la ServiceAccount de Kubernetes de cada componente con su rol de Consul correspondiente. Sin embargo, las reglas afectadas no limitaban consistentemente la autenticación a las ServiceAccounts dentro del espacio de nombres de Kubernetes que aloja el despliegue de Consul.

Esta restricción ausente podría permitir que una identidad de otro espacio de nombres se autentique como un componente de Consul y reciba los privilegios de dicho componente. El resultado es una vía a través de un límite de acceso previsto, en lugar de un simple fallo al comprobar si existe un token.

La explotación requiere un acceso específico. Debes tener permisos de Kubernetes para crear una ServiceAccount y obtener su token en otro espacio de nombres.

También debes tener acceso de red a la API de Consul. Por lo tanto, el boletín no describe un ataque que cualquier usuario de internet no autenticado pueda llevar a cabo contra cualquier despliegue de Consul.

Los privilegios obtenidos dependerían del componente de Consul que se esté suplantando. HashiCorp afirma que un atacante puede obtener los privilegios asociados a ese componente.

HashiCorp Parchea el Fallo de Seguridad de Consul-k8s

Según el aviso HCSEC-2026-50, una explotación exitosa no otorga necesariamente acceso administrativo total, y no se ha proporcionado código de explotación ni detalles confirmados de su uso.

El ajuste clave es global.acls.manageSystemACLs=true. HashiCorp establece explícitamente que los despliegues con la gestión de ACL del sistema desactivada no son vulnerables a este problema.

Tú y tu equipo deberíais comprobar tanto la versión de Consul-k8s instalada como este ajuste de configuración al decidir si tu entorno está afectado. Las comprobaciones de versión por sí solas no establecen la exposición.

Este problema difiere de ataques anteriores contra servidores DevOps mal configurados, que incluían a Consul entre las plataformas objetivo. Aquí, HashiCorp identifica un fallo en las reglas de autorización generadas, no simplemente un servicio expuesto abiertamente. Ambos casos muestran por qué la accesibilidad de la API es importante al evaluar el riesgo de la infraestructura.

Informes relacionados sobre el robo de tokens de Kubernetes y el abuso de permisos también muestran por qué es importante el acceso a la cuenta de servicio. Para esta vulnerabilidad, sin embargo, debes seguir los requisitos previos específicos del boletín de HashiCorp en lugar de asumir que actividades de ataque no relacionadas prueban la explotación.

HashiCorp aconseja a sus clientes evaluar su riesgo y actualizar a Consul-k8s 2.1.0 o 1.8.18. La empresa acredita al investigador de seguridad Elias Hasas, conocido en GitHub como zer0d4y5, por informar el fallo. El boletín no especifica requisitos adicionales de limpieza posteriores a la actualización.

Fuentes:
https://cybersecuritynews.com/hashicorp-consul-kubernetes-vulnerability/