HashiCorp patches Consul‑k8s authorization bypass (CVE‑2026‑110720)
HashiCorp has released fixes for an authorization bypass in Consul‑k8s that could let an attacker obtain elevated Consul privileges by impersonating a component from a different Kubernetes namespace.
Tracked as CVE‑2026‑110720 and disclosed on October 26, 2026, the issue affects deployments using automated system access control list (ACL) management. HashiCorp identifies Consul‑k8s 2.1.0 and 1.8.18 as patched releases. The official advisory also lists the affected range as versions 0.42.0 through 2.0.4, with 1.8.18 provided as a fixed release.
The bulletin does not include a severity rating or CVSS score. The flaw is in the ACL binding rules that map Kubernetes identities to Consul permissions: when system ACL management is enabled, Consul‑k8s creates Kubernetes authentication and binding rules so components can obtain Consul tokens. Those rules should tie each Kubernetes ServiceAccount to the corresponding Consul role, and restrict authentication to ServiceAccounts inside the namespace hosting the Consul deployment.
In the affected versions, the binding rules did not consistently enforce the namespace restriction. That omission can allow a ServiceAccount from another namespace to authenticate as a Consul component and receive that component’s privileges, creating a path across an intended access boundary rather than a simple missing token check.
Exploitation requires specific access: an attacker must have Kubernetes permissions to create a ServiceAccount and obtain its token in a different namespace, and must have network access to the Consul API. Because of these prerequisites, the advisory does not describe an attack that any unauthenticated internet user can carry out against every Consul deployment.
The level of privileges an attacker could gain depends on the Consul component being impersonated; HashiCorp says an attacker may obtain that component’s associated privileges. The company’s HCSEC‑2026‑50 advisory notes that successful exploitation does not necessarily grant full administrative access. HashiCorp did not publish exploit code or report any confirmed exploitation.
The issue is distinct from prior attacks that targeted misconfigured DevOps servers or publicly exposed services; here the problem is in generated authorization rules rather than an openly exposed Consul instance. The advisory highlights why API reachability and service account access are important when assessing infrastructure risk, but defenders should rely on the specific prerequisites described in the bulletin rather than assuming unrelated token‑theft activity proves exploitation of this vulnerability.
HashiCorp recommends that customers evaluate their exposure and upgrade to Consul‑k8s 2.1.0 or 1.8.18. The company credits security researcher Elias Hasas (GitHub: zer0d4y5) for reporting the flaw. The advisory does not specify additional post‑upgrade cleanup steps.
Give your SOC the alert context to stop incidents quickly. Integrate Threat Intel from 16K SOCs.
