CVE-2026-87090 in Consul
Summary
by MITRE • 09/10/2026
Consul and Consul Enterprise are vulnerable to an authorization bypass in the catalog node-write path that may allow an authenticated attacker to delete another node's catalog registration and take over its node identity. An attacker with a token granting node-write permission on any single node name may exploit this issue if they can obtain the node ID of a node they do not control. This vulnerability (CVE-2026-87090) is fixed in Consul 2.0.4 and Consul Enterprise 1.21.18, 1.22.12 and 2.0.4.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/10/2026
The HashiCorp Consul service discovery and configuration platform contains a critical authorization bypass vulnerability within its catalog node-write API endpoint, identified as CVE-2026-87090. This flaw stems from an insufficient validation mechanism in the server-side processing of registration requests for nodes. Specifically, while the access control system correctly verifies that an authenticated user possesses write permissions for a specific node name, it fails to adequately verify that the requestor is authorized to modify or delete data associated with the unique internal identifier (node ID) of that target node. In Consul's architecture, each registered agent is assigned a globally unique node ID which serves as the primary key for catalog entries and health checks. The vulnerability arises because the authorization logic relies solely on the human-readable node name rather than enforcing strict binding between the permission scope and the immutable node identifier during write operations.
An attacker who has been granted token-based permissions to perform node-write actions on any single node can exploit this logical flaw if they are able to discover or obtain the node ID of a different target node that is not under their control. By crafting a malicious API request that targets the victim's node name but includes the victim's unique node ID, the attacker can trick the Consul server into accepting the modification as valid for the authorized node name while effectively operating on the unauthorized target. This allows the authenticated attacker to delete or overwrite the catalog registration of another agent in the cluster without possessing explicit permissions for that specific entity. The exploitation does not require privilege escalation beyond existing low-level write access, making it accessible to compromised services with minimal privileges within a multi-tenant environment.
The operational impact of this vulnerability is severe, as it enables an attacker to take over the identity of another node in the service mesh or infrastructure-as-code ecosystem. By deleting or altering the catalog registration, the attacker can disrupt health checks associated with legitimate nodes, causing them to be marked as unhealthy and removed from load balancers or routing tables. This leads directly to denial-of-service conditions for critical services relying on Consul for discovery. Furthermore, if an attacker replaces a node's registration data, they may inject malicious service definitions that redirect traffic to compromised infrastructure, facilitating man-in-the-middle attacks or data exfiltration. The ability to impersonate nodes undermines the integrity of the entire distributed system, as downstream components trust catalog entries implicitly based on their registered state.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management and CWE-754 Improper Check for Unusual or Exceptional Conditions within access control systems. It also maps to MITRE ATT&CK techniques related to Defense Evasion via Masquerading (T1036) and Account Manipulation, as the attacker manipulates system identities to bypass security controls. The root cause is a logical error in how permissions are scoped against resource identifiers rather than just display names or labels.
Mitigation requires immediate patching of all affected Consul installations to version 2.0.4 for open-source users, and versions 1.21.18, 1.22.12, or 2.0.4 for Enterprise customers where applicable. Organizations should audit their ACL token policies to ensure that node-write permissions are granted on a least-privilege basis, restricting write access only to nodes strictly necessary for operational functions. Additionally, implementing strict network segmentation and monitoring API call patterns can help detect anomalous behavior indicative of exploitation attempts before significant damage occurs. Regular rotation of tokens and review of catalog entries against expected infrastructure states provide additional layers of defense against such identity-based attacks.