GHSA-7RX3-5WX3-5V76: Root-cause authz fix for webhook allow_private SSRF bypass

Vulnerability

The advisory describes a missing authorization check in Nebula-mesh's webhook subscription API: non-admin operators could set allow_private, which opts a delivery target out of the SSRF guard and permits private, loopback, or link-local destinations. That creates an SSRF primitive against internal services because the parameter effectively switches webhook delivery into a less restricted path. The issue is documented in the GitHub Security Advisory and reflected in the patch commit notes and tests. See GHSA-7RX3-5WX3-5V76 and the fixing commit f3c54530e388dd21763e548923426e60a8e93ff0.

Source-grounded evidence is strongest in the added regression test, which states that allow_private "switches the dispatcher to the unguarded HTTP client and bypasses the private/loopback/link-local rejection," and verifies that a non-admin user previously capable of normal webhook operations must now receive 403 when attempting to enable that flag.

Patch

The patch introduces an explicit admin authorization gate in the webhook API handler before processing requests with allow_private=true. The same guard appears on both relevant request paths in internal/api/webhooks.go, matching the create and update coverage added in tests. The OpenAPI description and user-facing webhook documentation were also updated to declare that allow_private is admin-only and that non-admin operators receive 403.

if req.AllowPrivate && !s.isActiveAdmin(r.Context()) {
	writeError(w, http.StatusForbidden, "allow_private requires the admin role")
	return
}

The regression test in the commit validates three important cases: non-admin create with allow_private is rejected with 403, non-admin create without the flag still succeeds for a public URL, and non-admin update of an owned subscription to enable allow_private is also rejected with 403.

Review

Pros

• The fix addresses the actual trust-boundary failure: authorization is now enforced on the dangerous capability rather than relying only on network-target validation.
• The control is narrow and low-risk: only requests that set allow_private are blocked for non-admins, preserving existing non-admin webhook functionality for public destinations.
• Regression coverage is good for the disclosed exploit path, explicitly testing both create and update operations for a non-admin principal.
• API contract and documentation were updated alongside code, reducing ambiguity for clients and operators. See commit reference.

Cons

• The provided snippet shows duplicated authorization logic in internal/api/webhooks.go. While likely intentional across separate handlers, this pattern can drift over time unless centralized.
• The patch evidence is scoped to allow_private on webhook subscriptions. Based on the available sources, it does not demonstrate a broader audit for equivalent SSRF opt-out flags or alternate webhook mutation paths elsewhere in the codebase.
• The tests assert HTTP status outcomes but, from the provided snippets, do not verify persistence invariants such as ensuring the stored subscription state cannot retain or inherit allow_private through partial updates or omitted fields.

Verdict

Root-cause.

This is a root-cause fix because the vulnerability was an authorization gap on a privileged SSRF-bypass control, and the patch directly restores that missing authorization check at the API boundary. The change is consistent across code, tests, and API/docs, and the regression cases align with the advisory's exploitation model described in the GHSA. Based on the supplied sources, the patch is technically sound and appropriately targeted.