Threat reportVulnerabilityTL-2026-4535
Critical HashiCorp Consul-k8s ACL Binding Rule Authorization Bypass Allows Cross-Namespace Privilege Escalation (CVE-2026-110720)
Critical HashiCorp Consul-k8s ACL Binding Rule Authorization (TL-2026-4535), also tracked as HCSEC-2026-50, is a critical-severity software vulnerability scored CVSS 9.9, first published 2026-10-27. It has no confirmed attribution, affects HashiCorp Consul-k8s, references 1 CVE (CVE-2026-110720), maps to 4 MITRE ATT&CK techniques (T1078.004, T1136.003, T1550.001), and is covered by 9 detection rules and 6 indicators of compromise.
- CVSS
- 9.9/10Critical
- CVEs
- 1Referenced vulnerabilities
- Techniques
- 4MITRE ATT&CK
- Actors
- 0Not attributed
- Detection rules
- 9SPL · KQL · Sigma
- IOCs
- 6Indicators of compromise
Key facts for TL-2026-4535
- Threat ID
- TL-2026-4535
- Also known as
- HCSEC-2026-50
- Severity
- CRITICAL
- CVSS
- 9.9 (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)
- Status
- PATCHED
- Category
- VULNERABILITY
- First published
- Last reviewed
- Attribution confidence
- LOW
- Motivation
- UNKNOWN
- Target sectors
- technology, cloud services, finance, government administration, health
- Target regions
- Global
- Detection rules
- 9
- Indicators of compromise
- 6
Malware and tooling in Critical HashiCorp Consul-k8s ACL Binding Rule Authorization
Malware and tooling: consul acl CLI / Consul HTTP API
How Critical HashiCorp Consul-k8s ACL Binding Rule Authorization works
CVE-2026-110720 (HCSEC-2026-50) is a cross-namespace authorization bypass in Consul-k8s component ACL binding rules (0.42.0 through 2.0.4) that lets an attacker with ServiceAccount-creation rights in any Kubernetes namespace impersonate Consul components and obtain elevated Consul privileges when global.acls.manageSystemACLs=true. Fixed in Consul-k8s 2.1.0 and 1.8.18; no exploitation or public PoC has been reported.
HashiCorp disclosed HCSEC-2026-50 on 2026-10-26: Consul-k8s is vulnerable to a cross-namespace authorization bypass in component ACL binding rules. Binding rules are the mechanism that maps Kubernetes identities (ServiceAccounts authenticated through the Consul Kubernetes auth method) to Consul ACL roles and permissions. On deployments where system ACL management is enabled (global.acls.manageSystemACLs=true), the rules created for Consul components did not consistently restrict authentication to ServiceAccounts located in the Kubernetes namespace that hosts the Consul deployment.
Because the binding-rule selectors could match on the ServiceAccount name alone, a same-named ServiceAccount created in any other namespace could log in to Consul and receive the component's ACL role. The v2.1.0 release notes describe two affected code paths: rules written by server-acl-init, and the TerminatingGateway controller, which overwrote the terminating-gateway ACL binding rule with a selector matching only the ServiceAccount name. Both now require the Consul release namespace in addition to the ServiceAccount name.
Exploitation prerequisites stated by the vendor and NVD: (1) Kubernetes permissions to create a ServiceAccount and obtain tokens for it in a namespace other than the Consul namespace, and (2) network access to the Consul API. The attacker can then impersonate a Consul component and inherit its privileges. The source notes that successful exploitation does not necessarily grant full administrative access; the impact depends on the privileges of the impersonated component role. Deployments with system ACL management disabled are not affected.
NVD scores the issue 9.9 CRITICAL (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), CWE-863 (Incorrect Authorization). Affected: Consul-k8s 0.42.0 through 2.0.4 (the NVD text phrases the range as 0.42.0 up to versions before 1.8.18 and 2.0.4; HashiCorp's bulletin states 0.42.0 through 2.0.4). Fixed: 1.8.18 (released 2026-10-19) and 2.1.0 (released 2026-10-23). The issue was reported by Elias Hasas (GitHub: zer0d4y5). No in-the-wild exploitation, PoC or IOCs have been published.
Upgrade caveat from the 1.8.18 and 2.1.0 release notes: server-acl-init does not rewrite binding rules of components that were disabled before the upgrade. If a component (for example sync-catalog, mesh-gateway or a gateway) was previously enabled and later disabled, delete its old binding rule on the component auth method (consul acl binding-rule delete) or re-enable the component once and run the upgrade so the rule is updated; otherwise the permissive rule may persist.
MITRE ATT&CK techniques used in TL-2026-4535
Privilege Escalation
T1078.004 Valid Accounts: Cloud Accounts
Defense Evasion
T1078.004 Valid Accounts: Cloud Accounts
Persistence
T1136.003 Create Account: Cloud Account
Lateral Movement
T1550.001 Use Alternate Authentication Material: Application Access Token
lateral-movement
T1550.001 Use Alternate Authentication Material: Application Access Token
Credential Access
Affected products and versions in Critical HashiCorp Consul-k8s ACL Binding Rule Authorization
- HashiCorp — Consul-k8s
Vulnerable versions: 0.42.0 through 2.0.4 with global.acls.manageSystemACLs=true
Fixed in: 1.8.18; 2.1.0
Remediation for Critical HashiCorp Consul-k8s ACL Binding Rule Authorization
Patches
- consul-k8s 2.1.0 (released 2026-10-23)
- consul-k8s 1.8.18 (released 2026-10-19)
Immediate actions
- Upgrade Consul-k8s to 2.1.0 or 1.8.18 (HashiCorp recommends evaluating exposure and upgrading)
- After upgrading, list binding rules on the component auth method and delete stale rules for components that were disabled before the upgrade, or re-enable the component once and re-run the upgrade
- Audit Kubernetes RBAC for principals able to create ServiceAccounts and request tokens outside the Consul namespace
Workarounds
- Deployments with global.acls.manageSystemACLs disabled are not vulnerable (vendor statement); disabling ACL management is not recommended as a security control
- Limit ServiceAccount creation and token issuance in non-Consul namespaces via Kubernetes RBAC until patched (general hardening, not a vendor-published workaround)
Longer-term hardening
- Restrict network access to the Consul API to required workloads only
- Review Consul ACL binding rules for selectors that match on ServiceAccount name without a namespace constraint
- Monitor Consul ACL login events from the Kubernetes auth method for ServiceAccounts outside the Consul release namespace
CVEs associated with Critical HashiCorp Consul-k8s ACL Binding Rule Authorization
Weaknesses (CWE) in Critical HashiCorp Consul-k8s ACL Binding Rule Authorization
Timeline of Critical HashiCorp Consul-k8s ACL Binding Rule Authorization
- Pull request GH-5749 merged into release/2.1.x: binding rules now require serviceaccount.name and serviceaccount.namespace==<release ns>, -k8s-namespace becomes a required server-acl-init flag, terminating-gateway bootstrap scoped to the release namespace; cross-namespace logins now return 403 Permission denied
- HashiCorp releases consul-k8s 1.8.18 with namespace-restricted component ACL binding rules and a note on stale binding rules for previously disabled components
- HashiCorp releases consul-k8s 2.1.0, restricting server-acl-init and TerminatingGateway controller binding rules to the Consul release namespace (GH-5749)
- NVD record last modified about an hour after publication; description states Consul-k8s 0.42.0 and later are affected, with no KEV listing
- NVD publishes CVE-2026-110720 with CVSS 3.1 base score 9.9 (CRITICAL) and CWE-863
- HashiCorp publishes bulletin HCSEC-2026-50 for CVE-2026-110720, crediting Elias Hasas (zer0d4y5)
- Cyber Security News reports the flaw; no exploitation, PoC or IOCs reported
Sources cited for Critical HashiCorp Consul-k8s ACL Binding Rule Authorization
- HCSEC-2026-50 - Consul-k8s vulnerable to a cross-namespace authorization bypass in component ACL binding rules
- NVD - CVE-2026-110720
- Critical HashiCorp Consul Kubernetes Flaw Allows Attackers to Gain Elevated Privileges
- consul-k8s v2.1.0 release notes
- consul-k8s v1.8.18 release notes
- consul-k8s GH-5749 - ACL binding rule namespace restriction fix
- Consul ACL Binding Rules command reference
- HashiCorp consul-k8s release index
Detection coverage for TL-2026-4535
As of 2026-10-27, Threadlinqs Intelligence publishes 9 detection rule(s) for TL-2026-4535 across Splunk SPL, Microsoft KQL and Sigma, covering 6 indicator(s) of compromise. The whole corpus is readable without an account; a free account unlocks full detection query text in Splunk SPL, Microsoft KQL and Sigma; paid tiers add raw indicator values, correlation and the MCP server. Threadlinqs MCP server · View plans.