HashiCorp Consul-k8s: Cross-namespace authorization bypass in component ACL binding rules
Summary
Consul-k8s versions 0.42.0 and later allow a cross-namespace authorization bypass in component ACL binding rules. An attacker who can create a ServiceAccount and obtain its token in another Kubernetes namespace, and who can reach the Consul API, may authenticate as a Consul component and gain its elevated privileges. The issue only affects deployments with global.acls.manageSystemACLs=true.
Affected
- consul-k8s 0.42.0 up to 2.0.4 (per HashiCorp advisory HCSEC-2026-50)
- Only deployments with global.acls.manageSystemACLs=true are affected
- Note: the CNA data lists the range as less than 2.0.4, so 2.0.4 is unconfirmed; do not assume it is safe
Fixed in
- consul-k8s 2.1.0
- consul-k8s 1.8.18
Workaround
- No vendor workaround; apply the fixed versions.
- Interim measures (our analysis, not vendor guidance): check whether system ACL management is enabled, review existing ACL binding rules, restrict who can create ServiceAccounts or obtain their tokens in other namespaces, and limit network access to the Consul API.
Exploitation
- No evidence of in-the-wild exploitation was found; the Strix record lists KEV as No.
- CISA SSVC: exploitation none, automatable no, technical impact total.
- A public PoC is claimed by third-party listings but is unverified; treat any such code as untrusted.
Our recommendation
- Identify all consul-k8s deployments and confirm their versions.
- Check whether system ACL management (global.acls.manageSystemACLs) is enabled.
- Upgrade to consul-k8s 2.1.0 or 1.8.18, reviewing the release notes first: rules now also require the Consul release namespace, and components outside it must be moved.
- Prioritise multi-tenant clusters and restrict ServiceAccount creation and Consul API access in the meantime.
Public exploits
Links to third-party sites, not checked by us – exploit code can contain malware. Only use it in isolated test environments.
- Proof of concept on GitHub (1 repositories)
Ghost-Bx1/ConsulK8s-CVE-2026-110720
Research sources
- HashiCorp HCSEC-2026-50 advisory discuss.hashicorp.com
- consul-k8s releases github.com
- OpenCVE CVE-2026-110720 app.opencve.io
- Strix CVE-2026-110720 www.strix.ai
- SecurityOnline: consul-k8s vulnerability CVE-2026-110720 securityonline.info
- Cryptika: critical HashiCorp Consul Kubernetes flaw www.cryptika.com
- CyberPress: critical HashiCorp Consul Kubernetes flaw cyberpress.org
Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 30 Oct 2026, 14:52.
Original description (NVD)
Consul-k8s versions 0.42.0 and later are vulnerable to a cross-namespace authorization bypass in component ACL binding rules that may allow an attacker to obtain elevated Consul privileges. This vulnerability (CVE-2026-110720) is fixed in consul-k8s 2.1.0 and 1.8.18.
Sources
The tracker combines official, freely usable data sources – updated continuously:
- NVD (NIST) – CVEs, rating (CVSS), affected products
- CISA KEV – vulnerabilities confirmed by CISA as actively exploited
- CISA Vulnrichment – CISA assessment (SSVC) in the official CVE record
- FIRST EPSS – probability of exploitation
- Microsoft MSRC – Patch Tuesday: vulnerabilities, severity, updates
- PoC-in-GitHub – public proof-of-concept repositories
- Metasploit (Rapid7) – modules of the Metasploit Framework
- Exploit-DB (OffSec) – archive of public exploits (links only)
- Patch days: official vendor pages (linked per vendor) (Vendor patch days)
This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.
Affected? We can help.
We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.