T03 · Remote Payload Retrieval and Execution
- Location
SKILL.md:118- Finding
Unverified Remote Installer Is Piped Directly into a Shell
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This is a coherent secrets-vault helper, but it documents unsafe installation and secret-handling patterns that warrant Review before use.
Review before installing. Require a verified, pinned Locker CLI installation path; remove examples that write secrets to .env, export all secrets, or place access keys in crontab; use read-only Locker keys by default; and avoid create/update paths that pass secret values in command-line arguments unless the CLI supports a safer stdin or file-descriptor mechanism.
SKILL.md:118Unverified Remote Installer Is Piped Directly into a Shell
scripts/vault-client.js:249Secret Values Are Exposed Through Child-Process Command-Line Arguments
references/cli-reference.md:102CLI Examples Encourage Plaintext Credential Exposure in Files, Environment State, Pipelines, and Crontab
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
Also use when creating cron jobs, scheduled tasks, integrations, or any process that requires
credentials — the skill ensures vault item IDs are stored instead of raw values. Triggers:
"secret", "credential", "API key", "token", "password", "vault", "locker", "access key",
"env var", "environment variable", ".env", "sensitive", "connection string", "webhook secret".
---
# Locker Vault — Secrets Management for OpenClaw Agents
The skill instructs users to install software by piping a remote script directly into bash. This is a classic supply-chain risk: if the remote server, transport, DNS, or published installer is compromised, arbitrary code will execute immediately on the agent host with the user's privileges.
# Download and install (check locker.io/secrets/download for latest)
curl -fsSL https://locker.io/secrets/install.sh | bash
# Verify installation
locker --version
The '| bash' pattern explicitly chains network retrieval to code execution without any verification boundary. In the context of a secrets-management skill intended for hosts with credential access, this is especially dangerous because compromise of the installer path could lead directly to theft of vault access keys or tampering with secret-handling behavior.
# Download and install (check locker.io/secrets/download for latest)
curl -fsSL https://locker.io/secrets/install.sh | bash
# Verify installation
locker --version
Referenced artifact was not completely inspected
Copy `scripts/vault-client.js` into the agent's workspace. The script has zero npm dependencies — it uses only Node.js built-in modules (`child_process`, `util`
Referenced artifact was not completely inspected
Copy `scripts/vault-client.js` into the agent's workspace. The script has zero npm dependencies — it uses only Node.js built-in modules (`child_process`, `util`
Referenced artifact was not completely inspected
Copy `scripts/vault-client.js` into the agent's workspace. The script has zero npm dependencies — it uses only Node.js built-in modules (`child_process`, `util`
Referenced artifact was not completely inspected
Copy `scripts/vault-client.js` into the agent's workspace. The script has zero npm dependencies — it uses only Node.js built-in modules (`child_process`, `util`
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
// ❌ WRONG: Writing to .env
fs.writeFileSync('.env', `API_KEY=${apiKey}`);
// ❌ WRONG: Hardcoding in config
Code accesses credential files (SSH keys, AWS credentials, etc.). This could indicate credential theft attempts.
// ❌ WRONG: Writing to .env
fs.writeFileSync('.env', `API_KEY=${apiKey}`);
// ❌ WRONG: Hardcoding in config
const config = { token: 'sk-live-abc123' };
Directing users to dump secrets into .env facilitates credential access by placing sensitive values in a plaintext file that is easy to exfiltrate, commit, or accidentally disclose. In the context of a secrets-management skill, this is a strong contradiction of the intended trust boundary and substantially increases exposure risk.
Output: One key per line, or a formatted table depending on CLI version.
Export all secrets to .env file:
locker secret list > .env
The documentation explicitly instructs users to export all secrets into a local .env file, which directly conflicts with the skill's stated anti-leakage purpose. Writing all secrets to disk materially increases the chance of credential disclosure through source control, backups, filesystem compromise, developer tooling, or accidental sharing.
This duplicate .env export finding is also a true issue because it promotes plaintext persistence of sensitive values in a commonly mishandled file format. Such files are frequently captured by tooling, backups, shell history workflows, or source control mistakes, making credential compromise more likely.
Export all secrets to .env file:
locker secret list > .env
The example recommends exporting all secrets as system variables for a child process, which broadens secret exposure across process boundaries and runtime inspection surfaces. In a skill whose purpose is preventing leakage, this pattern is especially dangerous because it normalizes indiscriminate secret materialization into process environments.
The cron example embeds raw access keys directly in the crontab, creating persistent plaintext credentials in system configuration. This is highly inconsistent with the skill's promise to store vault identifiers instead of raw secrets, and cron entries may be readable through administrative tooling, backups, or misconfigured permissions.
The cron pipeline chains secret retrieval directly into xargs and curl, causing the secret to flow through multiple process invocations and command-line contexts. This increases exposure through process listings, shell debugging, wrapper logs, and operational observability systems, especially in unattended scheduled jobs.
# crontab entry
0 */6 * * * LOCKER_ACCESS_KEY_ID=ak_xxx LOCKER_SECRET_ACCESS_KEY=sk_xxx locker secret get --name=API_TOKEN | xargs -I{} curl -H "Authorization: Bearer {}" https://api.example.com/sync
Piping a remotely fetched installer script directly into bash executes unverified code immediately and removes opportunities for inspection or integrity verification. This is a well-known supply-chain hazard, and in an agent-oriented skill it is especially risky because automation may perform the action without human review.
The instruction curl -fsSL https://locker.io/secrets/install.sh | bash is a classic remote-script execution pattern that can lead to arbitrary code execution if the host, transport, or distribution channel is compromised. Because this is documentation for agent use, the pattern is more dangerous: agents may execute it automatically without verifying provenance.
# macOS / Linux
curl -fsSL https://locker.io/secrets/install.sh | bash
# Verify
locker --version
Chaining a network fetch directly into bash creates an execution path where untrusted remote content becomes shell code with no validation barrier. This materially increases supply-chain and compromise impact because any malicious change upstream immediately becomes local code execution.
# macOS / Linux
curl -fsSL https://locker.io/secrets/install.sh | bash
# Verify
locker --version
Remote code is downloaded and executed. This bypasses code review and could introduce malicious code.
if (err.code === 'ENOENT') {
const error = new Error(
`VAULT_CLI_NOT_FOUND: The "${_config.cliPath}" binary was not found. ` +
`Install Locker CLI: curl -fsSL https://locker.io/secrets/install.sh | bash`
);
error.code = 'VAULT_CLI_NOT_FOUND';
throw error;
The skill describes and encourages use of shell execution and environment-based secret bootstrapping, but it does not declare an explicit tool scope or permission boundary in its own metadata. In an agent ecosystem, undocumented capability assumptions can cause the skill to be invoked in contexts with broader-than-expected privileges, increasing the chance of unsafe secret access or command execution.
The trigger list is extremely broad and includes common terms like 'secret', 'token', 'password', '.env', and 'sensitive', which can cause the skill to activate in many ordinary conversations. Because this skill is designed around credential handling and shell-backed vault access, accidental invocation expands the attack surface and raises the probability of unnecessary secret access workflows.
The guidance says environment variables are preferred for agents, even though the skill claims to minimize raw secret exposure and promote vault-reference handling. Environment variables are often visible to subprocesses, crash dumps, diagnostics, and sometimes other local users or orchestration layers, so this advice weakens the stated security posture.
The secret export examples lack any caution that .env files and environment variables can expose credentials through logs, process inspection, backups, and accidental commits. In a secrets-management skill, omission of these warnings makes misuse more likely and increases the chance of downstream credential leakage.
The markdown documents locker secret delete --name=SECRET_KEY as a standalone command but provides no user warning about deleting a secret. Because deletion can remove access to configuration or credentials and may be irreversible depending on backend behavior, the description should disclose that risk.
npx commands without a version suffix (e.g. @1.0.0) create a rug-pull risk if the upstream server is compromised and publishes a malicious update.
No suspicious patterns detected.