CVE-2026-87107 in Consul
Summary
by MITRE • 09/10/2026
Consul and Consul Enterprise are vulnerable to an authorization bypass in the catalog deregistration path that may allow a local ACL token to delete peer-imported catalog objects. A caller with {{service:write}} or {{node:write}} permission may exploit this issue to remove services, checks, or nodes imported from a peered cluster without holding authority over the peer origin. This vulnerability (CVE-2026-87107) is fixed in Consul 2.0.4 and Consul Enterprise 1.21.18, 1.22.12 and 2.0.4.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/10/2026
The HashiCorp Consul platform, a widely deployed service networking solution for managing microservices across dynamic distributed systems, contains a critical authorization bypass vulnerability within its catalog deregistration mechanism. This flaw specifically affects the handling of peer-imported catalog objects in both open-source Consul and Consul Enterprise editions. The core technical issue stems from an insufficient validation of access control list permissions during the deletion process for services, checks, or nodes that originate from a peered cluster rather than the local node. In a properly secured environment, operations on resources should strictly adhere to the ownership and permission boundaries defined by the originating authority. However, in this vulnerable state, the system fails to verify whether the caller possesses explicit authorization over the peer origin before allowing deregistration actions.
An attacker possessing an ACL token with service write or node write permissions for a specific local scope can exploit this logic error to delete catalog entries that were imported from another peered cluster. This capability exists even if the attacker holds no authority whatsoever over the remote peer's namespace or resources. The vulnerability effectively allows lateral movement of destructive actions across trust boundaries, undermining the isolation guarantees provided by Consul’s multi-datacenter and mesh networking features. By removing these critical infrastructure components, an adversary can disrupt service discovery, cause cascading failures in dependent services, and degrade the overall availability and reliability of the distributed application architecture.
From a security classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management, as it involves a failure to enforce proper access control policies for specific actions on protected resources. Furthermore, within the MITRE ATT&CK framework, this behavior is indicative of T1485 Data Destruction, where an adversary aims to destroy data or disrupt availability by removing critical system components. The attack vector typically requires local network access and valid credentials with write permissions, placing it in a medium complexity category for exploitation but resulting in high severity due to the potential impact on service continuity and integrity.
The operational impact of this vulnerability is significant for organizations relying on Consul for multi-cluster orchestration. It allows unauthorized deletion of critical infrastructure metadata, which can lead to service outages, failed health checks, and incorrect routing decisions by load balancers or ingress controllers that depend on accurate catalog data. In environments where strict compliance and audit trails are required, this bypass also represents a significant control failure, as actions taken under one set of credentials result in changes to resources governed by different administrative policies without proper authorization verification.
To mitigate this risk, organizations must immediately upgrade their Consul installations to version 2.0.4 for the open-source edition or versions 1.21.18 and 1.22.12 for Enterprise editions, with future releases also including patch 2.0.4 as noted in the advisory. Prior to upgrading, administrators should review ACL policies to ensure that write permissions are granted on a least-privilege basis, limiting scope to only necessary services or nodes. Additionally, implementing strict network segmentation and monitoring for unusual deregistration events can help detect potential exploitation attempts while patching efforts are underway. Regular auditing of peer connections and catalog synchronization logs is recommended to identify any unauthorized modifications resulting from this vulnerability in unpatched environments.