HashiCorp disclosed a vulnerability in consul-k8s, a cross-namespace authorization bypass that could let attackers with limited Kubernetes permissions gain elevated Consul privileges.
This vulnerability is tracked as CVE-2026-110720 and affects component access control list (ACL) binding rules when automated system ACL management is enabled. HashiCorp published advisory HCSEC-2026-50 on October 26, 2026, and released fixes in consul-k8s versions 1.8.18 and 2.1.0.
HashiCorp Consul Vulnerability
The affected versions range from consul-k8s 0.42.0 to 2.0.4, with version 1.8.18 specifically listed as a patched release. The exposure to this vulnerability depends on the configuration: deployments where `global.acls.manageSystemACLs=true` are affected, whereas those with system ACL management disabled are not vulnerable.
When system ACL management is enabled, consul-k8s configures Kubernetes authentication and Consul ACL binding rules. These rules allow Consul components to authenticate using Kubernetes ServiceAccounts and obtain Consul tokens associated with their designated roles. This association links each component’s Kubernetes identity to its corresponding privileges in Consul.
The vulnerability occurs because the component binding rules did not consistently restrict authentication to ServiceAccounts located in the Kubernetes namespace where the Consul deployment resides. As a result, a ServiceAccount created in a different namespace could potentially satisfy a component authentication rule and receive privileges intended for that component.
This creates a cross-namespace authorization failure rather than an unrestricted authentication bypass. An attacker must first possess Kubernetes permissions to create a ServiceAccount and obtain its token in another namespace.
The attacker must also have network access to the Consul API. If these prerequisites are met, the attacker may authenticate as a Consul component and gain associated privileges.
The potential impact is elevated access within Consul via an incorrectly authorized component identity. However, the advisory does not identify specific component roles, enumerate the permissions obtainable through exploitation, or confirm that every affected deployment allows for complete administrative takeover. The documented outcome is access to the privileges associated with the impersonated component.
This distinction is important for assessing exposure. Kubernetes permissions in a separate namespace are part of the attack prerequisites and do not indicate that the attacker already controls the Consul namespace. The flaw can bridge that namespace boundary when vulnerable binding rules accept the attacker-controlled identity.
HashiCorp advises customers to evaluate their exposure and upgrade to consul-k8s versions 2.1.0 or 1.8.18. Administrators assessing affected installations should determine if automated system ACL management is enabled and whether the documented ServiceAccount and Consul API access prerequisites exist. These checks are directly related to the conditions described in the advisory.
HashiCorp credited security researcher Elias Hasas, known on GitHub as zer0d4y5, for reporting the vulnerability. The bulletin provides no CVSS score, exploitation telemetry, or confirmation of active exploitation, leaving those aspects of the threat unestablished.
Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.
