T09 · Insecure Skill Coding Practices
- Location
scripts/alibaba_cloud_model_setup.py:107- Finding
API Key Exposure Through Command-Line Arguments
- Content
View full analysis
- Remediation
View remediation
Security audit
Security checks for vulnerabilities and agentic risk
This setup skill is purpose-aligned, but it needs review because it handles Alibaba Cloud API keys with weak secret-storage and exposure safeguards.
Review this before installing if you will use a real paid Alibaba Cloud key. Prefer an environment variable or secret manager, avoid passing the key with --api-key, avoid inline storage unless you accept plaintext local-file risk, check config and backup permissions, and rotate any key that was written to a shared config, backup, shell history, or logs.
scripts/alibaba_cloud_model_setup.py:107API Key Exposure Through Command-Line Arguments
scripts/alibaba_cloud_model_setup.py:410Plaintext Inline API Key Written Without Enforced Restrictive Permissions
The documented behavior understates what the skill can do: it is not strictly interactive, it can run via CLI flags, and it performs remote API-key validation over the network. This mismatch can mislead operators and automated policy systems about the skill's actual execution model and trust boundary, which is dangerous for a credential-handling setup flow.
The skill advertises operational behavior that includes shell execution, file reads/writes, and network access, but it declares no explicit tool scope or permissions boundary. That makes the skill harder to audit and increases the chance an agent will invoke powerful capabilities without clear user visibility or policy enforcement.
The skill intentionally writes persistent configuration and backups, including provider settings and potentially credentials, to disk. Persistence is expected for a setup skill, but it still enlarges the attack surface because secrets or sensitive configuration may remain in config files and backup copies after the session ends.
- API key storage mode (env-var recommended or inline)
- Primary model selection
- Whether to set as default model
4. **Validate API key** against selected site before config write
5. **Backup existing config** before modification
6. **Update config** with provider, models, and defaults
7. **Validate JSON** and report final status
The example configuration includes an inline apiKey field in plaintext and does not prominently warn against storing secrets directly in config files. Users often copy examples verbatim, so this pattern can lead to long-lived credential exposure through local files, backups, logs, screenshots, or source control.
The document recommends exporting a long-lived API key and adding it to shell startup files for persistence, but it does not warn that this exposes the credential to local account compromise, shell-history mishandling, accidental disclosure during debugging, or inheritance into child processes and tooling. In a setup skill that guides users through provider configuration, this normalizes weak secret-handling practices and can lead to credential theft or misuse of paid cloud resources.
Although labeled 'Not Recommended,' the inline JSON example still shows plaintext API key storage in a primary configuration file without a strong warning about source-control leaks, backups, shared home directories, or accidental disclosure through support bundles and screenshots. Because this skill is specifically for configuring OpenClaw, users are likely to copy the example directly, making credential compromise a realistic outcome.
The script exposes options implying it may persist API credentials into shell profiles or systemd user overrides, expanding from local config editing into persistence of secrets in broader execution contexts. That increases the chance of accidental credential exposure, long-lived secret retention, and unintended use by other processes or future sessions.
The script defines a feature to write an API key export directly into a shell profile, creating durable credential persistence outside the tool's immediate config scope. Persisting secrets in startup files can expose them to other local users, shell history mishandling, backups, and unrelated processes that inherit the environment.
parser.add_argument(
"--persist-env-shell",
action="store_true",
help="Write export line to shell profile (default ~/.bashrc) when using env key mode.",
)
parser.add_argument(
"--shell-profile",
When api_key_source is set to inline, the script writes the API key directly into the JSON configuration file in plaintext. Plaintext credentials in config files are commonly exposed through backups, source control, filesystem access by other local users, or diagnostic collection, making credential compromise much more likely.
Skill establishes unauthorized persistence across sessions via cron jobs, startup scripts, or state files. Session persistence allows an attacker to maintain access beyond the current interaction.
if api_key_source == "env":
print(f"\n🔐 API key stored in environment variable: {env_var}")
print(f" Add to ~/.bashrc: export {env_var}=YOUR_KEY")
print(f"\n🚀 Next steps:")
print(f" 1. Restart Gateway: openclaw gateway restart")
The manifest says configuration happens 'through a strict interactive flow,' implying guided prompting is the intended behavior. However, the argument parser accepts plan, site, API key, model, default-setting, and other options directly, allowing the skill to bypass the interactive flow entirely.
No suspicious patterns detected.