CVE-2026-115804: 
Consul vulnerability analysis and mitigation

CVE-2026-115804 is an authorization bypass vulnerability in HashiCorp Consul and Consul Enterprise affecting health check registration. It allows an authenticated user with low privileges to modify health checks belonging to another service on the same node. The vulnerability affects Consul and Consul Enterprise versions 0.7.2 through 2.1.0 (exclusive), and was disclosed on October 26, 2026. It carries a CVSS v3.1 base score of 6.4 (Medium) (GitHub Advisory, Feedly).

The root cause is classified as CWE-639 (Authorization Bypass Through User-Controlled Key), where the health check registration logic fails to validate that the requesting service owns the health check being modified. An authenticated attacker on the same Consul node can supply a user-controlled key (e.g., a service or check identifier) to reference and alter health checks belonging to a different service. The attack vector is network-based, requires low privileges (valid authentication), no user interaction, and has a changed scope — meaning the impact extends beyond the vulnerable component to affect other services on the node (GitHub Advisory, HashiCorp Advisory).

A successful exploit allows an authenticated low-privilege user to alter the health status of services they do not own on the same Consul node, with low integrity and low availability impact and no confidentiality impact. This can corrupt service discovery and routing decisions within the Consul service mesh, potentially causing legitimate services to be marked unhealthy (availability disruption) or routing traffic to unintended endpoints (integrity degradation). While lateral movement to other nodes is not directly enabled, manipulation of health checks could be leveraged to redirect traffic or cause denial of service for specific services in a multi-tenant or shared-node deployment (GitHub Advisory, Feedly).

As of the disclosure date, there is no public proof-of-concept exploit and no evidence of in-the-wild exploitation (Feedly). The EPSS score is 0.0, indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. NVD's SSVC assessment classifies exploitation as "none" and technical impact as "partial," and the attack is not automatable due to the requirement for authenticated access (GitHub Advisory).

1. Authentication: Obtain valid credentials or a token for a low-privilege user or service account registered on the target Consul node.
2. Enumerate services: Use the Consul API (e.g., GET /v1/health/node/<node>) to list services and their associated health checks on the same node.
3. Identify target health check: Note the check ID belonging to a different service that the attacker does not own.
4. Craft malicious request: Submit a health check registration or update API request (e.g., PUT /v1/agent/check/register or PUT /v1/agent/check/update/<checkID>) using the target service's check ID as the user-controlled key, bypassing ownership validation.
5. Manipulate health status: Set the health check status to a desired value (e.g., critical to mark the target service unhealthy, or passing to force routing to a compromised service), disrupting service discovery and routing (HashiCorp Advisory, GitHub Advisory).

• Logs: Consul agent logs showing health check update or registration API calls where the requesting service token does not match the owning service of the check ID; repeated PUT /v1/agent/check/update/<checkID> or PUT /v1/agent/check/register requests from unexpected service identities.
• Network: Unusual API calls to Consul health check endpoints originating from service accounts that do not own the referenced check IDs; unexpected changes in service health status visible via GET /v1/health/node/<node>.
• Audit Logs: If Consul audit logging is enabled, entries showing cross-service health check modifications where the actor token's service does not correspond to the check's registered service.

HashiCorp has released patches addressing this vulnerability: upgrade to Consul Community Edition 2.1.0 or Consul Enterprise 2.1.0 or Consul Enterprise 1.21.19 (HashiCorp Advisory, GitHub Advisory). No specific configuration-based workaround has been published; upgrading to a patched version is the recommended remediation. As an interim measure, administrators should audit health check configurations and review Consul ACL policies to restrict service token permissions as tightly as possible, and enable Consul audit logging to detect unauthorized health check modifications (IBM Advisory).

HashiCorp published an official security advisory (HCSEC-2026-49) on their community forum detailing the vulnerability and fix (HashiCorp Advisory). IBM also issued a security bulletin for customers using Consul in IBM-managed environments (IBM Advisory). No notable independent researcher commentary or significant social media discussion has been observed as of the disclosure date.