Database/Container, Kubernetes & orchestration

Consul: service write permission is enough to apply Envoy escape-hatch proxy configuration

CVSS 8.8CVE-2026-105608Container, Kubernetes & orchestrationcurated

Impact

Consul and Consul Enterprise fail to enforce mesh write on proxy registration, so a principal holding only service write can inject Envoy escape-hatch configuration - raw Envoy config that the mesh operator intended to require a higher privilege. Escape-hatch config controls listeners, clusters and filters, which is the machinery that keeps mesh traffic authenticated and separated, so the holder of a single service token can reshape how that proxy terminates and forwards traffic. In a shared cluster where the mesh carries traffic between tenants or between a serving tier and internal control services, that is an authorization boundary crossing performed with ordinary workload credentials rather than operator ones.

Who can reach it

Anyone authenticated to the Consul API with service write permission on a service - typically a workload token, not an operator token. Network reach to the Consul API or an agent is required.

What to do

Upgrade to Consul Community Edition 2.1.0, or Consul Enterprise 2.1.0 or 1.21.19. This is a rolling upgrade of Consul servers and agents, not a node reboot; until it is done, audit who holds service write and review existing proxy registrations for escape-hatch fields.

References

https://nvd.nist.gov/vuln/detail/CVE-2026-105608 https://discuss.hashicorp.com/t/hcsec-2026-47-consul-vulnerable-to-an-authorization-bypass-in-service-mesh-registration/77912

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.