Critical HashiCorp Consul Kubernetes Flaw Allows Attackers to Gain Elevated Privileges

HashiCorp has released fixes for a Consul-k8s authorization bypass that could allow an attacker to gain elevated Consul privileges from another Kubernetes namespace.

Tracked as CVE-2026-110720, the flaw affects deployments using automated system access control list management. HashiCorp disclosed the issue on October 26, 2026, and identified Consul-k8s 2.1.0 and 1.8.18 as patched releases.

The official security advisory lists the affected range as versions 0.42.0 through 2.0.4, with 1.8.18 available as a fixed release.

Although this article’s headline describes the vulnerability as critical, the bulletin does not provide a severity rating or CVSS score. The weakness sits in the component ACL binding rules that connect Kubernetes identities to Consul permissions.

When system ACL management is enabled, Consul-k8s sets up Kubernetes authentication and binding rules so its components can obtain Consul tokens.

Those rules should link each component’s Kubernetes ServiceAccount to its corresponding Consul role. However, the affected rules did not consistently limit authentication to ServiceAccounts inside the Kubernetes namespace hosting the Consul deployment.

This missing restriction could allow an identity from another namespace to authenticate as a Consul component and receive that component’s privileges. The result is a path across an intended access boundary, rather than a simple failure to check whether a token exists.

Exploitation requires specific access. An attacker must have Kubernetes permissions to create a ServiceAccount and obtain its token in another namespace.

The attacker must also have network access to the Consul API. The bulletin therefore does not describe an attack that any unauthenticated internet user can carry out against every Consul deployment.

The privileges gained would depend on the Consul component being impersonated. HashiCorp says an attacker may obtain the component’s associated privileges.

HashiCorp Patches Consul-k8s Security Flaw

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.

The key setting is global.acls.manageSystemACLs=true. HashiCorp explicitly states that deployments with system ACL management disabled are not vulnerable to this issue.

Teams should check both their installed Consul-k8s version and this configuration setting when deciding whether their environment is affected. Version checks alone do not establish exposure.

The issue differs from earlier attacks against misconfigured DevOps servers, which included Consul among targeted platforms. Here, HashiCorp identifies a flaw in generated authorization rules, not merely an openly exposed service. Both cases show why API reachability matters when assessing infrastructure risk.

Related reporting on Kubernetes token theft and permission abuse also shows why service account access matters. For this vulnerability, however, defenders should follow the specific prerequisites in HashiCorp’s bulletin rather than assume that unrelated attack activity proves exploitation.

HashiCorp advises customers to evaluate their risk and upgrade to Consul-k8s 2.1.0 or 1.8.18. The company credits security researcher Elias Hasas, known on GitHub as zer0d4y5, with reporting the flaw. The bulletin does not specify additional post-upgrade cleanup requirements.

Give your SOC the alert context to stops incidents quickly. Integrate Threat Intel from 16K SOCs.

The post Critical HashiCorp Consul Kubernetes Flaw Allows Attackers to Gain Elevated Privileges appeared first on Cyber Security News.