Consul-k8s corrige un bypass de ACL entre namespaces

El 26 de octubre HashiCorp publicó HCSEC-2026-50 para consul-k8s, la integración que conecta Kubernetes con Consul. El aviso describe CVE-2026-110720: una regla de autorización puede aceptar una identidad de Kubernetes desde un namespace distinto al que aloja Consul y concederle privilegios de componente. No afecta automáticamente a cualquier instalación: la condición clave es que esté habilitada la gestión de ACL del sistema.

El fallo aparece al unir dos modelos de identidad que suelen vivir en planos distintos. Kubernetes separa recursos por namespace, mientras Consul concede permisos mediante ACL (listas de control de acceso). Si la regla de binding no limita bien la identidad al namespace esperado, una cuenta de servicio creada en otro espacio puede terminar autenticándose ante Consul como si perteneciera a uno de sus componentes.

-InfraCrew dice: La frontera entre namespaces sirve de poco si la regla que traduce identidades se queda mirando solo el nombre del usuario.-

Una ruta concreta, no una puerta abierta para cualquiera

HashiCorp sitúa el problema en las reglas de binding que gestionan las identidades de los componentes. Un atacante necesita poder crear una ServiceAccount en un namespace diferente, obtener su token y alcanzar la API de Consul desde la red. Con esas condiciones puede intentar autenticarse como componente y heredar los privilegios asociados a ese rol; el aviso no dice que baste con enviar una petición desde Internet ni que el fallo permita saltarse por sí solo la autenticación del clúster.

La configuración de global.acls.manageSystemACLs=true es determinante. HashiCorp indica que los despliegues con esta opción activa están afectados y que aquellos con la gestión de ACL del sistema deshabilitada no lo están. Esa distinción evita dos errores habituales en un triage: poner todos los clústeres Consul en la misma bolsa o descartar el riesgo porque el API no está publicado en una dirección pública, cuando aún puede ser alcanzable desde cargas internas con permisos excesivos.

El registro CVE califica el impacto con 9,9 sobre 10 en CVSS 3.1, según la revisión técnica de los registros y avisos de la publicación secundaria. La puntuación ayuda a comparar, pero no sustituye las condiciones de explotación descritas por el fabricante: quien no puede crear identidades en otros namespaces o no tiene ruta a la API parte de una situación distinta. HashiCorp no informa de explotación activa ni presenta una solución temporal alternativa en su boletín.

-InfraCrew dice: Una API interna sigue siendo una API alcanzable; el diagrama de red suele ser más optimista que los permisos de los pods.-

Versiones y comprobaciones útiles

El aviso cubre consul-k8s desde 0.42.0 hasta 2.0.4. HashiCorp publica las correcciones en 1.8.18 y 2.1.0, por lo que la versión adecuada depende de la rama que use cada instalación y de su ruta de actualización soportada. No conviene elegir el número más alto a ciegas: un operador puede depender de valores de Helm, compatibilidad con Consul o un ciclo de mantenimiento concreto que deba validarse antes del cambio.

La primera revisión es comprobar la versión efectiva del chart o del operador y el valor de gestión de ACL, no solo la versión del servidor Consul. Después, identifica quién puede crear ServiceAccounts y leer sus tokens en namespaces distintos, además de qué workloads pueden llegar al API de Consul. Ese cruce dibuja el alcance real mejor que una lista genérica de clústeres Kubernetes.

La corrección más directa es actualizar consul-k8s a una versión indicada por HashiCorp y confirmar que el controlador vuelve a reconciliar sus recursos con normalidad. Antes de desplegarla, contrasta la compatibilidad de la versión con el resto de la instalación y prueba el cambio en el entorno que corresponda a la política interna. El boletín pide evaluar el riesgo y actualizar; no documenta un workaround que permita tratar una configuración vulnerable como corregida.

Tras el cambio, verifica que los componentes de Consul recuperan sus tokens esperados y que la reconciliación de servicios continúa operando. También merece la pena revisar los permisos sobre la creación de cuentas de servicio y la conectividad hacia la API: reducir privilegios y rutas innecesarias limita las precondiciones que describe el aviso, aunque no reemplaza la corrección del software. No hay que inferir una intrusión a partir de la presencia de una versión vulnerable; la revisión de registros debe seguir el procedimiento de seguridad de cada organización.

-InfraCrew dice: La actualización cierra el defecto; el inventario de quién puede emitir identidades evita que el mismo patrón vuelva con otro nombre.-

Diccionario de la Crew

Namespace — Ámbito lógico de Kubernetes que agrupa recursos y permite separarlos dentro del mismo clúster.
ServiceAccount — Identidad que un proceso o componente de Kubernetes usa para acceder a la API u otros servicios.
ACL — Lista de reglas que define qué operaciones puede realizar una identidad sobre un recurso.

Fuentes

HashiCorp — HCSEC-2026-50
Severity Daily — análisis de los cinco avisos de Consul