A HashiCorp divulgou uma vulnerabilidade no consul-k8s, uma falha de contorno de autorização entre namespaces que pode permitir que invasores com permissões limitadas no Kubernetes obtenham privilégios elevados no Consul.
A vulnerabilidade está catalogada como CVE-2026-110720 (Common Vulnerabilities and Exposures, ou identificador comum de vulnerabilidades) e afeta as regras de vinculação de lista de controle de acesso (ACL, na sigla em inglês para access control list) dos componentes quando o gerenciamento automatizado de ACL do sistema está habilitado. A HashiCorp publicou o alerta HCSEC-2026-50 em 26 de outubro de 2026 e liberou correções nas versões 1.8.18 e 2.1.0 do consul-k8s.
Vulnerabilidade no HashiCorp Consul
As versões afetadas vão do consul-k8s 0.42.0 até a 2.0.4, sendo a 1.8.18 listada especificamente como versão corrigida. A exposição depende da configuração: implantações em que global.acls.manageSystemACLs=true estão vulneráveis, enquanto as que têm o gerenciamento de ACL do sistema desativado não são afetadas.
Quando o gerenciamento de ACL do sistema está ativo, o consul-k8s configura a autenticação do Kubernetes e as regras de vinculação de ACL do Consul. Essas regras permitem que os componentes do Consul se autentiquem usando contas de serviço do Kubernetes (ServiceAccounts) e obtenham tokens do Consul associados aos seus papéis designados. Essa associação vincula a identidade Kubernetes de cada componente aos respectivos privilégios no Consul.
A falha ocorre porque as regras de vinculação dos componentes não restringiam de forma consistente a autenticação às contas de serviço localizadas no namespace do Kubernetes onde a implantação do Consul está. Como resultado, uma conta de serviço criada em outro namespace poderia, em tese, atender a uma regra de autenticação de componente e receber privilégios destinados a esse componente.
Trata-se de uma falha de autorização entre namespaces, e não de um contorno irrestrito de autenticação. Um invasor precisa, primeiro, ter permissões no Kubernetes para criar uma conta de serviço e obter seu token em outro namespace.
O invasor também precisa ter acesso de rede à interface de programação de aplicações (API) do Consul. Se esses pré-requisitos forem atendidos, ele poderá se autenticar como um componente do Consul e obter os privilégios associados.
O impacto potencial é o acesso elevado dentro do Consul por meio de uma identidade de componente autorizada incorretamente. No entanto, o alerta não identifica papéis específicos de componentes, não enumera as permissões obteníveis pela exploração nem confirma que todas as implantações afetadas permitem controle administrativo total. O resultado documentado é o acesso aos privilégios associados ao componente personificado.
Essa distinção é importante para avaliar a exposição. As permissões no Kubernetes em um namespace separado fazem parte dos pré-requisitos do ataque e não indicam que o invasor já controla o namespace do Consul. A falha pode ultrapassar essa fronteira quando as regras de vinculação vulneráveis aceitam a identidade controlada pelo invasor.
A HashiCorp orienta os clientes a avaliar sua exposição e atualizar o consul-k8s para as versões 2.1.0 ou 1.8.18. Administradores que avaliam instalações afetadas devem verificar se o gerenciamento automatizado de ACL do sistema está habilitado e se existem os pré-requisitos de conta de serviço e de acesso à API do Consul descritos no alerta.
A HashiCorp creditou o pesquisador de segurança Elias Hasas, conhecido no GitHub como zer0d4y5, pela identificação da vulnerabilidade. O boletim não apresenta pontuação CVSS (Common Vulnerability Scoring System, sistema de pontuação de severidade de vulnerabilidades), telemetria de exploração ou confirmação de exploração ativa, o que deixa esses aspectos da ameaça não comprovados.
