T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:15
- Finding
- API Key Disclosure Through Terminal Output and Plaintext Shell-Profile Storage## Vulnerability Details **File Location**: `SKILL.md`, lines 15–29 **Vulnerability Type**: Plaintext sensitive-data exposure **Risk Level**: Medium ### Vulnerable Code ```bash echo "$USERCALL_API_KEY" ``` If the variable is empty, the Skill instructs the user to configure it as follows: ```bash export USERCALL_API_KEY="your_key_here" ``` It then recommends persistent plaintext storage: ```text Add that line to your `~/.zshrc` or `~/.bashrc` to make it permanent, then restart your terminal. ``` ### Technical Analysis The API-key availability check prints the complete value of `USERCALL_API_KEY` to standard output. This is unnecessary because the Skill only needs to determine whether the variable is configured. Exposing the value can place the bearer token in terminal recordings, command-execution logs, agent transcripts, CI logs, or shared terminal output. The setup instructions also recommend storing the API key directly in a shell initialization file. These files are plaintext, are commonly included in workstation backups or configuration repositories, and may be readable by other local processes or users when permissions are insufficient. The combination of persistent plaintext storage and explicit terminal disclosure increases the likelihood of credential compromise. ### Attack Path 1. A user follows the Skill instructions and places the Usercall API key in `~/.zshrc` or `~/.bashrc`. 2. The shell loads the key into `USERCALL_API_KEY`. 3. The Skill executes `echo "$USERCALL_API_KEY"`, exposing the complete credential in terminal output. 4. An attacker obtains the output through a recorded agent transcript, terminal log, CI log, screen-sharing session, or another process with access to captured output. Alternatively, the attacker reads the plaintext shell profile or an associated backup. 5. The attacker reuses the disclosed value as a bearer token against the Usercall API. 6. Subject to the token's server-side permissions, the attacker may create o ...[truncated 756 chars]
- Remediation
- ## Remediation Suggestions 1. Replace the secret-printing command with a presence-only test: ```bash if [ -n "${USERCALL_API_KEY:-}" ]; then echo "USERCALL_API_KEY is configured" else echo "USERCALL_API_KEY is not configured" fi ``` 2. Do not display the key, even partially, in normal execution output. Ensure error handling and debugging modes also redact the `Authorization` header and environment-variable value. 3. Recommend storage in an operating-system credential manager, dedicated secrets manager, or another access-controlled secret store instead of a shell startup file. 4. If environment-file or shell-profile storage must be documented, clearly warn that the file contains a secret, require restrictive permissions such as `chmod 600`, and advise users not to commit it to version control or include it in publicly accessible backups. 5. Advise users to rotate the API key immediately if it has appeared in logs, transcripts, screenshots, shared terminal sessions, or repositories. 6. Where supported by Usercall, use narrowly scoped, revocable API tokens and monitor account activity for unauthorized requests.