HashiCorp published advisory HCSEC-2026-50 on October 26, 2026, disclosing CVE-2026-110720, an incorrect-authorization flaw (CWE-863) in consul-k8s. The component ACL binding rules that map Kubernetes ServiceAccounts to Consul roles did not reliably restrict authentication to ServiceAccounts in the namespace where Consul itself is deployed. A principal with ServiceAccount-creation rights in any other namespace can therefore present a token to Consul and be granted the privileges of an internal Consul component.

Third-party databases list the flaw at CVSS 3.1 9.9. The HashiCorp bulletin as relayed by press coverage does not clearly assign a score, so treat the number as unconfirmed and judge severity by your own exposure.

Technical details

When global.acls.manageSystemACLs=true, consul-k8s bootstraps Consul’s ACL system and creates auth methods and binding rules for its own components (server ACL init, connect injector, mesh gateways, and similar). Those binding rules tie a Kubernetes ServiceAccount identity to a Consul role or policy. The bug is that the component bindings did not consistently pin the match to the Consul deployment’s Kubernetes namespace.

The attack path:

  1. The attacker has Kubernetes RBAC to create a ServiceAccount in some namespace other than Consul’s, and to read that ServiceAccount’s token (for example via a TokenRequest or a token secret).
  2. The attacker names the ServiceAccount to match what a component binding rule selects.
  3. The attacker presents the token to the Consul API through the Kubernetes auth method.
  4. Consul accepts the identity and issues an ACL token carrying the component’s role.

Exposure requires network reachability to the Consul API. Deployments with system ACL management disabled are not affected, per HashiCorp. The impact is bounded by the privileges of whichever component is impersonated, so it is not automatically cluster-admin equivalent, but component roles typically include service registration, catalog writes and certificate-related permissions that matter in a mesh.

Affected and fixed versions

  • Affected: consul-k8s 0.42.0 through 2.0.4
  • Fixed: consul-k8s 1.8.18 and 2.1.0

Impact

This is a multi-tenancy problem. Clusters where Consul runs in a shared namespace and other teams hold ServiceAccount-creation rights in their own namespaces are the realistic target: a compromised tenant workload or a developer with namespace-scoped RBAC can escalate into the service mesh control plane. Mesh trust decisions (intentions, service identity, registrations) rely on the integrity of component tokens, so impersonation can be used to register or alter services and reach data that the mesh was supposed to isolate.

At time of writing there is no confirmed in-the-wild exploitation, and no verified public exploit. One aggregator lists a “PoC” entry for the CVE, but it contains only the advisory text. Because the precondition is Kubernetes API access, expect this to be used post-compromise for lateral movement rather than as an internet-facing entry point.

Mitigation

  • Upgrade consul-k8s to 1.8.18 or 2.1.0 (or later) and re-run the Helm upgrade so binding rules are regenerated.
  • Until patched, remove or tighten component binding rules that are not scoped to the Consul namespace, and review the auth method’s binding configuration with consul acl binding-rule list.
  • Restrict who can create ServiceAccounts and mint tokens (serviceaccounts/token) outside trusted namespaces; audit for ServiceAccounts in other namespaces that share names with Consul component accounts.
  • Limit network access to the Consul HTTP/gRPC API to mesh participants with NetworkPolicy.
  • Enable Consul audit logging and alert on ACL logins via the Kubernetes auth method from unexpected namespaces or ServiceAccounts, and on ACL binding-rule or policy changes.
  • Rotate component ACL tokens if you find evidence of anomalous logins.

References