ClawHub
Back to skill

Security audit

Test

Security checks for vulnerabilities and agentic risk

Overview

This skill is for a monitoring API, but it documents a persistent service that can expose sensitive OpenClaw and host status data without documented access controls.

Install only if you intend to run a private operator-facing monitoring service. Before using it, review the missing server implementation, bind it to localhost or protect it behind authentication, disable collectors you do not need, avoid loginctl linger unless necessary, and add clear removal and hardening steps.

A.I.G

Vulnerability Patterns
  • System PersistenceInstalls backdoors, hooks, services, or scheduled tasks that survive the run
  • Insecure Skill Coding PracticesFinds exploitable flaws such as hardcoded secrets or command injection
  • Skill Instruction HijackingAlters the agent's session goals or safety constraints when the skill loads
  • Agent Memory PoisoningWrites attacker-controlled rules into memory that affect later sessions
  • Remote Payload Retrieval and ExecutionFetches external code whose behavior can change after review
Findings (2)

T06 · System Persistence

Error
Location
SKILL.md:61
Finding

Persistent background service configured to survive user logout

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 61-88
Vulnerability Type: Cross-session service persistence
Risk Level: High

Vulnerable Code

ini
# ~/.config/systemd/user/bot-status.service
[Unit]
Description=Bot Status API
After=network.target

[Service]
Type=simple
WorkingDirectory=/path/to/bot-status
ExecStart=/usr/bin/node server.js
Restart=always
RestartSec=5
Environment=PORT=3200
Environment=HOME=/home/youruser
Environment=PATH=/usr/local/bin:/usr/bin:/bin

[Install]
WantedBy=default.target
bash
systemctl --user daemon-reload
systemctl --user enable --now bot-status
loginctl enable-linger $USER  # survive logout

Technical Analysis

The setup instructs users to install and enable a systemd user service with Restart=always. It also enables user lingering through loginctl enable-linger, explicitly allowing the service to continue running after the user logs out.

A persistent service may be appropriate for an intentionally deployed monitoring server, but this configuration exceeds the privileges required merely to run or evaluate the Skill. It creates a long-lived execution mechanism without presenting persistence as a separate, security-sensitive opt-in. The service will repeatedly execute server.js from a writable deployment directory. If that file or directory is subsequently compromised, attacker-controlled code can execute persistently under the affected user's account.

The package does not include the referenced server.js, collectors, or package manifest, so the behavior of the program installed through this persistent mechanism cannot be independently verified from the audited artifact.

Attack Path

  1. A user follows the documented installation procedure.
  2. The user service is enabled and immediately started with systemctl --user enable --now.
  3. User lingering is enabled, allowing the service to run without an active logi ...[truncated 1055 chars]
Remediation
View remediation

Remediation Suggestions

  1. Make foreground execution the default and document persistence as a separate, explicit opt-in.
  2. Do not enable user lingering by default. Require administrators to assess whether operation after logout is genuinely necessary.
  3. Replace Restart=always with a more restrictive policy such as Restart=on-failure, with rate limits configured through StartLimitIntervalSec and StartLimitBurst.
  4. Protect the service directory and executable files from unauthorized modification. The service account should own only the files it needs and should not use a broadly writable working directory.
  5. Run the service under a dedicated, minimally privileged account with no interactive login and narrowly scoped access to OpenClaw data.
  6. Add systemd hardening directives where compatible, including NoNewPrivileges=true, PrivateTmp=true, ProtectSystem=strict, ProtectHome=true, and narrowly scoped ReadOnlyPaths or ReadWritePaths.
  7. Provide complete removal instructions covering service shutdown, disabling the unit, removal of the unit file, daemon reload, and disabling lingering when it is no longer required.
  8. Include the referenced implementation files in the audited package so the executable installed through the persistence mechanism can be reviewed.

T09 · Insecure Skill Coding Practices

Error
Location
SKILL.md:8
Finding

Unauthenticated status interface may expose sensitive operational metadata

Content
View full analysis

Vulnerability Details

File Location: SKILL.md, lines 8-19 and 103-106
Vulnerability Type: Sensitive information exposure over a network service
Risk Level: High

Vulnerable Code

markdown
A configurable HTTP service that exposes your OpenClaw bot's operational status as JSON. Designed for dashboard integration, monitoring, and transparency.

## What It Provides

- **Bot Core:** Online status, model, context usage, uptime, heartbeat timing
- **Services:** Health checks for any HTTP endpoint, CLI tool, or file path
- **Email:** Unread counts from any email provider (himalaya, gog, etc.)
- **Cron Jobs:** Reads directly from OpenClaw's `cron/jobs.json`
- **Docker:** Container health via Portainer API
- **Dev Servers:** Auto-detects running dev servers by process grep
- **Skills:** Lists installed and available OpenClaw skills
- **System:** CPU, RAM, Disk metrics from `/proc`
markdown
| Endpoint | Description |
|----------|-------------|
| `GET /status` | Full status JSON (cached) |
| `GET /health` | Simple `{"status":"ok"}` |

Technical Analysis

The documented /status endpoint aggregates operational information from numerous sensitive local sources, including OpenClaw runtime state, model and context information, email unread counts, cron jobs, Docker containers, running development servers, installed skills, and host metrics.

The instructions do not require authentication, authorization, TLS, response redaction, network allowlisting, or loopback-only binding. They also configure a persistent service on port 3200. If the implementation binds to a non-loopback interface, any party with network access to that port may be able to retrieve this metadata without credentials.

This violates least-privilege and data-minimization principles. A basic health endpoint ordinarily needs to disclose only whether the service is healthy. It does not require exposing cron configuration, i ...[truncated 2226 chars]

Remediation
View remediation

Remediation Suggestions

  1. Bind the service to 127.0.0.1 and ::1 by default. Require an explicit configuration change and warning before accepting remote connections.
  2. Require authentication for /status, using a securely generated secret, mutual TLS, or authentication enforced by a trusted reverse proxy.
  3. Apply authorization so callers receive only the status fields they require. Separate public health, operator status, and administrative diagnostics.
  4. Limit the public /health endpoint to a minimal response and never include system, process, cron, skill, email, or container details.
  5. Redact filesystem paths, endpoint URLs, command text, job definitions, container identifiers, skill inventories, model details, and other environment-specific data.
  6. Encrypt remote traffic with TLS and reject plaintext remote access. Avoid placing credentials or tokens in query strings.
  7. Add network allowlisting and firewall instructions, especially for persistent installations.
  8. Disable sensitive collectors by default. Require explicit opt-in for email, cron, Docker, process, skill, and host-level collection.
  9. Run collectors with narrowly scoped filesystem and API permissions. Do not grant broad access to the OpenClaw home directory or container-management interfaces.
  10. Include server.js and all collectors in the package so reviewers can verify the bind address, authentication, response filtering, URL handling, command execution, and error behavior.
  11. Add security-focused deployment documentation and tests confirming that unauthenticated remote requests cannot access detailed status data.

SkillSpector

Vulnerability Patterns
  • Rogue AgentSelf-Modification, Session Persistence
  • Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
  • Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
  • Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
  • Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code
Findings (2)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
96% confidence
Finding

The skill advertises a status API exposing runtime health, service connectivity, cron jobs, skills, and system metrics, but it does not warn that this data can disclose sensitive operational details if reachable by unauthorized users. In context, this is more dangerous because the documented features explicitly include filesystem-derived state, process visibility, and service health data, which can aid reconnaissance and leak internal environment information over HTTP.

Content

No source excerpt is available for this finding.

Session Persistence

Medium
Category
Rogue Agent
Confidence
80% confidence
Finding

Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.

Content

Scanner excerpt · SKILL.md (reported line 84)May include surrounding context.

bash
systemctl --user daemon-reload
systemctl --user enable --now bot-status
loginctl enable-linger $USER  # survive logout

Static analysis

No suspicious patterns detected.