Nebula Claw Developer
SuspiciousAudited by ClawScan on May 10, 2026.
Overview
Review recommended: the skill matches its VM-management purpose, but it can create and hard-delete VMs through a control-plane API whose documented setup leaves authentication, credential handling, and cleanup controls under-scoped.
Use this only with a strongly restricted, authenticated API endpoint. Confirm that template allowlists are enforced server-side, admin credential overrides are disabled, VM names are validated, destructive deletes require user approval, and TTL cleanup is configured.
Findings (4)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
A bad or manipulated VM name/template argument could create an unintended request, and delete calls can terminate the wrong VM if the target is ambiguous.
The helper can create and delete VMs using task-provided arguments, but it does not JSON-encode the create parameters, URL-encode the delete target, or require confirmation before high-impact VM deletion.
curl -s -X POST "$NEBULA_CLAW_DEVELOPER_API_BASE/vms" ... -d "{\"template_name\":\"$template_name\",\"name\":\"$vm_name\"}" ... curl -s -X DELETE "$NEBULA_CLAW_DEVELOPER_API_BASE/vms/$vm_ref"Validate VM names and template names against a strict allowlist, encode JSON and URL path values safely, and require explicit user approval before delete operations.
If broader OpenNebula credentials are supplied, the agent could operate with more privilege than the restricted disposable-VM workflow intends.
The API contract allows OpenNebula credentials to be supplied in a VM-create request even though the skill is described as using a restricted control plane and the metadata declares no primary credential.
Optional OpenNebula credential override for testing: ... "one_user": "restrictedapi", "one_password": "change-me"
Remove or disable credential override in normal use, never pass admin credentials through this API, and declare any required credential contract clearly.
If the API is reachable by other users or systems, they may be able to create or hard-delete VMs, and credentials may be exposed in configuration.
Authentication, secret storage, and network exposure controls for the VM control-plane API are documented as future hardening rather than baseline requirements.
Follow-up hardening - Move the password out of JSON config. - Add API authentication. - ... Restrict bind address and network exposure according to the deployment.
Require API authentication before use, bind the service only to trusted interfaces, use TLS or a trusted local channel, and store OpenNebula credentials in a secret manager rather than JSON.
A VM left running can consume resources and may continue hosting any experiments or services started during the task.
Automatic TTL cleanup is listed as a future hardening step, so disposable VMs can persist if the agent or user does not delete them.
- Add TTL-based cleanup for disposable VMs.
Configure TTL-based cleanup and verify each created VM is destroyed or intentionally retained.