Node Red Manager
SuspiciousAudited by ClawScan on May 10, 2026.
Overview
This skill matches Node-RED administration, but it uses broad admin credentials and can change, delete, install, and persist Node-RED behavior without clear scoping or approval safeguards.
Only install this if you intentionally want an agent to administer a specific Node-RED instance. Before use, verify the target URL, credentials, and Docker service; back up flows; review any flow JSON before deployment, especially flows with exec nodes; and require explicit approval for delete, restore, install-node, context, or runtime-state changes.
Findings (6)
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.
If pointed at a real or production Node-RED instance, the agent could act with broad admin privileges over flows, nodes, and runtime settings.
The script authenticates to Node-RED using admin username/password and requests a wildcard API scope. The registry metadata declares no required env vars or primary credential, making this broad admin authority under-declared.
"scope": "*", "username": self.username, "password": self.password
Declare the credential requirements, prefer least-privileged tokens if available, require explicit target confirmation, and avoid storing broad admin passwords unless necessary.
A mistaken or overly autonomous invocation could alter or remove automations, install third-party Node-RED modules, or change shared runtime state.
The skill exposes high-impact Node-RED administration actions, including deployment, deletion, restore, node package installation/removal, and global context mutation, without documented approval or rollback safeguards.
scripts/nr deploy --file assets/flows/watchdog.json ... scripts/nr delete-flow <flow-id> ... scripts/nr restore ... scripts/nr install-node <module> ... scripts/nr remove-node <module> ... scripts/nr set-context global config
Require explicit user approval for destructive or persistent changes, back up flows before mutation, restrict allowed modules/targets, and clearly separate read-only troubleshooting from write operations.
If deployed without review, the Node-RED instance will keep running a shell command on a schedule after the original task is complete.
The provided example flow uses a Node-RED exec node to run a host command every 5 seconds. The command is benign, but deploying this file creates persistent command execution on the Node-RED host.
"type": "exec", "command": "uptime -p", "repeat": "5"
Clearly warn before deploying flows containing exec/function nodes, require user review of flow JSON, and avoid making command-executing flows a default example.
Reading or changing global/flow context can expose stored data or alter how automations behave later.
The tool can read and write Node-RED context stores. This is purpose-aligned, but context may contain sensitive values or persistent state that future flows rely on.
def get_context(self, store: str, key: str) ... return self._make_request("GET", f"/context/{store}/{key}") ... def set_context(self, store: str, key: str, value: Any)Only access explicitly named context keys, avoid storing secrets in context, and require confirmation before changing global or persistent values.
The skill may not run as documented, or users may need to rely on unreviewed setup behavior to make it work.
The instructions reference `.env.example` and `scripts/nr`, but those files are not present in the manifest, and first-run dependency handling is described without an install spec. This is a packaging/provenance gap rather than proof of malicious behavior.
Copy `.env.example` to `.env` ... The script automatically handles dependencies on first run ... scripts/nr list-flows
Include all referenced helper files, document dependency installation explicitly, and pin dependency versions.
An agent or user could be confused about which Node-RED instance or Docker service is being managed.
A generally described Node-RED manager includes project-specific infrastructure names and a public URL. This may be benign reuse, but users should not assume it targets their own instance without checking configuration.
Docker Service: `mema-node-red` ... URL: `https://flow.glassgallery.my.id`
Remove project-specific defaults or make them clearly optional examples, and require users to confirm the intended Node-RED URL and service name before any write action.