Consul 2.0.4: Intentions That Match Too Much and Catalog Takeovers

On 10 September 2026 HashiCorp published four Consul security bulletins, HCSEC-2026-34 to HCSEC-2026-37, fixed in Consul 2.0.4 and Consul Enterprise 1.21.18, 1.22.12 and 2.0.4. A fifth bulletin the same day, HCSEC-2026-38, fixed consul-template leaking Vault secrets into error messages. The service mesh one reaches furthest back: since Consul 1.9.0, the Envoy RBAC rules generated from intentions could match more service identities than the operator meant, so a service could reach a destination through an intention written for someone else.

What's affected

Fixed versions: Consul 2.0.4. Consul Enterprise 1.21.18, 1.22.12 and 2.0.4. consul-template 0.43.0.

The intentions bug. Consul enforces intentions by generating Envoy RBAC rules that match the caller's SPIFFE identity against patterns built from service names, namespaces and partitions. Some characters in those names weren't escaped, so the pattern matched a wider set of identities. The bulletin doesn't list the characters, but it says deployments whose catalog names don't contain them "are not impacted in practice". It needs Connect enabled with active intentions. Reported by ThanhDN of MBBank.

The node takeover. The catalog register endpoint didn't check that a token had permission over every node a write could affect. With node:write on any single node name and the node ID of a target, a caller could remove the target's registration, with its services and health checks, and take over its node identity. Deployments without ACLs, or where every operator already has unrestricted node:write, aren't affected.

The peering bug only affects clusters using cluster peering. Deletions hit the importing cluster's view, not the exporter's authoritative state, and the bulletin notes data may come back after the next replication update.

The RPC DoS needs a client that can reach port 8300 and complete the internal mTLS handshake, but no ACL token.

consul-template is used by Nomad and many sidecar setups to render Vault secrets into files. Some Vault response shapes slipped past its redaction, so secret values could show up in error messages, logs and, with Nomad, task events readable by anyone with job-read permission. KV v1-only deployments are not affected.

How to check if you're exposed

Server and agent versions across the cluster:

consul version
consul members   # the Build column shows each agent's version

Look for service names that use characters beyond lowercase letters, digits and hyphens. This is a heuristic, since the bulletin doesn't name the problem characters, but names outside that set are the ones to review first:

consul catalog services | grep -vE '^[a-z0-9-]+$'

Then list intentions and check which of them involve those names:

consul intention list

Check whether you use peering, which decides whether HCSEC-2026-36 matters:

consul peering list

For consul-template, check the version wherever it runs, including inside Nomad clients, which embed it:

consul-template -version

What to do now

1. Upgrade servers first, then clients, to Consul 2.0.4 or Enterprise 1.21.18, 1.22.12 or 2.0.4. Envoy RBAC rules are generated by Consul and pushed to proxies, so the corrected rules should arrive once the control plane is fixed. Confirm by checking a proxy's config after the upgrade.
2. Audit node:write grants. Tokens scoped to one node name were enough for the takeover. Make sure agent tokens are per node and that nobody outside operations holds node:write.
3. Keep the RPC port private. Port 8300 should only be reachable by Consul servers and agents. A firewall rule here makes HCSEC-2026-35 much harder to reach.
4. Upgrade consul-template to 0.43.0 and review logs and Nomad task events from failed template renders for secret values. Rotate anything you find. Nomad's template block uses consul-template as a library, so check your Nomad release notes for the version it ships.
5. Treat intentions as deny-by-default. Use a default deny intention and explicit allows. It doesn't fix this bug, but it keeps an overly broad match from being the only thing between two services.

Why it matters

Service mesh authorization is only as precise as the rules the control plane generates. Operators write intentions in names, Envoy enforces patterns, and anything lost in translation becomes access nobody granted. The same class of bug shows up in policy engines and ingress controllers: a value pasted into a pattern without escaping becomes part of the pattern.

The catalog bugs are a reminder that service discovery is a security boundary too. If a token scoped to one node can delete another node's registration and take its identity, traffic meant for that node can be redirected. Scope tokens to exactly what each agent needs, and watch for registrations that change hands.

Try it yourself

Run the service name check above against one Consul datacenter. For each name it prints, list the intentions that reference it and write down which callers you expect to be allowed. After upgrading a staging cluster to 2.0.4, test a call from a service that should be denied and confirm it fails.

Quick check

Sources

• HCSEC-2026-37: Consul authorization bypass in the Connect service mesh
• HCSEC-2026-34: Consul authorization bypass in the catalog node-write path
• HCSEC-2026-36: Consul authorization bypass in the catalog deregistration path
• HCSEC-2026-35: Consul denial of service in the native RPC listener
• HCSEC-2026-38: consul-template information disclosure in error handling