Back to skill

Security audit

Gateway Safety

Security checks for vulnerabilities and agentic risk

Overview

The skill has a coherent gateway-safety purpose, but its shell script has material safety and command-injection weaknesses around sensitive gateway configuration changes.

Review before installing. The skill is not showing deception or exfiltration, but it controls sensitive OpenClaw gateway configuration and its safety script needs hardening: validate numeric inputs, check every copy/restart result, enforce GATEWAY_LOCKOUT in the script, and document who can clear lockout state.

Vulnerability Patterns
  • 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
  • Embedded Malicious CodeShips malicious scripts inside the skill and executes them locally
Findings (4)

T09 · Insecure Skill Coding Practices

Error
Location
scripts/safe-gateway-update.sh:8
Finding
Command Injection Through Unvalidated Timeout Arithmetic<![CDATA[ ## Vulnerability Details **File Location**: `scripts/safe-gateway-update.sh`, lines 8 and 50 **Vulnerability Type**: Shell arithmetic-expression injection **Risk Level**: High ### Vulnerable Code ```bash TIMEOUT="${2:-30}" ``` ```bash for ((i=1; i<=$TIMEOUT; i++)); do STATUS=$(openclaw gateway status 2>/dev/null) if echo "$STATUS" | grep -q "RPC probe: ok"; then log "Gateway is back online and healthy (attempt $i)." SUCCESS=1 break fi sleep 1 done ``` ### Technical Analysis The second command-line argument is accepted without validating that it is a bounded decimal integer. It is subsequently inserted into a Bash arithmetic expression. Bash arithmetic expressions may recursively interpret variable contents as arithmetic syntax. Specially constructed expressions, including expressions containing array subscripts and command substitutions, can cause commands to be evaluated. Even when command execution is not achieved, negative, malformed, or extremely large values can bypass the intended health-check behavior or make the script run for an excessive period. The script modifies gateway configuration and restarts a service, making execution in its process context security-sensitive. ### Attack Path 1. An attacker or compromised automation invokes the script and controls its second argument. 2. The attacker supplies an arithmetic expression instead of a decimal timeout, such as an expression using an array subscript with command substitution. 3. The value is stored unchanged in `TIMEOUT`. 4. Bash evaluates the value when processing `((i=1; i<=$TIMEOUT; i++))`. 5. The embedded expression executes with the operating-system privileges of the account running the script. Alternatively, an extremely large integer can keep the polling loop active for an excessive duration. ### Impact Assessment Successful exploitation can execute arbitrary shell commands as the user running the Skill. That account already has a ...[truncated 398 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Validate and normalize the timeout before using it: ```bash TIMEOUT="${2:-30}" if [[ ! "$TIMEOUT" =~ ^[1-9][0-9]*$ ]] || (( 10#$TIMEOUT > 300 )); then log "Error: Timeout must be an integer between 1 and 300 seconds." exit 1 fi TIMEOUT=$((10#$TIMEOUT)) ``` Use the validated numeric variable without another parameter expansion inside the arithmetic expression: ```bash for ((i = 1; i <= TIMEOUT; i++)); do # Health check done ``` Set a conservative upper bound appropriate for gateway startup so that callers cannot cause an unreasonably long execution. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/safe-gateway-update.sh:72
Finding
Command Injection Through Unvalidated Failure Counter State<![CDATA[ ## Vulnerability Details **File Location**: `scripts/safe-gateway-update.sh`, lines 72–75 **Vulnerability Type**: Unsafe evaluation of mutable file contents **Risk Level**: Medium ### Vulnerable Code ```bash # Increment failure counter to prevent loops COUNT=$(cat "$COUNT_FILE" 2>/dev/null || echo 0) COUNT=$((COUNT + 1)) echo "$COUNT" > "$COUNT_FILE" ``` ### Technical Analysis The script reads the contents of `~/.openclaw/config_failure_count` and evaluates those contents as a Bash arithmetic expression without first confirming that they contain only decimal digits. Bash arithmetic evaluation can interpret more than integer literals. Crafted input can contain arithmetic syntax that triggers evaluation of array subscripts or command substitutions. Malformed content can also terminate the rollback workflow before the lockout is established. The counter is persistent mutable state. Its security depends on the ownership and permissions of the file and every parent directory, but the script does not verify those properties or reject symbolic links. ### Attack Path 1. An attacker gains the ability to create, replace, or modify `~/.openclaw/config_failure_count`, such as through overly permissive file or directory permissions or another process writing unsafe state. 2. The attacker places a crafted arithmetic expression in the file. 3. A gateway update fails its health check and enters the rollback branch. 4. The script reads the attacker-controlled expression into `COUNT`. 5. `COUNT=$((COUNT + 1))` evaluates that expression in the script process. 6. Any resulting command executes as the user running the gateway update script. A malformed value can instead disrupt counter processing, preventing reliable lockout creation. ### Impact Assessment Exploitation can execute commands with the privileges of the script’s operating-system account. It can also corrupt the anti-loop state and interfere with rollback or lockout processing. The practical explo ...[truncated 152 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Validate counter contents before arithmetic evaluation: ```bash COUNT=0 if [[ -f "$COUNT_FILE" ]]; then IFS= read -r COUNT < "$COUNT_FILE" || COUNT=0 fi if [[ ! "$COUNT" =~ ^[0-9]+$ ]]; then log "Warning: Invalid failure counter; resetting it safely." COUNT=0 fi COUNT=$((10#$COUNT + 1)) ``` Protect persistent state as follows: - Create `~/.openclaw` with permissions such as `0700`. - Create the counter with permissions such as `0600`. - Reject a counter path that is a symbolic link. - Write the new count to a securely created temporary file in the same directory and atomically rename it. - Consider applying a maximum counter value to prevent integer abuse. ]]>

T09 · Insecure Skill Coding Practices

Error
Location
scripts/safe-gateway-update.sh:39
Finding
Unchecked Backup, Configuration, Restart, and Rollback Operations Cause Fail-Open Behavior<![CDATA[ ## Vulnerability Details **File Location**: `scripts/safe-gateway-update.sh`, lines 39–46 and 69–78 **Vulnerability Type**: Missing error handling for safety-critical operations **Risk Level**: High ### Vulnerable Code ```bash log "Backing up current config to $BACKUP_PATH" cp "$CONFIG_PATH" "$BACKUP_PATH" log "Applying new config..." cp "$NEW_CONFIG" "$CONFIG_PATH" log "Restarting gateway..." openclaw gateway restart ``` ```bash log "TIMEOUT REACHED. Gateway failed to respond. ROLLING BACK..." cp "$BACKUP_PATH" "$CONFIG_PATH" # Increment failure counter to prevent loops COUNT=$(cat "$COUNT_FILE" 2>/dev/null || echo 0) COUNT=$((COUNT + 1)) echo "$COUNT" > "$COUNT_FILE" log "Restarting gateway with original config (Failure #$COUNT)..." openclaw gateway restart ``` ### Technical Analysis The script does not check the exit status of the operations that implement its core safety guarantees: - Copying the current configuration to the backup - Applying the replacement configuration - Restarting the gateway - Restoring the backup - Restarting the gateway after rollback The script also does not enable a controlled fail-fast mode or provide explicit error branches for these commands. Consequently, it may continue after an operation fails. For example, if the initial restart fails while an existing gateway instance remains healthy, the later status probe may report `RPC probe: ok` for the old process. The script can then report success and overwrite `openclaw.json.known-good`, even though the requested configuration was never activated. Conversely, if backup creation or restoration fails, rollback may not restore the original configuration. ### Attack Path One representative failure or exploitation path is: 1. The backup copy fails because of permissions, storage exhaustion, a missing source file, or an unsafe filesystem object. 2. The script ignores that failure and attempts to apply the new configuration. 3. The restart command fails, or the o ...[truncated 1014 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Check every safety-critical operation explicitly and stop on failure: ```bash if ! cp -- "$CONFIG_PATH" "$BACKUP_PATH"; then log "CRITICAL: Failed to create backup; no changes were made." exit 1 fi if ! cp -- "$NEW_CONFIG" "$CONFIG_PATH"; then log "CRITICAL: Failed to install the new configuration." exit 1 fi if ! openclaw gateway restart; then log "Restart command failed; initiating rollback." # Enter a checked rollback function. fi ``` Additional hardening should include: 1. Write configurations to a temporary file in `~/.openclaw`, apply appropriate permissions, and atomically rename the file into place. 2. Implement rollback in a function that checks both restoration and restart results. 3. Verify that the post-restart gateway is a newly started process rather than an old healthy instance. 4. Verify that the active gateway loaded the expected configuration, for example by checking a configuration digest or generation identifier. 5. Update `openclaw.json.known-good` only after confirming both restart completion and activation of the expected configuration. 6. Use a trap for unexpected termination while a replacement is in progress. 7. Check available storage and ensure backup, active configuration, and known-good paths are regular files rather than symbolic links. ]]>

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/safe-gateway-update.sh:80
Finding
Anti-Loop Lockout Is Documented but Not Enforced by the Script<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 14; `scripts/safe-gateway-update.sh`, lines 80–84 **Vulnerability Type**: Missing enforcement of a documented safety control **Risk Level**: Medium ### Vulnerable Code The Skill declares the following mandatory behavior: ```markdown 2. **Anti-Loop Policy**: If the script fails 3 times consecutively, it will create a `GATEWAY_LOCKOUT` file. If this file exists, **STOP ALL OPERATIONS** and wait for Kevin. Do not attempt to bypass the lockout. ``` The script only creates the marker after failures: ```bash # If we've failed too many times, we should probably stop and wait for a human if [ "$COUNT" -ge 3 ]; then log "CRITICAL: Multiple consecutive config failures detected ($COUNT). STOPPING." echo "CRITICAL: GATEWAY UPDATE LOOP DETECTED ($COUNT failures). AGENTS: DO NOT RETRY WITHOUT MANUAL REVIEW FROM KEVIN." > "$HOME/.openclaw/GATEWAY_LOCKOUT" fi ``` There is no corresponding startup check for `~/.openclaw/GATEWAY_LOCKOUT`. ### Technical Analysis The lockout policy is enforced only through agent instructions, not by the executable safety boundary. Although the script creates a marker after three failures, a direct invocation or automation process can run the script again without checking the marker. The log message says the process is “STOPPING,” but the marker only affects behavior if every caller independently follows the documentation. This creates a discrepancy between the stated control and actual execution. ### Attack Path 1. Three consecutive gateway updates fail. 2. The script creates `~/.openclaw/GATEWAY_LOCKOUT`. 3. A caller, automation loop, or compromised agent invokes the script again. 4. The script never checks for the marker. 5. It backs up and replaces the configuration and restarts the gateway again. 6. Repeated attempts can continue despite the intended lockout. ### Impact Assessment The missing enforcement permits repeated gateway reconfiguration and res ...[truncated 355 chars]
Remediation
<![CDATA[ ## Remediation Suggestions Enforce the lockout before any backup, file modification, or gateway command: ```bash LOCKOUT_FILE="$HOME/.openclaw/GATEWAY_LOCKOUT" if [[ -e "$LOCKOUT_FILE" ]]; then log "CRITICAL: Gateway lockout is active. Manual review is required." exit 1 fi ``` Also implement the following controls: - Validate that the lockout marker is a regular file and not a symbolic link. - Create it atomically with restrictive permissions. - Define an explicit manual recovery procedure that validates the active and known-good configurations before removing the marker. - Avoid relying solely on agent instructions for a safety boundary that can be enforced in code. - Ensure the failure counter and lockout update are serialized if concurrent script executions are possible. ]]>
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 (1)

Session Persistence

Medium
Category
Rogue Agent
Content
## Core Rules

1. **Mandatory Script Use**: Never edit `~/.openclaw/openclaw.json` directly. Always use the provided `safe-gateway-update.sh` script.
2. **Anti-Loop Policy**: If the script fails 3 times consecutively, it will create a `GATEWAY_LOCKOUT` file. If this file exists, **STOP ALL OPERATIONS** and wait for Kevin. Do not attempt to bypass the lockout.
3. **Backup Awareness**: The script maintains its own backups, but for critical changes, manually verify `~/.openclaw/openclaw.json.known-good` is up to date.

## Usage
Confidence
60% 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.