CVE-2026-63464 in Nebula Mesh
Summary
by MITRE • 09/04/2026
nebula-mesh is a self-hosted control plane for Slack Nebula mesh VPN. From version 0.6.0 to before version 0.7.2, non-admin operators (role user) can set allow_private: true on their own managed webhook subscription (POST/PATCH /api/v1/webhook-subscriptions). No admin check exists on this field. At delivery time, allow_private switches the dispatcher to an unguarded HTTP client, bypassing the private/loopback/link-local SSRF guard — letting a low-privilege operator make the server request internal addresses. This issue has been patched in version 0.7.2.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/04/2026
The vulnerability identified within nebula-mesh versions ranging from 0.6.0 to just prior to 0.7.2 represents a critical authorization bypass that facilitates Server-Side Request Forgery attacks against internal network infrastructure. Nebula-mesh serves as the self-hosted control plane for Slack's Nebula mesh VPN, managing connectivity and security policies across distributed environments. The core technical flaw resides in the API endpoint responsible for creating or updating webhook subscriptions, specifically through POST and PATCH requests to /api/v1/webhook-subscriptions. While the system implements role-based access controls that restrict administrative privileges to specific users, it fails to enforce these restrictions on a single configuration field known as allow_private. This boolean flag is intended to determine whether the underlying HTTP dispatcher should permit connections to private IP ranges, loopback addresses, and link-local networks.
In a properly secured implementation, any modification of security-critical settings such as allow_private would require administrative privileges due to its direct impact on network isolation boundaries. However, in the affected versions, non-admin operators with the user role are able to set this field to true without triggering an authorization check. This oversight effectively downgrades the HTTP client used by the webhook dispatcher from a restricted mode that blocks internal requests to an unguarded state capable of reaching any address reachable by the host machine. By manipulating this parameter, a low-privilege actor can instruct the server to initiate outbound connections to arbitrary destinations within the private network space. This mechanism bypasses existing SSRF guards designed to prevent external entities from probing or interacting with internal services that are not exposed to the public internet.
The operational impact of this vulnerability is severe, as it allows an attacker who has compromised a standard user account to perform reconnaissance and exploitation against internal assets. An adversary could utilize this capability to scan for vulnerable services running on localhost, access cloud metadata endpoints such as AWS EC2 instance metadata service or Azure managed identity endpoints, or interact with other microservices within the mesh network that rely on private IP addressing for security. This effectively neutralizes a key layer of defense-in-depth, allowing lateral movement and potential data exfiltration from systems that were previously considered safe from external web-based attacks. The flaw aligns closely with CWE-269 Improper Privilege Management, as it involves the failure to enforce required privileges before performing an action, and is also indicative of CWE-918 Server-Side Request Forgery due to the ability to force the server into making unintended requests.
From a threat intelligence perspective, this vulnerability maps to MITRE ATT&CK technique T1557 Adversary-in-the-Middle or more specifically T1046 Network Service Discovery if used for scanning, and potentially T1078 Valid Accounts if leveraged by an attacker who has already obtained user credentials. The exploitation path is straightforward given the RESTful nature of the API, requiring only a simple HTTP request with the allow_private flag set to true followed by subsequent webhook triggers or direct configuration changes depending on how the dispatcher processes new subscriptions. To mitigate this risk, organizations running affected versions must immediately upgrade to version 0.7.2 where the authorization check for the allow_private field has been implemented. Until an upgrade is possible, network segmentation strategies should be reviewed to ensure that critical internal services are not accessible from the host machine's loopback interface or private subnets via HTTP endpoints exposed by nebula-mesh. Additionally, implementing strict input validation and enforcing role-based access control checks on all configuration parameters related to security boundaries is essential for preventing similar authorization bypasses in future updates.