Security audit

Upgrade Openclaw

Security checks for vulnerabilities and agentic risk

Overview

This skill is an OpenClaw updater, but it can change the local OpenClaw installation and read full gateway configuration before strong user-controlled boundaries are established.

Review this skill carefully before installing. It is not malicious based on the inspected artifacts, but users should invoke it only when they actually want OpenClaw updated, avoid external sub-agent models unless gateway config has been redacted, and check `git stash list` after any interrupted or declined run.

A.I.G

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 (2)

T09 · Insecure Skill Coding Practices

Warning

Location: SKILL.md:25
Finding: Potential Disclosure of Full Gateway Configuration to an External Model Provider<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 25–32 and 73–77 **Vulnerability Type**: Sensitive configuration exposure **Risk Level**: Medium ### Vulnerable Code ```markdown ## Settings On first run, check `settings.json` in this skill's directory. If `subagentModel` not set, ask: > "Which model for upgrade sub-agents? (e.g., `claude-sonnet-4-6`, `deepseek-chat`). Note: external providers will receive config data." Save to `settings.json`: ```json { "subagentModel": "anthropic/claude-sonnet-4-6" } ``` ``` ```markdown ### 4. Config Schema Gap Analysis Fetch the live schema and current config: - Schema: `gateway config.schema` - Current: `gateway config.get` ``` ### Technical Analysis The skill instructs the agent to retrieve the complete live gateway configuration through `gateway config.get`. It also explicitly acknowledges that configuration data may be sent to an external provider when an externally hosted subagent model is selected. The instructions do not require the agent to: - Restrict configuration retrieval to fields needed for the comparison. - Remove credentials, API tokens, webhook secrets, internal endpoints, or user identifiers. - Inspect and disclose the exact outbound data before transmission. - Obtain explicit, informed approval for each external disclosure. - Prefer local processing for sensitive configuration analysis. A gateway configuration can contain operationally sensitive values even when it is not intended to function as a secret store. Transmitting the complete object violates data-minimization and least-disclosure principles. The vulnerability is conditional on an external model being used and the retrieved configuration being included in that model's context. ### Attack Path 1. The skill is invoked to upgrade or audit OpenClaw. 2. The configured `subagentModel` points to an externally hosted model provider. 3. The skill retrieves the complete gateway configuration with `gateway config.get`. 4 ...[truncated 1213 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Perform schema comparison locally without placing the complete configuration in a model context. 2. Retrieve only fields required to identify enabled channels, plugins, and explicitly configured schema paths. 3. Introduce a mandatory recursive redaction layer for: - Passwords and passphrases. - API keys and bearer tokens. - Webhook and signing secrets. - Private keys and certificates. - Session cookies and authentication headers. - Sensitive values referenced through secret-management systems. 4. Replace secret values with type-preserving placeholders such as `[REDACTED_TOKEN]`. 5. Show the user a preview of all fields that would be transmitted externally and obtain explicit approval before transmission. 6. Default to a local model or local deterministic comparison routine when configuration data is involved. 7. Document the selected provider, data-retention implications, and the minimum configuration fields required for the operation. 8. Add a validation step that aborts external processing if potentially secret-bearing fields remain after redaction. ]]>

T09 · Insecure Skill Coding Practices

Note

Location: SKILL.md:43
Finding: Pre-Update Git Stash Is Not Reliably Restored on Decline, Error, or Interruption<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, lines 43–47 and 168–174 **Vulnerability Type**: Unsafe worktree state handling **Risk Level**: Low ### Vulnerable Code ```markdown If dirty working tree, stash first: ```bash cd "$(openclaw --version 2>&1 | grep -oP '(?<=$).*?(?=$)' || echo ~/openclaw)" git stash --include-untracked -m "pre-update stash" && openclaw update ``` ``` ```markdown On approval, apply changes via: - Config changes: `gateway config.patch` - Hook enablement: `openclaw hooks enable <hook>` - Skill installs: `clawhub install <skill>` After applying, pop any git stash: ```bash cd ~/openclaw && git stash list | grep -q "pre-update stash" && git stash pop ``` ``` ### Technical Analysis The skill stashes tracked and untracked work before running the update. Restoration is placed in the later approval-and-application phase rather than in an unconditional cleanup phase. Consequently, the stash may remain unapplied if: - The user declines the proposed improvements. - The update or subsequent audit fails. - Execution is interrupted before approval. - The user does not respond to the approval prompt. - An application command fails before the restoration command. - The workflow exits early after reporting that no additional action is required. The restoration command also checks only whether any stash entry contains the generic message `pre-update stash`, then executes `git stash pop` without selecting the exact stash created by the current run. If newer stash entries exist, `git stash pop` can target the wrong entry. Repeated executions can also produce multiple indistinguishable stashes. This is primarily an availability and integrity problem rather than a privilege-escalation issue. ### Attack Path 1. The OpenClaw repository contains modified or untracked user files. 2. The skill detects or assumes a dirty worktree and runs: `git stash --include-untracked -m "pre-update stash"`. 3. The tracked and untracked file ...[truncated 1313 chars]
Remediation: <![CDATA[ ## Remediation Suggestions 1. Treat stashing and restoration as a transaction with an unconditional cleanup phase. 2. Record the exact stash object created by the current run rather than searching by a generic message. 3. Restore the stash after update analysis regardless of whether the user approves later configuration, hook, or skill changes. 4. Add cleanup handling for command failure, user rejection, timeout, and interruption. 5. Verify that the resolved repository path is correct before modifying its worktree. 6. Never use an unqualified `git stash pop` when other stash entries may exist. 7. Prefer applying the recorded stash first and dropping it only after a successful application, preserving recovery if conflicts occur. 8. Report restoration conflicts explicitly and retain the stash until the user resolves them. 9. Use a unique identifier in the stash message, such as a timestamp or generated run ID. A safer conceptual workflow is: ```bash repo_path="..." run_id="upgrade-openclaw-$(date +%s)" cd "$repo_path" || exit 1 before_ref="$(git rev-parse -q --verify refs/stash 2>/dev/null || true)" git stash push --include-untracked -m "$run_id" created_ref="$(git rev-parse -q --verify refs/stash 2>/dev/null || true)" # Run update and audit operations here. # Execute this cleanup regardless of approval or prior command failure. if [ -n "$created_ref" ] && [ "$created_ref" != "$before_ref" ]; then git stash apply "$created_ref" # Drop only after confirming that the apply operation succeeded. fi ``` The implementation should additionally account for stash-reference movement and preserve the created commit hash so that the exact stash remains identifiable. ]]>

SkillSpector

Vulnerability Patterns

Data ExfiltrationExternal Transmission, Env Variable Harvesting, File System Enumeration
Trigger AbuseOverly Broad Trigger, Shadow Command Trigger, Keyword Baiting Trigger
Prompt InjectionInstruction Override, Hidden Instructions, Exfiltration Commands
Privilege EscalationExcessive Permissions, Sudo/Root Execution, Credential Access
Supply ChainUnpinned Dependencies, External Script Fetching, Obfuscated Code

Findings (2)

Vague Triggers

Medium

Confidence: 92% confidence
Finding: The skill advertises broad natural-language triggers like 'update openclaw' and 'what's new in openclaw', which can match casual informational requests and cause the agent to invoke a workflow that performs system-changing actions such as running updates, stashing git state, and writing files. In this context, over-broad activation is risky because the skill has side effects before any explicit confirmation gate, so accidental invocation could modify the local environment unexpectedly.

Missing User Warnings

Low

Confidence: 85% confidence
Finding: The skill persists configuration in 'settings.json' and later upgrade history in 'state.json' without clearly warning the user that local data will be stored. Although the stored data is not obviously highly sensitive, it includes model/provider choices and upgrade activity metadata, and the skill also notes that external providers may receive config data, so silent persistence reduces user awareness and informed consent.

Static analysis

No suspicious patterns detected.