Test

• Outcome: Review
• Latest audit: Sep 10, 2026 · 10:13 AM UTC
• Version: 0.0.1

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 Persistence: Installs backdoors, hooks, services, or scheduled tasks that survive the run
• Insecure Skill Coding Practices: Finds exploitable flaws such as hardcoded secrets or command injection
• 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
• Remote Payload Retrieval and Execution: Fetches 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## 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: ## 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## 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: ## 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 Agent: Self-Modification, Session Persistence
• Prompt Injection: Instruction Override, Hidden Instructions, Exfiltration Commands
• Data Exfiltration: External Transmission, Env Variable Harvesting, File System Enumeration
• Privilege Escalation: Excessive Permissions, Sudo/Root Execution, Credential Access
• Supply Chain: Unpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Missing User Warnings

Medium

• 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.

Session Persistence

Medium

• Category: Rogue Agent

Content

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

• 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.

Static analysis

No suspicious patterns detected.