Critical HashiCorp Consul Kubernetes Flaw Allows Attackers to Gain Elevated Privileges
Key Takeaways A critical authorization bypass (CVE-2026-110720) has been discovered in HashiCorp Consul-k8s. The vulnerability allows attackers to gain elevated Consul privileges from a different...
Key Takeaways
- A critical authorization bypass (CVE-2026-110720) has been discovered in HashiCorp Consul-k8s.
- The vulnerability allows attackers to gain elevated Consul privileges from a different Kubernetes namespace.
- It impacts Consul-k8s versions 0.42.0 through 2.0.4, specifically when automated system ACL management is enabled.
- Patched versions 2.1.0 and 1.8.18 have been released to address the flaw.
- Exploitation requires specific Kubernetes permissions and network access to the Consul API.
HashiCorp Consul-k8s Flaw Exposes Elevated Privilege Risk Across Kubernetes Namespaces
HashiCorp has issued patches for a significant authorization bypass vulnerability within its Consul-k8s integration. This flaw, identified as CVE-2026-110720, could enable an attacker to escalate their Consul privileges from an unauthorized Kubernetes namespace, posing a serious security risk to affected deployments.
Table Of Content
Understanding the Vulnerability
Disclosed on October 26, 2026, the vulnerability impacts Consul-k8s environments where automated system Access Control List (ACL) management is active. The core issue resides in how Consul-k8s establishes component ACL binding rules, which are designed to link Kubernetes identities to corresponding Consul permissions.
Specifically, when global.acls.manageSystemACLs=true, Consul-k8s configures Kubernetes authentication and binding rules to allow its components to acquire Consul tokens. The flaw arises because these rules fail to consistently restrict authentication to ServiceAccounts exclusively within the Kubernetes namespace where the Consul deployment is hosted. This oversight creates an avenue for an identity from an external namespace to impersonate a Consul component and inherit its associated privileges.
Impact and Exploitation Prerequisites
While the official advisory does not assign a CVSS score, the nature of the vulnerability suggests a critical impact due to the potential for privilege escalation. The successful exploitation of this flaw is not trivial and requires a specific set of conditions:
- An attacker must possess Kubernetes permissions sufficient to create a ServiceAccount and obtain its token within a different namespace.
- The attacker must also have network connectivity to the Consul API.
Consequently, this vulnerability does not represent a threat that can be exploited by an unauthenticated internet user against any Consul deployment. The level of privilege gained upon successful exploitation would be equivalent to that of the impersonated Consul component.
According to the HCSEC-2026-50 advisory, successful exploitation does not necessarily grant full administrative access, and no exploit code or confirmed exploitation details were provided.
Affected Versions and Patches
The vulnerability affects Consul-k8s versions ranging from 0.42.0 through 2.0.4. HashiCorp has released patched versions to address the issue:
- Consul-k8s 2.1.0
- Consul-k8s 1.8.18
HashiCorp emphasizes that deployments with system ACL management disabled are not susceptible to this vulnerability. The company credits security researcher Elias Hasas, known on GitHub as zer0d4y5, for reporting the flaw.
What You Should Do
- Identify Affected Deployments: Verify both your installed Consul-k8s version and the configuration setting
global.acls.manageSystemACLs. Only environments with automated system ACL management enabled are vulnerable. - Upgrade Immediately: Prioritize upgrading affected Consul-k8s deployments to version 2.1.0 or 1.8.18.
- Review Access Controls: Scrutinize Kubernetes ServiceAccount permissions across namespaces, especially those with network access to the Consul API, to minimize the attack surface.
- Monitor Network Access: Ensure strict network segmentation and access controls for the Consul API to prevent unauthorized access.
Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.



No Comment! Be the first one.