Config Guard

• Outcome: Review
• Latest audit: Sep 10, 2026 · 9:29 PM UTC
• Version: 0.1.0

Overview

This skill is a disclosed OpenClaw rollback helper, but it can automatically replace the live configuration and force a gateway restart without enough validation or user control.

Review this carefully before installing. Only run it if you trust the contents and permissions of ~/.openclaw/backups, understand that it may overwrite ~/.openclaw/openclaw.json, and are comfortable with an automatic forced Gateway restart. Avoid running it as a more privileged user than necessary, and prefer adding backup validation, retries, a private log path, and an explicit approval or dry-run mode.

A.I.G

Vulnerability Patterns

• 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
• Embedded Malicious Code: Ships malicious scripts inside the skill and executes them locally

Findings (2)

T09 · Insecure Skill Coding Practices

Warning

• Location: bin/watchdog.sh:11
• Finding: Unvalidated Backup Automatically Replaces the Active Configuration## Vulnerability Details **File Location**: `bin/watchdog.sh`, lines 11-29 **Vulnerability Type**: Unsafe automatic configuration rollback **Risk Level**: Medium ### Vulnerable Code ```bash # 1. 探测 Gateway 状态 # 尝试使用 openclaw status --probe 进行深探测 if ! openclaw gateway status --json | grep -q '"state": "active"'; then echo "[$(date)] ⚠️ Gateway detected as DOWN or UNREACHABLE." >> "$LOG_FILE" # 2. 查找最新的有效备份 LATEST_BACKUP=$(ls -t "$BACKUP_DIR"/openclaw-*.json 2>/dev/null | head -n 1) if [ -n "$LATEST_BACKUP" ]; then echo "[$(date)] 🔄 Attempting recovery using backup: $LATEST_BACKUP" >> "$LOG_FILE" # 3. 执行回滚 (先备份坏掉的，以防万一) cp "$CONFIG_FILE" "$BACKUP_DIR/failed-config-$(date +%Y%m%d-%H%M%S).json" cp "$LATEST_BACKUP" "$CONFIG_FILE" # 4. 重启 Gateway echo "[$(date)] 🚀 Restarting Gateway..." >> "$LOG_FILE" openclaw gateway restart --force ``` ### Technical Analysis The health check relies on searching command output for the exact text `"state": "active"`. A command failure, malformed response, permission error, temporary timeout, or harmless JSON-formatting change is therefore treated as a confirmed Gateway outage. Once this condition occurs, the script selects the newest pathname matching `openclaw-*.json` and copies it over the active configuration. It does not verify that the selected object: - Is a regular file rather than a symbolic link or another special object. - Resolves to a canonical path inside the expected backup directory. - Is owned by the expected user. - Has safe permissions. - Contains valid JSON. - Conforms to the expected OpenClaw configuration schema. - Represents a trusted backup. The replacement is also not atomic. An interrupted `cp` operation can leave the live configuration partially written before the forced restart. ### Attack Path 1. An attacker with the ability ...[truncated 1439 chars]
• Remediation: ## Remediation Suggestions 1. Parse the status output with a real JSON parser and separately handle command failures, malformed output, timeouts, and an explicit inactive state. 2. Require multiple failed probes or an explicitly armed rollback window before changing the active configuration. 3. Resolve the backup with a safe file-selection mechanism rather than parsing `ls` output. 4. Canonicalize the selected path and verify that it remains beneath the expected backup directory. 5. Use `lstat` or equivalent checks to reject symbolic links and non-regular files. 6. Verify ownership and restrictive permissions before trusting a backup. 7. Validate both JSON syntax and the complete OpenClaw configuration schema before installation. 8. Store and verify a cryptographic digest or signature when backups are created. 9. Copy the validated configuration to a temporary file in the same directory, set safe permissions, synchronize it, and atomically rename it over the active file. 10. Check every copy and restart operation for failure, aborting safely if any step fails. 11. Avoid automatic rollback entirely when directory ownership or permissions do not satisfy the expected trust policy.

T09 · Insecure Skill Coding Practices

Note

• Location: bin/watchdog.sh:8
• Finding: Predictable Shared Temporary Log File Permits Symlink Following## Vulnerability Details **File Location**: `bin/watchdog.sh`, lines 8-10 **Vulnerability Type**: Unsafe temporary-file handling **Risk Level**: Low ### Vulnerable Code ```bash LOG_FILE="/tmp/openclaw-watchdog.log" echo "[$(date)] Watchdog starting..." >> "$LOG_FILE" ``` ### Technical Analysis The script writes to a fixed, predictable path in the shared `/tmp` directory. Shell redirection follows symbolic links, and the script performs no check of the existing object's type, ownership, or permissions before opening it in append mode. Consequently, another local user may pre-create `/tmp/openclaw-watchdog.log` as a symbolic link. When the watchdog runs, its log messages are appended to the link target with the privileges of the invoking account. Similar writes occur throughout the script, increasing the amount of text that can be appended. The written text is mostly fixed and includes timestamps and selected backup paths, so this issue does not provide arbitrary file-content control. It can nevertheless corrupt a targeted file that is writable by the watchdog's effective user. ### Attack Path 1. A local attacker removes or waits for the absence of `/tmp/openclaw-watchdog.log`. 2. The attacker creates that pathname as a symbolic link to a file that the future watchdog process can write. 3. A user or privileged automation invokes `bin/watchdog.sh`. 4. Shell append redirection follows the symbolic link. 5. Watchdog log records are appended to the target file. 6. If the target is syntax-sensitive, the appended data may corrupt it or alter its behavior in a context-dependent manner. ### Impact Assessment The direct impact is unauthorized file modification and potential denial of service through file corruption. The accessible scope is limited to targets writable by the account executing the watchdog. If the watchdog runs with elevated privileges while `/tmp` remains writable by unprivileged users, this becomes a ...[truncated 233 chars]
• Remediation: ## Remediation Suggestions 1. Store logs in a private state directory, such as `${XDG_STATE_HOME:-$HOME/.local/state}/openclaw`, rather than in shared `/tmp`. 2. Create the containing directory with mode `0700` and the log file with mode `0600`. 3. Before writing, use `lstat` or equivalent logic to reject symbolic links and non-regular files. 4. Verify that the log file is owned by the effective user. 5. If temporary storage is unavoidable, securely create a unique file with `mktemp` in a trusted directory and retain the returned pathname. 6. Prefer a system logging facility when the watchdog is operated as a privileged service. 7. Set a restrictive `umask`, such as `umask 077`, near the start of the script.

SkillSpector

Vulnerability Patterns

• 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
• Excessive Agency: Unrestricted Tool Access, Autonomous Decision Making, Scope Creep

Findings (3)

Missing User Warnings

Medium

• Confidence: 93% confidence
• Finding: The script automatically overwrites the active configuration with the newest backup and performs a forced gateway restart based only on a simple health check, with no user confirmation, integrity validation, or safety guardrails. If the probe is wrong, the backup is stale or maliciously modified, or the environment is unstable, this can cause unintended rollback, service disruption, or restoration of insecure settings.

Natural-Language Policy Violations

Low

• Confidence: 85% confidence
• Finding: The title and introductory description present core usage information in Chinese, while later sections are in English. This imposes a language assumption on the user without any stated opt-in or alternative, which matches the language/locale policy concern for natural-language content.

Natural-Language Policy Violations

Low

• Confidence: 88% confidence
• Finding: The script's descriptive comments are written only in Chinese, which imposes a specific language without any opt-in or explanation of a locale-specific requirement. The policy requires avoiding forced language or locale constraints unless choice or justification is provided.

Static analysis

No suspicious patterns detected.