T01 · Skill Instruction Hijacking
- Location
SKILL.md:673- Finding
Mandatory Cross-Skill Enforcement Hijacks Agent and Skill Behavior
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This skill has a legitimate credential-management purpose, but it asks for broad control over sensitive local credentials and includes unsafe guidance and scripts that could expose or damage them.
Review carefully before installing. Do not use this as a mandatory cross-skill policy without explicit opt-in, do not store the GPG passphrase in the same .env, do not source generated .env files as shell code unless values are safely serialized, and avoid running cleanup or setup-gpg.sh until you have verified backups and understand the global GPG changes.
SKILL.md:673Mandatory Cross-Skill Enforcement Hijacks Agent and Skill Behavior
SKILL.md:614Shell Command Injection Through GPG Passphrase in Recommended Node.js Loader
scripts/consolidate.py:121Unescaped Credential Values Are Written to a File Later Executed as Shell Code
scripts/encrypt.py:50Decryption Failure Can Silently Overwrite Existing Encrypted Secrets
scripts/setup-gpg.sh:59Skill-Specific Setup Overwrites Global GPG Security Configuration
Mandating that all credentials live in '~/.openclaw/.env' creates a single high-value target in a predictable location. If any skill, script, backup process, or local compromise gains read access to that file, all consolidated credentials may be exposed at once.
There is exactly ONE location for all OpenClaw credentials:
~/.openclaw/.env
No exceptions. Not workspace, not skills, not scripts. Root only.
The rule explicitly instructs scanning and consolidating files such as '~/.config/*/credentials.json' into a single .env file. Broadly harvesting credential files across unrelated tools or services can pull in secrets beyond OpenClaw's scope, increase unnecessary access to sensitive material, and weaken separation between applications.
- `~/.openclaw/workspace/skills/*/.env` ❌ → Root
- `~/.openclaw/workspace/skills/*/repo/.env` ❌ → Root
- `~/.openclaw/workspace/scripts/.env` ❌ → Root
- `~/.config/*/credentials.json` ❌ → Root
- Any scattered API key files ❌ → Root
## Enforcement
The enforcement section describes detecting all credential files, merging them into one location, and removing originals. This operational pattern can over-collect secrets, erase separation of duties, and turn one file compromise into full credential compromise, especially because the skill frames consolidation as mandatory.
The credential-manager skill enforces this rule:
1. **Scan:** Detects ALL .env files and credential files
2. **Consolidate:** Merges everything into `~/.openclaw/.env`
3. **Cleanup:** Removes scattered files (after backup)
4. **Validate:** Ensures no scattered files remain
The guidance tells all skill developers to load credentials from a shared root secret file. This encourages broad credential exposure across skills, including skills that may only need a subset of secrets, and increases the chance that a compromised or buggy skill can read unrelated credentials.
## For Skill Developers
**DO NOT create .env files in your skill directories.**
Load credentials from root:
The shell example explicitly uses 'source ~/.openclaw/.env', which executes the contents of that file in the current shell. If the .env contains shell metacharacters, command substitutions, or malicious content, sourcing it can execute arbitrary commands in addition to exposing all loaded secrets to the process environment.
#!/bin/bash
# Load from root .env
source ~/.openclaw/.env
# Use credentials
The Python example directs developers to read a shared root .env file, reinforcing centralized plaintext secret access from any skill code. While less dangerous than shell sourcing, it still promotes broad, predictable access to all credentials from code that may not need them.
#!/usr/bin/env python3
# Load from root .env
from pathlib import Path
env_file = Path.home() / '.openclaw' / '.env'
# ... load and use
The skill markets itself as a mandatory security foundation with encryption, rotation tracking, deep scanning, permission enforcement, and migration support, but the analysis indicates those controls are missing, partial, or delegated elsewhere. This kind of security overclaim can cause operators to trust the skill, store secrets under false assumptions, and skip compensating controls.
The skill markets itself as a mandatory security foundation with encryption, rotation tracking, deep scanning, permission enforcement, and migration support, but the analysis indicates those controls are missing, partial, or delegated elsewhere. This kind of security overclaim can cause operators to trust the skill, store secrets under false assumptions, and skip compensating controls.
The skill markets itself as a mandatory security foundation with encryption, rotation tracking, deep scanning, permission enforcement, and migration support, but the analysis indicates those controls are missing, partial, or delegated elsewhere. This kind of security overclaim can cause operators to trust the skill, store secrets under false assumptions, and skip compensating controls.
The skill markets itself as a mandatory security foundation with encryption, rotation tracking, deep scanning, permission enforcement, and migration support, but the analysis indicates those controls are missing, partial, or delegated elsewhere. This kind of security overclaim can cause operators to trust the skill, store secrets under false assumptions, and skip compensating controls.
The skill markets itself as a mandatory security foundation with encryption, rotation tracking, deep scanning, permission enforcement, and migration support, but the analysis indicates those controls are missing, partial, or delegated elsewhere. This kind of security overclaim can cause operators to trust the skill, store secrets under false assumptions, and skip compensating controls.
The skill markets itself as a mandatory security foundation with encryption, rotation tracking, deep scanning, permission enforcement, and migration support, but the analysis indicates those controls are missing, partial, or delegated elsewhere. This kind of security overclaim can cause operators to trust the skill, store secrets under false assumptions, and skip compensating controls.
The skill markets itself as a mandatory security foundation with encryption, rotation tracking, deep scanning, permission enforcement, and migration support, but the analysis indicates those controls are missing, partial, or delegated elsewhere. This kind of security overclaim can cause operators to trust the skill, store secrets under false assumptions, and skip compensating controls.
The skill markets itself as a mandatory security foundation with encryption, rotation tracking, deep scanning, permission enforcement, and migration support, but the analysis indicates those controls are missing, partial, or delegated elsewhere. This kind of security overclaim can cause operators to trust the skill, store secrets under false assumptions, and skip compensating controls.
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
- `~/.local/share/*/credentials.json` — Local share directories
**Sensitive Key Patterns:**
- API keys, access tokens, bearer tokens
- Secrets, passwords, passphrases
- OAuth consumer keys
- Private keys, signing keys, wallet keys
The documentation says high-value secrets should never exist as plaintext on disk, then later recommends storing the GPG passphrase in the same plaintext .env file. That collapses the protection boundary: anyone who can read the .env can also decrypt the supposedly protected secrets.
The instructions explicitly tell users to store the GPG passphrase in the main .env without warning that this defeats much of the benefit of encrypting high-value secrets. Users following the guide would create a single compromise point for both encrypted data and the decryption key.
Recommending the central credential file as storage for the GPG passphrase creates a natural-language secret exfiltration path in the very file meant to centralize credentials. A compromise of that file yields both application credentials and the means to decrypt protected private keys, magnifying blast radius.
The documentation includes a direct rm of a credential file after migration. In a skill that already overclaims safety and supports auto-confirm flows, destructive cleanup can cause accidental loss of the only usable credential copy or delete the wrong file if migration/backup validation is incomplete.
cp ~/.openclaw/farcaster-credentials.json ~/.openclaw/backups/credentials-old-YYYYMMDD/farcaster-credentials.json.bak chmod 600 ~/.openclaw/backups/credentials-old-YYYYMMDD/farcaster-credentials.json.bak rm ~/.openclaw/farcaster-credentials.json
### Step 7: Update Scripts That Referenced Old Files
The 'secure' Bash and Node examples interpolate or pipe the passphrase into shell commands, exposing it to process arguments, shell history, logs, crash dumps, or child-process capture. This undermines the claimed GPG protection and creates additional plaintext exposure paths for the most sensitive secret.
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
The documentation recommends decrypting secrets into /tmp/.env, which is a globally predictable temporary path and may be exposed to other local processes or users depending on system configuration. It also increases the chance of leaving plaintext secrets behind on disk after use.
# Encrypt .env with GPG
gpg -c ~/.openclaw/.env
# Decrypt when needed
gpg -d ~/.openclaw/.env.gpg > /tmp/.env
This line is part of the same decryption example that writes plaintext credentials to /tmp/.env. Storing decrypted secrets in a temporary shared location creates avoidable local exposure and persistence risk.
gpg -c ~/.openclaw/.env
gpg -d ~/.openclaw/.env.gpg > /tmp/.env
### Use Secret Managers
The incident-response example uses sed -i 's/old_key/new_key/' ~/.openclaw/.env, which can place secret values directly in shell history, process arguments, and potentially logs or monitoring tools. That undermines the surrounding guidance about avoiding secret exposure in command lines and terminals.
# 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
No suspicious patterns detected.