T09 · Insecure Skill Coding Practices
- Location
SKILL.md:62- Finding
Bearer Token Stored in a Predictable Shared Temporary File
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 62–63 and 111–112
Vulnerability Type: Insecure storage of authentication credentials in a shared temporary directory
Risk Level: MediumVulnerable Code
Registration flow:
bash TOKEN="TOKEN_VALUE_FROM_RESPONSE" echo -n "$TOKEN" > /tmp/clawmart_token.txtLogin flow:
bash echo -n "TOKEN_VALUE" > /tmp/clawmart_token.txt TOKEN=$(cat /tmp/clawmart_token.txt)Technical Analysis
The Skill instructs the agent to store a reusable ClawMart bearer token as plaintext at the fixed path
/tmp/clawmart_token.txt. It does not set restrictive permissions, securely create the file, verify file ownership, reject symbolic links, or remove the token after the requested operation is complete.A predictable file in a shared temporary directory creates several security risks:
- Another local process or user may read the token if the process umask permits overly broad file permissions.
- A pre-existing file or symbolic link at this path may redirect or interfere with the write, subject to operating-system protections and the privileges of the process.
- Concurrent Skill executions can overwrite or consume one another's tokens, potentially causing cross-account operations.
- The token can remain on disk after the session, extending its exposure beyond the period required for the task.
- File contents may be captured by host backups, diagnostics, or forensic collection.
The network transmission of credentials, bearer tokens, profile information, and user-selected images to the configured ClawMart API is consistent with the declared store-management functionality and uses HTTPS by default. The confirmed issue is the unnecessary persistence of the bearer token in an insecure shared location, rather than the API communication itself.
Attack Path
- An attacker with local access monitors the predictable path
/tmp/clawmart_token.txtor ...[truncated 1315 chars]
- Remediation
View remediation
Remediation Suggestions
-
Keep the bearer token only in process memory for the duration of the requested operation. Avoid writing it to disk when persistence is not essential.
-
If temporary persistence is unavoidable, use a private per-user runtime directory such as
$XDG_RUNTIME_DIR, rather than a fixed path in/tmp. -
Create token files atomically with permissions restricted to the current user:
bash TOKEN_FILE="$(mktemp "${XDG_RUNTIME_DIR:-$HOME/.cache}/clawmart-token.XXXXXX")" chmod 600 "$TOKEN_FILE" printf '%s' "$TOKEN" > "$TOKEN_FILE" -
Ensure the parent directory is owned by the current user and has permissions no broader than
0700. -
Reject symbolic links and verify file ownership and permissions before reading an existing token file.
-
Use a unique token file for each invocation to prevent cross-session and cross-account collisions.
-
Register cleanup logic and delete the token immediately after use:
bash trap 'rm -f -- "$TOKEN_FILE"' EXIT INT TERM -
Prefer an operating-system credential store or secret-management service if tokens must persist across sessions.
-
Revoke exposed tokens and require re-authentication when token-file integrity or confidentiality cannot be established.
-
Require explicit user confirmation and HTTPS validation before sending credentials, tokens, or files to a user-supplied self-hosted API endpoint.
-