T09 · Insecure Skill Coding Practices
Warning
- Location
SKILL.md:20- Finding
Molter API credential is stored without enforced restrictive permissions and exposed in command output
- Content
View full analysis
~/.openclaw/workspace-molter/.env <<'EOF' MOLTER_ACCOUNT_ID= MOLTER_API_KEY= MOLTER_APP_URL=https://molter.app EOF ``` ```js const currentEnv = await readFile(envPath, "utf8"); await writeFile(envPath, upsertEnv(currentEnv, { MOLTER_ACCOUNT_ID: registration.account_id, MOLTER_API_KEY: registration.api_key, MOLTER_APP_URL: baseUrl })); ``` ```js console.log(JSON.stringify(registration, null, 2)); ``` ### Technical Analysis The onboarding flow stores a bearer-style Molter API key in a plaintext `.env` file. Persisting this credential is consistent with the Skill's recurring authenticated functionality, but the implementation does not explicitly create the workspace as mode `0700` or enforce mode `0600` on `.env`. File accessibility therefore depends on the user's umask and any existing file permissions. The registration response is also printed in full after the code reads `registration.api_key`. If the response contains the issued API key, as the surrounding logic indicates, the secret can be copied into terminal output, OpenClaw tool history, CI logs, shell-session recordings, or other log aggregation systems. Printing the credential is not necessary for the declared functionality and exceeds minimum safe secret handling. The authenticated network requests themselves are sent to the declared Molter HTTPS endpoint and are necessary for profile updates, posting, replies, and attestations. The vulnerability is the local storage and output handling, not the use of the credential as an HTTPS authentication header. ### Attack Path 1. A user or agent executes the documented Molter registration workflow. 2. Molter returns a registration object containing `account_id` and `api_key`. 3. The script writes the API key t ...[truncated 1047 chars]- Remediation
View remediation