HashiCorp's five October 26 advisories cover unauthenticated cached mesh certificate/key access, service and health-check authorization bypasses, unauthenticated API memory exhaustion, and consul-k8s cross-namespace privilege escalation. Preconditions differ by flaw.
HashiCorp disclosed five Consul-related vulnerabilities on October 26. They are one release batch, but they do not share a universal unauthenticated attack path. L3: these affect mainstream service-discovery and mesh authorization boundaries; the advisories do not establish malicious exploitation or give victim counts.
The leaf API flaw can disclose a cached service certificate and its private key to someone who can reach an ACL-enabled agent’s HTTP API. It does not expose every mesh identity automatically: the requested certificate must already be cached on that agent. Most agents cache their own managed sidecars’ identities; servers supporting Consul Dataplane may cache more. Consul normally binds the HTTP API to loopback, so remote reachability depends on the deployment, while untrusted local processes still matter. A stolen identity could reach only services permitted by applicable mesh intentions; this is not disclosure of the root CA key.
The registration flaw needs an authenticated principal with write permission to both a proxy and its destination service, but without mesh write. In affected releases, equivalent spellings of Envoy override keys evade the narrower permission check. HashiCorp describes possible code execution inside that proxy, traffic access/modification and intention bypass there; this is not an unconditional Consul-server RCE. The separate health-check flaw needs write access to another service on the same node and can manipulate the victim service’s health/discovery results.
The memory-exhaustion issue needs API reachability but no valid ACL token. Large bodies are processed before authorization; enabling ACLs alone is insufficient. The fix also changes compatibility: most write endpoints cap bodies at 512 KiB.
For consul-k8s, the critical boundary is global.acls.manageSystemACLs=true. A user able to create a ServiceAccount and obtain its token in a different Kubernetes namespace, and contact the Consul API, may authenticate as a Consul component and acquire its associated privileges. This is not an anonymous Internet attack or proof that every Kubernetes user becomes cluster administrator. Deployments with system ACL management disabled are not affected by this specific issue.
The vendor lists Consul CE 2.1.0, Enterprise 2.1.0 or 1.21.19, and consul-k8s 2.1.0 or 1.8.18 as applicable fixes. Notably, HCSEC-2026-47 names Enterprise 1.22.12 as affected but does not list a dedicated 1.22 fixed release; follow a supported upgrade path rather than guessing one or blindly downgrading. No automatic version checker is offered because these products and affected release sets differ. Restricting or blocking one endpoint is temporary mitigation for the leaf-key issue, not a replacement for the batch’s updates.
Affected Consul/Enterprise releases from 1.17.0 through 2.0.4, excluding the fixed Enterprise 1.21.19 release, can return an already-cached service leaf certificate and private key without validating an ACL token. Requires ACLs enabled and access to the agent HTTP API; its default loopback binding limits remote exposure.
Affected releases are Consul 2.0.4 and Enterprise 2.0.4, 1.22.12 and 1.21.18. With ACLs enabled, a principal with write access to the proxy and destination service but without mesh write can bypass override-key checks and supply Envoy configuration.
Affected Consul/Enterprise releases through 2.0.4, excluding the fixed Enterprise 1.21.19 release, decode request bodies without a size cap before ACL checks. An attacker who can reach the HTTP API can exhaust agent memory without a valid token.
Affected Consul/Enterprise releases from 0.7.2 through 2.0.4, excluding the fixed Enterprise 1.21.19 release, with ACLs enabled allow a principal with service:write for another service on the same node to modify or rebind an existing health check, affecting discovery or mesh routing.
The advisory identifies consul-k8s 0.42.0 through 2.0.4, except fixed 1.8.18, with system ACL management enabled. An attacker able to create a ServiceAccount and obtain its token in another namespace, and reach the Consul API, can obtain a component's Consul privileges.
| Product | Safe from | Note |
|---|---|---|
| Consul Community Edition | 2.1.0 | Upgrade affected community installations |
| Consul Enterprise 2.x | 2.1.0 | Vendor-listed fixed release |
| Consul Enterprise 1.x | 1.21.19 | Vendor-listed fixed release; no separate 1.22 fix is listed |
| consul-k8s 2.x | 2.1.0 | Fix for component ACL binding rules |
| consul-k8s 1.x | 1.8.18 | Fix for component ACL binding rules |
Oct 26, 2026
HashiCorp publishes HCSEC-2026-46 through HCSEC-2026-50
Five advisories identify distinct attack prerequisites and fixed Consul, Enterprise and consul-k8s releases.
We list each claim and who made it. Primary sources (the vendor, the researcher, the registry) are marked. Where reports disagree, we grade by the worst credible case.