nebula-mesh: Authorization Bypass in API Endpoints Enabling Cross-Operator Privilege Escalation

Vulnerability Description

The nebula-mesh API implements a broken access control pattern where authorization decisions rely solely on bearer token validation without enforcing per-resource ownership checks at the API layer. The vulnerability affects the /api/v1/* route surface across host, network, firewall, mobile-bundle, and operator endpoints. The root cause stems from delegating CA-ownership enforcement exclusively to the Web UI layer (loadAccessibleCA), leaving the API layer unprotected. In a multi-tenant architecture where each operator controls a distinct CA, this creates a critical isolation boundary failure: any operator key can perform privileged actions on resources belonging to other operators or administrative accounts.

PoC Significance

The disclosed proof-of-concept demonstrates two attack vectors: (1) API key escalation via the /api/v1/operators/{id}/api-keys endpoint, which lacks both admin-role and actor-ownership checks, and (2) cross-operator resource hijacking via host reenrollment endpoints. The PoC is deterministic and low-friction—requiring only network access to the API and a valid (low-privilege) operator bearer token. The attack succeeds because the endpoint handler does not validate that the requesting operator matches the target operator ID, and the codebase itself documents this gap at internal/api/hosts.go:384. Preconditions are minimal: any operator account in the system is sufficient.

Detection Guidance

Log Indicators:

• Repeated POST /api/v1/operators/{id}/api-keys requests from distinct operator contexts or with user IDs mismatched to the authorization header.
• Successful API-key creation followed immediately by API calls from the new key with elevated permissions (e.g., calls to admin-only endpoints).
• PUT /api/v1/hosts/{id}/enroll or reenrollment endpoints called by operators that do not own the target host CA.
• Audit logs showing API key generation for operator accounts other than the requester's own ID.

YARA/Detection Patterns:

• Monitor HTTP logs for POST requests to /api/v1/operators/*/api-keys where the Authorization header's operator ID (if extractable from token metadata) differs from the URI operator ID.
• Alert on Bearer token reuse anomalies: a low-privilege token suddenly issuing commands to privileged endpoints.

Mitigation Steps

1. Immediate (Pre-Patch): Implement API gateway rules to reject any /api/v1/operators/{id}/api-keys request where the caller's operator ID (decoded from the Bearer token) does not equal {id}. Similarly, gate host reenrollment to callers with ownership of the host's CA.
2. Patch: Upgrade to nebula-mesh v0.3.4 or later, which adds canAccessCA and actor-ownership validation to API endpoints.
3. Code Review: Audit all API endpoint handlers to ensure they validate resource ownership independently, not relying on UI-layer gates.
4. Configuration: Rotate all operator API keys after upgrading; revoke keys that may have been used to mint admin bearers during the vulnerability window.
5. Monitoring: Enable structured audit logging for all API-key creation and resource state-change events, with alerting on cross-tenant access patterns.

Risk Assessment

The likelihood of exploitation in the wild is high given the low barrier to entry (any operator key suffices) and the immediate, deterministic payoff (admin privilege in seconds). Multi-operator deployments of nebula-mesh are the primary target; isolated single-operator instances face reduced risk but are not immune if the operator account is compromised. Threat actors with initial low-privilege access to the nebula-mesh infrastructure (e.g., via phishing of an operator credential) have a direct path to full administrative control. The vulnerability aligns with MITRE ATT&CK T1098.003 (Modify Cloud Compute Credentials) and T1078.004 (Valid Accounts—Cloud Accounts), making it attractive to cloud-focused adversaries and insider threats. Public PoC availability post-disclosure will accelerate exploitation; patch deployment should be treated as urgent.