Back to skill

Security audit

Blue Green Deployer

Security checks for vulnerabilities and agentic risk

Overview

The skill is for OpenClaw configuration deployment, but its script can replace the live configuration during validation and has unsafe rollback and temporary-file handling.

Install only if you are comfortable with a script directly modifying ~/.openclaw/openclaw.json. Review and harden deploy.sh first: validate Green without replacing the live config, separate validate from promote, remove BLUE_LONG_NAME from cleanup, use per-run temporary files, and require explicit confirmation before promotion.

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/deploy.sh:17
Finding

Environment-Controlled File Used as Emergency Rollback Source

Content
View full analysis
/dev/null || true fi fi ``` ### Technical Analysis The script never defines or validates `BLUE_LONG_NAME`. Bash therefore obtains its value from the inherited process environment when it is present. Although the existence check is performed against `${BLUE_CONFIG}.tmp`, the source passed to `mv` can be an entirely different path selected through `BLUE_LONG_NAME`. This creates a mismatch between the validated file and the file actually used for restoration. Because `cleanup` is registered as an `EXIT` trap, any nonzero termination can reach this operation. In the normal validation-failure path, the script first restores the backup and exits with status 1; the cleanup handler can then overwrite that restored configuration with the environment-selected source. ### Attack Path 1. An attacker who can influence the deployment process environment creates a malicious OpenClaw configuration at a path accessible to the invoking user. 2. The attacker exports `BLUE_LONG_NAME` with that path: ```bash export BLUE_LONG_NAME=/path/to/malicious-openclaw.json ``` 3. The attacker ensures `$HOME/.openclaw/openclaw.json.tmp` exists, or invokes the script far enough for line 57 to create it. 4. The deployment is made to terminate with a nonzero status, such as by causing validation to fail. 5. The `EXIT` trap confirms that the `.tmp` file exists but executes: ```bash mv "$BLUE_LONG_NAME" "$BLUE_CONFIG" ``` 6. The ...[truncated 531 chars]
Remediation
View remediation

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/deploy.sh:47
Finding

Predictable Backup and Temporary Paths Permit Symlink-Following File Overwrites

Content
View full analysis
Remediation
View remediation

T09 · Insecure Skill Coding Practices

Error
Location
scripts/deploy.sh:59
Finding

Validation Temporarily Replaces the Live Configuration and Uses an Insufficient Health Check

Content
View full analysis
/dev/null 2>&1; then echo "✅ SUCCESS: Green configuration is valid!" echo "🎉 Promoting Green to Blue..." # To promote, we replace the symlink with the actual content of Green rm "$BLUE_CONFIG" cp "$GREEN_CONFIG" "$BLUE_CONFIG" ``` ### Technical Analysis The audit is not isolated from the live environment. Before validation, the script deletes the real Blue configuration and replaces it with a two-level symbolic-link chain pointing to the Green configuration. The only validation command is `openclaw status`. A successful status command is treated as proof that the candidate configuration is syntactically and semantically valid. The script does not run the `jq empty` check documented in `SKILL.md`, and there is no evidence that `openclaw status` necessarily parses every candidate field or validates all behavior affected by the configuration. This produces two security and reliability problems: 1. The candidate configuration becomes the live configuration during the test, so services or concurrent OpenClaw processes can observe unapproved settings. 2. Any candidate for which `openclaw status` returns zero is promoted automatically, even if it contains malformed, unsupported, or unsafe settings not exercised by that command. ### Attack Path 1. An attacker or untrusted operator modifies `openclaw.json.green`. 2. The candidate is chosen so that `openclaw status` still exits successfully, for example because the statu ...[truncated 987 chars]
Remediation
View remediation

T09 · Insecure Skill Coding Practices

Warning
Location
scripts/deploy.sh:17
Finding

Stale Temporary Configuration Can Overwrite Current Blue State During a Later Failure

Content
View full analysis
/dev/null || true fi fi # Remove the audit symlink if it exists [ -L "$AUDIT_LINK" ] && rm "$AUDIT_LINK" } trap cleanup EXIT ``` The predictable temporary file is created here: ```bash # Create a temporary copy of Blue to swap in cp "$BLUE_CONFIG" "${BLUE_CONFIG}.tmp" ``` ### Technical Analysis A successful deployment does not remove `${BLUE_CONFIG}.tmp`, because the cleanup function only processes that file when the exit code is nonzero. The script also does not record whether the current invocation created the temporary file. As a result, a later execution can mistake a stale copy from a previous successful deployment for current recovery state. If the later execution fails before replacing the stale file with a fresh copy, the `EXIT` trap moves the obsolete configuration over the current Blue path. For example, the script checks for the existence of Blue before reaching the fresh copy operation. If that check fails while an old `.tmp` remains, the cleanup trap restores the obsolete file even though it was not created by the current run. ### Attack Path 1. A deployment reaches line 57 and completes successfully. 2. The script leaves `$HOME/.openclaw/openclaw.json.tmp` on disk. 3. Blue is subsequently updated by another legitimate process, so the stale temporary file no longer represents the current state. 4. A later deployment exits with an error before line 57 creates a fresh temporary copy. Th ...[truncated 895 chars]
Remediation
View remediation
Vulnerability Patterns
  • 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
  • Excessive AgencyUnrestricted Tool Access, Autonomous Decision Making, Scope Creep
Findings (1)

Missing User Warnings

Medium
Category
Not specified by scanner
Confidence
92% confidence
Finding

The skill instructs users to run a deployment workflow that can automatically promote Green to Blue or roll back Blue, but it does not clearly warn that these actions modify the live configuration state. In a configuration-management skill, hidden or underemphasized state-changing behavior can cause unintended production changes, operator confusion, and outages if a user assumes the process is only a safe test step.

Content

No source excerpt is available for this finding.