Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.7",
  "pubDate": "2026-09-04T20:17:24.730Z",
  "pubdate": "2026-09-04T20:17:24.730Z",
  "executiveSummary": "A Server-Side Request Forgery (SSRF) vulnerability exists in nebula-mesh versions 0.6.0 through 0.7.1. The flaw allows authenticated, low-privilege users with the 'user' role to manipulate the internal HTTP client configuration for webhook subscriptions. By explicitly setting the 'allow_private' parameter to 'true' within the POST or PATCH /api/v1/webhook-subscriptions endpoint, a malicious actor can bypass existing security controls designed to restrict requests to internal, loopback, and link-local network ranges. This elevates the risk of unauthorized internal network scanning, interaction with sensitive metadata services, or exploitation of internal-only APIs that lack secondary authentication. Successful exploitation requires valid user-level credentials, making the risk profile dependent on the security posture of the authentication mechanism and the internal network architecture accessible from the nebula-mesh server environment.",
  "technicalDetails": "The vulnerability originates from an improper access control implementation within the /api/v1/webhook-subscriptions endpoint of nebula-mesh. Specifically, the API lacks a server-side authorization check to validate the 'allow_private' Boolean field during the creation or modification of webhook subscription objects. While the application intends to restrict the dispatcher's HTTP client to public, routable IP addresses to mitigate SSRF, the 'allow_private' flag effectively toggles the security policy of the underlying request dispatcher.\nWhen a user with the 'user' privilege level sends a crafted POST or PATCH request, they can include 'allow_private: true' in the payload. The application fails to strip or reject this parameter for non-administrative roles, persisting the setting in the database. During the subsequent asynchronous delivery phase, the webhook dispatcher consumes this configuration. Upon encountering the 'allow_private' flag set to true, the dispatcher initializes or configures its HTTP client to bypass the integrated SSRF guard, which would otherwise prevent requests targeting private ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.1/8) or link-local addresses.\nThe attack flow is as follows: 1) An attacker authenticates as a standard user. 2) The attacker submits an API request to /api/v1/webhook-subscriptions containing the payload 'allow_private: true'. 3) The server processes the subscription object without validating the user's authority to override security defaults. 4) The attacker configures the webhook destination URL to point to a sensitive internal resource, such as 'http://169.254.169.254/latest/meta-data/' or an internal management console. 5) The dispatcher triggers the webhook, utilizing the permissive HTTP client to successfully route the request to the internal destination. 6) The server returns the result of the internal request, potentially exposing sensitive data or enabling unintended actions within the internal network segment. This flaw allows a low-privilege attacker to act as a pivot point for lateral movement or information gathering against the local infrastructure, bypassing the intended network boundary isolation."
}