HashiCorp consul-k8s CVE-2026-110720

Requires a running consul-k8s deployment at version 0.42.0 or later (versions before 0.42.0 are not stated as affected; fixed in 2.1.0 and 1.8.18). Per CVSS PR:L the attacker must already hold some authenticated/low-level privilege in the environment rather than being fully unauthenticated, and the flaw specifically resides in component ACL binding rules spanning Kubernetes namespaces - so a multi-namespace Consul-on-Kubernetes configuration with component ACL binding rules in use is the operative prerequisite. Limiting factors: an existing low-privilege foothold is needed (not anonymous remote), and environments not using consul-k8s component ACL binding rules or still on pre-0.42.0 releases are outside the affected scope. The precise trigger for the bypass is not described in the available sources.

Signals align toward high priority but with important caveats. The vendor-supplied CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) describes a network-reachable, low-complexity flaw requiring some existing privilege (PR:L) that crosses a trust boundary (S:C) to yield full confidentiality, integrity and availability impact - consistent with a cross-namespace authorization bypass that lets an already-authenticated principal escalate to elevated Consul privileges. The vuln.today decision label is act_now, and HashiCorp is the reporting vendor (advisory HCSEC-2026-50), so the defect is confirmed by the originator. However, this is NOT confirmed active exploitation: the input shows no CISA KEV listing and no EPSS score, and the single reference is the HashiCorp discussion-forum advisory, not a published exploit - so there is no public exploit identified at time of analysis. The act_now label therefore rests on severity and the privilege-escalation nature rather than on observed in-the-wild activity; treat it as a patch-urgently item for anyone running consul-k8s, while recognizing the real-world threat is currently potential rather than demonstrated. EPSS is absent, so probabilistic exploitation likelihood cannot be compared against the KEV/POC signals.

An attacker who already holds limited, legitimate access within a Kubernetes cluster running consul-k8s (0.42.0 or later) abuses a flaw in how component ACL binding rules are evaluated across namespaces, causing Consul to grant them ACL tokens or permissions scoped beyond their own namespace. This yields elevated Consul privileges - potentially read/write over service-mesh configuration and secrets belonging to other namespaces. No public exploit code is identified at time of analysis; only the HashiCorp advisory is referenced.