HashiCorp consul-k8s CVE-2026-110720 cross-namespace ACL binding rule flaw allows Consul privilege escalation
HashiCorp disclosed CVE-2026-110720 (advisory HCSEC-2026-50, published October 26, 2026), a cross-namespace authorization bypass in consul-k8s. Component ACL binding rules did not consistently restrict authentication to ServiceAccounts in the Kubernetes namespace where Consul is deployed. An attacker with limited Kubernetes permissions could therefore authenticate as a Consul component and obtain that component's privileges. Fixes are in consul-k8s 1.8.18 and 2.1.0. The advisory gives no CVSS score and no evidence of active exploitation.
Entenda a falha
A vulnerabilidade
CVE-2026-110720 is a cross-namespace authorization bypass in HashiCorp consul-k8s (advisory HCSEC-2026-50). The component ACL binding rules did not consistently restrict authentication to ServiceAccounts in the Kubernetes namespace where Consul is deployed. An attacker needs Kubernetes permissions to create a ServiceAccount and obtain its token in another namespace, plus network access to the Consul API. They can then authenticate as a Consul component and get that component's privileges. Affected: consul-k8s 0.42.0 to 2.0.4, only with global.acls.manageSystemACLs=true. Fixed in 1.8.18 and 2.1.0. No CVSS score was given.
Como funciona
When system ACL management is enabled, consul-k8s configures Kubernetes authentication and Consul ACL binding rules. Consul components present a Kubernetes ServiceAccount token, and the binding rules map that identity to a Consul token tied to the component's role. The problem appears at the matching step: the rule did not require the ServiceAccount to be in the Consul namespace. A ServiceAccount created in another namespace could therefore satisfy a component rule and receive the privileges meant for that component.
Por que é vulnerável
The root cause is a missing restriction in the component binding rules. They did not consistently scope accepted identities to the Kubernetes namespace where Consul runs, so the namespace boundary was not enforced when mapping a ServiceAccount to a Consul role. The articles do not explain why it went unnoticed or describe the code change in detail. The fixed releases 1.8.18 and 2.1.0 address the binding rule behavior.
Onde está
The articles name no file, function or commit; they only place the flaw in the component ACL binding rules that consul-k8s creates when global.acls.manageSystemACLs=true, described in advisory HCSEC-2026-50.
Como foi descoberta
HashiCorp credited researcher Elias Hasas (GitHub: zer0d4y5) with reporting the flaw. The articles do not say how it was found or when it was reported. HashiCorp published advisory HCSEC-2026-50 on October 26, 2026, together with the fixed releases. The advisory gives no exploitation telemetry and no evidence of active exploitation.
Explicação gerada por IA a partir da matéria e dos artigos, em 27/10/2026 09:16.
Detalhes técnicos
- Affected: consul-k8s 0.42.0 to 2.0.4, only where
global.acls.manageSystemACLs=true. Deployments with system ACL management disabled are not vulnerable. - With system ACL management enabled, consul-k8s configures Kubernetes authentication and Consul ACL binding rules. These let Consul components use Kubernetes ServiceAccounts to obtain Consul tokens tied to their roles.
- Because the binding rules were not restricted to the Consul namespace, a ServiceAccount created in another namespace could satisfy a component rule and receive that component's privileges.
- Prerequisites: Kubernetes permissions to create a ServiceAccount and obtain its token in another namespace, plus network access to the Consul API.
- The advisory does not name the component roles, list the obtainable permissions, or confirm that full administrative takeover is possible in every affected deployment.
- Credit: researcher Elias Hasas (GitHub: zer0d4y5).
Remediação
- Upgrade consul-k8s to 2.1.0 or 1.8.18.
- Check whether
global.acls.manageSystemACLsis enabled. - Review who can create ServiceAccounts and tokens in other namespaces, and who has network access to the Consul API.
Linha do tempo
-
HashiCorp consul-k8s CVE-2026-110720 cross-namespace ACL binding rule flaw allows Consul privilege escalation
ler a análise desta fonte ocultar
HashiCorp disclosed CVE-2026-110720 (advisory HCSEC-2026-50, published October 26, 2026), a cross-namespace authorization bypass in consul-k8s. Component ACL binding rules did not consistently restrict authentication to ServiceAccounts in the Kubernetes namespace where Consul is deployed. An attacker with limited Kubernetes permissions could therefore authenticate as a Consul component and obtain that component's privileges. Fixes are in consul-k8s 1.8.18 and 2.1.0. The advisory gives no CVSS score and no evidence of active exploitation.
Technical Details
- Affected: consul-k8s 0.42.0 to 2.0.4, only where
global.acls.manageSystemACLs=true. Deployments with system ACL management disabled are not vulnerable. - With system ACL management enabled, consul-k8s configures Kubernetes authentication and Consul ACL binding rules. These let Consul components use Kubernetes ServiceAccounts to obtain Consul tokens tied to their roles.
- Because the binding rules were not restricted to the Consul namespace, a ServiceAccount created in another namespace could satisfy a component rule and receive that component's privileges.
- Prerequisites: Kubernetes permissions to create a ServiceAccount and obtain its token in another namespace, plus network access to the Consul API.
- The advisory does not name the component roles, list the obtainable permissions, or confirm that full administrative takeover is possible in every affected deployment.
- Credit: researcher Elias Hasas (GitHub: zer0d4y5).
Remediation
- Upgrade consul-k8s to 2.1.0 or 1.8.18.
- Check whether
global.acls.manageSystemACLsis enabled. - Review who can create ServiceAccounts and tokens in other namespaces, and who has network access to the Consul API.
- Affected: consul-k8s 0.42.0 to 2.0.4, only where