T01 · Skill Instruction Hijacking
- Location
SKILL.md:8- Finding
Mandatory Instructions Hijack Unrelated Agent Workflows
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
The skill is a real credential-management tool, but it should be reviewed carefully because it broadly centralizes secrets, deletes old credential files, and gives overbroad mandatory instructions with unsafe handling patterns.
Review before installing. Do not run auto-confirm or cleanup modes until you have inspected the exact files to be migrated, verified secure backups, and tested the new credential store. Avoid sourcing the generated .env in shell, avoid centralizing irreplaceable wallet seed phrases unless you deliberately accept that risk, and verify permissions, ownership, and git tracking with real filesystem and Git checks.
SKILL.md:8Mandatory Instructions Hijack Unrelated Agent Workflows
scripts/consolidate.py:87Credential Backups Are Stored in Plaintext and May Retain Insecure Permissions
scripts/consolidate.py:208Central Credential File Is Written Before Restrictive Permissions Are Applied
scripts/consolidate.py:102Unescaped Credential Values Allow Dotenv Variable Injection
scripts/cleanup.py:14Cleanup Deletes Files Without Proving Successful Migration or Backup
scripts/enforce.py:32Substring-Based Gitignore Checks Produce False Security Assurance
The bash example source ~/.openclaw/.env encourages executing the contents of the .env file as shell code. If that file is modified maliciously or contains unexpected shell syntax, sourcing it can trigger command execution rather than merely loading key-value pairs.
#!/bin/bash
# Load from root .env
source ~/.openclaw/.env
# Use credentials
This snippet combines sourcing a credential file with immediately echoing a secret, creating both code-execution risk and direct secret disclosure risk. In a credential-management skill, such guidance is especially dangerous because users are likely to copy-paste it while handling sensitive production tokens.
#!/bin/bash
# Load from root .env
source ~/.openclaw/.env
# Use credentials
echo "$SERVICE_API_KEY"
If the skill only validates an existing ~/.openclaw/.env and perhaps fixes limited metadata, then calling it a mandatory migration and consolidation foundation is materially misleading. The risk is amplified because the content repeatedly frames itself as non-optional and authoritative, encouraging users to trust it without independent verification.
If the skill only validates an existing ~/.openclaw/.env and perhaps fixes limited metadata, then calling it a mandatory migration and consolidation foundation is materially misleading. The risk is amplified because the content repeatedly frames itself as non-optional and authoritative, encouraging users to trust it without independent verification.
If the skill only validates an existing ~/.openclaw/.env and perhaps fixes limited metadata, then calling it a mandatory migration and consolidation foundation is materially misleading. The risk is amplified because the content repeatedly frames itself as non-optional and authoritative, encouraging users to trust it without independent verification.
If the skill only validates an existing ~/.openclaw/.env and perhaps fixes limited metadata, then calling it a mandatory migration and consolidation foundation is materially misleading. The risk is amplified because the content repeatedly frames itself as non-optional and authoritative, encouraging users to trust it without independent verification.
The top-level description announces consolidation of API keys and credentials into a single .env, which is a sensitive operation with direct access to secrets. The risk comes from centralizing many credentials into one target without strong guarantees around scope, implementation fidelity, and safe handling.
---
name: credential-manager
description: MANDATORY security foundation for OpenClaw. Consolidate scattered API keys and credentials into a secure .env file with proper permissions. Use when setting up OpenClaw, migrating credentials, auditing security, or enforcing the .env standard. This is not optional — centralized credential management is a core requirement for secure OpenClaw deployments. Scans for credential files across common locations, backs up existing files, creates a unified .env with mode 600, validates security, and enforces best practices.
---
# Credential Manager
Mandating a single ~/.openclaw/.env as the only credential store creates a concentration-of-secrets pattern. While centralization can simplify administration, it also makes compromise of one file disproportionately damaging and may not fit all threat models.
Every OpenClaw deployment MUST have:
~/.openclaw/.env (mode 600)
This is your single source of truth for all credentials. No exceptions.
The skill explicitly targets credential files such as credentials.json and secret-bearing patterns for scanning and consolidation. Access to such files is inherently high risk, and in this case the danger is elevated by the lack of clearly bounded permissions and the possible mismatch between claimed and actual safeguards.
The skill automatically detects credentials by scanning for:
**File Patterns:**
- `credentials.json` files in config directories
- `.env` files
- Memory files with `-creds` or `credentials` in the name
The skill targets highly sensitive secret classes including access tokens, passwords, private keys, and seed phrases. That scope is inherently dangerous and requires especially strong containment, explicit consent, and minimal-retention design; otherwise the skill becomes a high-value path to aggregate the user's most sensitive assets.
- Memory files with `-creds` or `credentials` in the name
**Sensitive Key Patterns:**
- API keys, access tokens, bearer tokens
- Secrets, passwords, passphrases
- OAuth consumer keys
- Private keys, signing keys, wallet keys
The documented scan paths include broad globs over configuration and memory directories plus a home-directory .env, which can sweep up unrelated secrets. Broad credential discovery is dangerous in agent contexts because it expands the blast radius of accidental leakage, misuse, or destructive cleanup.
The skill scans these locations:
~/.config/*/credentials.json
~/.openclaw/workspace/memory/*-creds.json
~/.openclaw/workspace/memory/*credentials*.json
~/.env (if exists, merges)
Including ~/.env in merge targets broadens collection into a common user-level secret store that may contain unrelated credentials. That increases the chance of over-collection, unintended copying, and cross-project secret exposure.
~/.config//credentials.json ~/.openclaw/workspace/memory/-creds.json ~/.openclaw/workspace/memory/credentials.json ~/.env (if exists, merges)
## Security Features
The example code imports helper functions that validate and retrieve credentials from the secure store, normalizing skill-level credential access. This is acceptable for a credential tool, but it should be treated as sensitive because it encourages downstream skills to depend on direct secret retrieval.
# Add credential-manager scripts to path
sys.path.insert(0, str(Path.home() / '.openclaw/skills/credential-manager/scripts'))
# Enforce secure .env (exits if not compliant)
from enforce import require_secure_env, get_credential
require_secure_env()
The bash example sources ~/.openclaw/.env directly into the shell. Sourcing executes shell syntax, so if the file contains malicious command substitutions or crafted content, using it as code can lead to command execution and secret exposure.
fi
source ~/.openclaw/.env
**This creates a fail-fast system:** If credentials aren't properly secured, skills refuse to run. Users are forced to fix it.
The Python example reads the entire .env file and loads all variables into process environment state. Bulk-loading all secrets increases accidental exposure risk through subprocess inheritance, debugging output, or unrelated code paths.
import os
from pathlib import Path
# Load .env
env_file = Path.home() / '.openclaw' / '.env'
with open(env_file) as f:
for line in f:
Opening and iterating the .env file is expected, but the example's simplistic parsing can mishandle quoting, malformed lines, or dangerous values, leading to incorrect credential loading or accidental leakage. In a security skill, weak parsing guidance is a meaningful risk.
from pathlib import Path
# Load .env
env_file = Path.home() / '.openclaw' / '.env'
with open(env_file) as f:
for line in f:
if '=' in line and not line.strip().startswith('#'):
This example again advises sourcing the .env file in bash, which treats file contents as executable shell input rather than inert configuration data. If an attacker can modify the file or inject crafted values, this can trigger arbitrary command execution when users follow the documentation.
# Load .env
set -a
source ~/.openclaw/.env
set +a
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
# Development
~/.openclaw/.env.development
# Production
~/.openclaw/.env.production
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
~/.openclaw/.env.development
~/.openclaw/.env.production
Decrypting a secret file directly into /tmp/.env is risky because /tmp is a shared, world-searchable location on many Unix systems and may be monitored, backed up, or left behind after crashes. Even if the file's default mode is restrictive, placing plaintext credentials in a transient shared area materially increases the chance of accidental exposure.
gpg -c ~/.openclaw/.env
gpg -d ~/.openclaw/.env.gpg > /tmp/.env
### Use Secret Managers
The incident-response example performs in-place text replacement of old and new secrets via sed, which can leak both credentials through shell history, process listings, logs, or recovery artifacts. Documentation that normalizes direct command-line handling of plaintext secrets increases operational exposure during emergency rotation.
# 1. Revoke old key in service dashboard
# 2. Generate new key
# 3. Update .env
sed -i 's/old_key/new_key/' ~/.openclaw/.env
# 4. Test
./test_credentials.sh
This line is part of the same sed-based credential replacement example and inherits the same exposure risk: plaintext credentials may appear in shell history, process arguments, audit logs, or terminal recordings. In a credential-management skill, such examples are more sensitive because users may copy them verbatim during real secret rotations.
# 1. Revoke old key in service dashboard
# 2. Generate new key
# 3. Update .env
sed -i 's/old_key/new_key/' ~/.openclaw/.env
# 4. Test
./test_credentials.sh
# 5. Monitor logs
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
File patterns: x/credentials.json, twitter/credentials.json
Keys:
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
File patterns: x/credentials.json, twitter/credentials.json
Keys:
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
File patterns: x/credentials.json, twitter/credentials.json
Keys:
No suspicious patterns detected.