Mission Control

• Outcome: Review
• Latest audit: Sep 10, 2026 · 11:17 AM UTC
• Version: 1.0.0

Overview

The skill describes a plausible OpenClaw dashboard, but its setup runs unpinned remote code, uses OpenClaw gateway credentials, and offers root-level persistent service installation without enough scoping.

Review the external repository and service file before installing, prefer a pinned release or commit, use npm ci with lockfiles where available, avoid enabling the system service until you confirm it runs as an unprivileged local-only service, and use a dedicated least-privilege OpenClaw token rather than a primary gateway credential.

A.I.G

Vulnerability Patterns

• Remote Payload Retrieval and Execution: Fetches external code whose behavior can change after review
• Unauthorized Access and Privilege Escalation: Obtains permissions beyond the task's legitimate needs
• System Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Skill Instruction Hijacking: Alters the agent's session goals or safety constraints when the skill loads
• Agent Memory Poisoning: Writes attacker-controlled rules into memory that affect later sessions

Findings (3)

T03 · Remote Payload Retrieval and Execution

Error

• Location: SKILL.md:14
• Finding: Unpinned Remote Code and Dependencies Are Retrieved and Executed<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 14–25 **Vulnerability Type**: Remote payload retrieval and insecure software supply chain **Risk Level**: High ### Vulnerable Code ```bash # Clone the repo into your workspace cd "$CLAWD_WORKSPACE" 2>/dev/null || cd ~/clawd git clone https://github.com/Jzineldin/mission-control.git cd mission-control # Install dependencies + build frontend npm install cd frontend && npm install && npm run build && cd .. # Create your config cp mc-config.default.json mc-config.json # Start (dev) node server.js ``` ### Technical Analysis The installation procedure clones the current default branch of an external Git repository without pinning a reviewed commit, release, or signed tag. It subsequently runs `npm install` for two dependency trees, executes a frontend build, and starts the downloaded server. The effective payload can therefore change after the Skill itself has been reviewed. In addition, npm installation may execute package lifecycle scripts such as `preinstall`, `install`, and `postinstall`, which can run arbitrary commands with the installing user's privileges. The instructions do not require checksum or signature verification, lockfile-enforced installation through `npm ci`, dependency auditing, or inspection of lifecycle scripts. The remotely downloaded source code and dependency manifests were not included in the audited artifact, so their behavior could not be verified. ### Attack Path 1. An attacker compromises the remote repository, a maintainer account, or an npm dependency. 2. The attacker adds malicious application code or an npm lifecycle script. 3. A user follows the Skill instructions and clones the mutable default branch. 4. `npm install`, `npm run build`, or `node server.js` executes the modified payload. 5. The payload runs with the user's permissions and can access files available to that account, including OpenClaw configuration data. 6. If the user subsequently ena ...[truncated 594 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Pin the cloned source to a reviewed commit hash or cryptographically signed release tag. - Publish and verify checksums or signatures before executing downloaded files. - Include the relevant source code, dependency manifests, lockfiles, and service definition in the reviewed Skill artifact. - Use committed lockfiles and `npm ci` rather than unconstrained `npm install`. - Use `npm ci --ignore-scripts` where lifecycle scripts are unnecessary. - If lifecycle scripts are required, document and review each script before installation. - Run dependency auditing and software composition analysis as part of release validation. - Perform installation and builds in an isolated, unprivileged environment with no access to OpenClaw credentials. - Separate software installation from credential configuration so unverified installation scripts cannot access sensitive tokens. ]]>

T06 · System Persistence

Error

• Location: SKILL.md:28
• Finding: Unaudited Remote Application Is Registered as a Persistent System Service<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 28–33 **Vulnerability Type**: System-wide persistent service registration **Risk Level**: High ### Vulnerable Code ```bash # Or use systemd for production: sudo cp mission-control.service /etc/systemd/system/ # Edit paths in the service file, then: sudo systemctl enable --now mission-control ``` ### Technical Analysis The instructions use `sudo` to copy a service definition obtained from the mutable external repository into `/etc/systemd/system/`, then enable and immediately start it. Enabling the unit causes its configured process to execute across system reboots. Persistent operation may be useful for a production dashboard, and the document presents systemd as an alternative to development execution. However, the service file is not included in the audited artifact. Its executable path, service account, environment variables, filesystem access, Linux capabilities, restart behavior, and systemd sandboxing controls cannot be verified. A system-wide service is not the minimum privilege required to run a local web dashboard. A foreground process or user-level systemd service would satisfy the basic functionality without writing to a root-controlled system directory. If the unit lacks an explicit restricted `User=`, it may run with root privileges by default. ### Attack Path 1. An attacker modifies the remote `mission-control.service` file or the application that the unit starts. 2. A user clones the repository and follows the production setup instructions. 3. The user authorizes `sudo cp`, placing the attacker-controlled unit in a root-managed systemd directory. 4. `sudo systemctl enable --now mission-control` immediately launches the configured command and enables startup execution. 5. The malicious process continues to execute across reboots. 6. If the unit runs as root or has broad filesystem access, the attacker obtains system-level access; otherwise, the attacker retains the pe ...[truncated 592 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Include the complete service unit in the Skill artifact so it can be reviewed with the installation instructions. - Prefer a user-level systemd service under `~/.config/systemd/user/` when system-wide execution is unnecessary. - Create a dedicated, unprivileged service account with no interactive login. - Explicitly set `User=` and `Group=` in any system-level service unit. - Apply systemd hardening directives such as: - `NoNewPrivileges=true` - `ProtectSystem=strict` - `ProtectHome=true` or narrowly scoped exceptions - `PrivateTmp=true` - `PrivateDevices=true` - `RestrictSUIDSGID=true` - `CapabilityBoundingSet=` - `RestrictAddressFamilies=` limited to required protocols - `ReadWritePaths=` limited to necessary application directories - Pin and verify both the service definition and its executable before installation. - Display and require explicit review of the resolved service unit before copying or enabling it. - Document safe disablement and removal commands. - Avoid running the dashboard as root and bind it only to the required local interface. ]]>

T05 · Unauthorized Access and Privilege Escalation

Warning

• Location: SKILL.md:59
• Finding: Dashboard Automatically Accesses the OpenClaw Gateway Credential<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 59–62 **Vulnerability Type**: Sensitive credential access with unspecified handling controls **Risk Level**: Medium ### Vulnerable Code ```markdown Auto-detected from your OpenClaw setup: - Gateway token from `~/.openclaw/openclaw.json` - Agent name from `IDENTITY.md` - Model + channels from OpenClaw config ``` The behavior is also introduced at line 37: ```markdown Visit `http://localhost:3333` — the Setup Wizard auto-detects your OpenClaw config. ``` ### Technical Analysis The dashboard automatically reads the OpenClaw gateway token and other configuration information from the user's home directory. Access to a gateway credential is relevant to the dashboard's declared management functions, but it materially increases the consequences of compromise. The implementation is not present in the audited artifact, so it is not possible to verify whether the token remains exclusively in server-side memory, is persisted securely, is redacted from logs, or is exposed to frontend JavaScript. It is also not possible to confirm whether the dashboard uses authentication, CSRF defenses, strict origin controls, or loopback-only network binding. This finding concerns excessive credential exposure and insufficiently documented privilege boundaries. The documentation does not state that a narrowly scoped dashboard credential is used or that explicit consent is required before reading the primary OpenClaw token. ### Attack Path 1. The user installs and launches the dashboard. 2. The Setup Wizard reads `~/.openclaw/openclaw.json` and obtains the gateway token. 3. A compromised dependency, malicious remote update, server vulnerability, frontend exposure, or insecure logging path gains access to the token. 4. An attacker extracts and reuses the credential against the OpenClaw gateway. 5. The attacker exercises whichever capabilities the gateway token authorizes, potentially including access to conver ...[truncated 556 chars]
• Remediation: <![CDATA[ ## Remediation Suggestions - Require explicit user consent before reading OpenClaw configuration or credentials. - Use a dedicated, revocable, least-privilege dashboard token instead of the primary gateway credential. - Limit the token to only the API operations required by enabled dashboard features. - Keep credentials exclusively in server-side memory where feasible. - Never include the gateway token in frontend bundles, browser storage, URLs, telemetry, error messages, or application logs. - Bind the dashboard to the loopback interface by default. - Require strong dashboard authentication and implement CSRF and strict origin protections. - Set restrictive permissions on configuration files and credential storage. - Document credential storage, rotation, revocation, and incident-response procedures. - Isolate the dashboard service so it can read only the specific required configuration files. - Include the credential-handling implementation in the auditable artifact and test it for accidental token disclosure. ]]>

SkillSpector

Vulnerability Patterns

• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Rogue Agent: Self-Modification, Session Persistence
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (4)

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

node server.js

# Or use systemd for production:
sudo cp mission-control.service /etc/systemd/system/
# Edit paths in the service file, then:
sudo systemctl enable --now mission-control
```

• Confidence: 76% confidence
• Finding: The documentation instructs users to run sudo cp mission-control.service /etc/systemd/system/, which requires root privileges and installs files into a privileged system location. While common for service setup, asking users to elevate privileges for a repository-cloned artifact expands the blast radius if the service file or surrounding project contents are malicious or modified.

Sudo/Root Execution

Medium

• Category: Privilege Escalation

Content

# Or use systemd for production:
sudo cp mission-control.service /etc/systemd/system/
# Edit paths in the service file, then:
sudo systemctl enable --now mission-control
```

Visit `http://localhost:3333` — the Setup Wizard auto-detects your OpenClaw config.

• Confidence: 79% confidence
• Finding: The command sudo systemctl enable --now mission-control starts the service immediately and configures it to run with persistence under system control, requiring elevated privileges. In the context of a dashboard that controls an agent and auto-detects local credentials, enabling it as root-backed infrastructure makes accidental overexposure or misuse more consequential.

Session Persistence

Medium

• Category: Rogue Agent

Content

# Or use systemd for production:
sudo cp mission-control.service /etc/systemd/system/
# Edit paths in the service file, then:
sudo systemctl enable --now mission-control
```

Visit `http://localhost:3333` — the Setup Wizard auto-detects your OpenClaw config.

• Confidence: 84% confidence
• Finding: systemctl enable --now establishes persistence so the dashboard will restart automatically, which is a recognized persistence mechanism. Persistence is not inherently malicious, but in this context it is security-relevant because the service offers monitoring/control features and may auto-consume a gateway token, so compromise or misconfiguration would survive reboots and continue exposing access.

Missing User Warnings

Medium

• Confidence: 94% confidence
• Finding: The skill explicitly states that the Setup Wizard auto-detects local OpenClaw configuration and the configuration section says it reads the gateway token from ~/.openclaw/openclaw.json, but the install/usage text does not warn users that a sensitive local credential will be discovered and used by the dashboard. Because this is a web dashboard that can monitor and control the agent, silent ingestion of the gateway token materially increases the risk of unauthorized local control, credential exposure, or accidental over-trust by the user.

Static analysis

No suspicious patterns detected.