T09 · Insecure Skill Coding Practices
- Location
SKILL.md:29- Finding
API Token Exposure Through Plaintext Command-Line Setup Examples
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 29-58
Vulnerability Type: Plaintext sensitive data exposure
Risk Level: MediumVulnerable Code
macOS example at line 29:
bash security add-generic-password -a "$USER" -s "daily-dev-api" -w "dda_your_token"Windows example at line 41:
powershell $credential = New-Object System.Management.Automation.PSCredential("daily-dev-api", (ConvertTo-SecureString "dda_your_token" -AsPlainText -Force))Linux example at line 58:
bash echo "dda_your_token" | secret-tool store --label="daily.dev API Token" service daily-dev-api username "$USER"Technical Analysis
The setup documentation encourages users to replace
dda_your_tokenwith an actual API token directly inside an interactive command. Although the commands subsequently place the token in an operating-system credential store, the token is exposed in plaintext during initial entry.On macOS and Linux, the substituted command may be retained in shell history. The token may also be temporarily visible through process inspection because it is supplied as a command-line argument to
securityorecho. In PowerShell, the plaintext token can remain in command history and is explicitly passed toConvertTo-SecureStringusing-AsPlainText -Force.The Skill correctly states that tokens must only be transmitted to
api.daily.dev, and its documented network requests target that domain. The necessary authenticated API communication is therefore not itself an unauthorized exfiltration behavior. The vulnerability is the insecure local handling of the token before it reaches secure storage.Attack Path
- A user follows the setup instructions and replaces
dda_your_tokenwith a valid daily.dev API token. - The user executes the resulting command in Bash, Zsh, or PowerShell.
- The command containing the plaintext token is retained in shell history, terminal logs, ses ...[truncated 1329 chars]
- A user follows the setup instructions and replaces
- Remediation
View remediation
Remediation Suggestions
-
Do not instruct users to place a real token directly in a command that may be saved in shell history.
-
Prompt for the token without terminal echo and pass it to the credential-storage command without exposing it as a command-line argument where platform capabilities permit.
-
For POSIX shells, use a silent prompt and clear the temporary variable immediately after storage:
bash read -rsp "daily.dev API token: " DAILY_DEV_TOKEN printf '\n' printf '%s' "$DAILY_DEV_TOKEN" | secret-tool store --label="daily.dev API Token" service daily-dev-api username "$USER" unset DAILY_DEV_TOKEN -
For PowerShell, use
Read-Host -AsSecureStringinstead of embedding the token as plaintext:powershell $secureToken = Read-Host "daily.dev API token" -AsSecureString $credential = [System.Management.Automation.PSCredential]::new( "daily-dev-api", $secureToken ) $credential | Export-Clixml "$env:USERPROFILE\.daily-dev-credential.xml" Remove-Variable secureToken, credential -
On macOS, prefer a silent prompt and avoid documenting a literal secret. If platform tooling requires conversion to plaintext or a command-line argument, clearly disclose the residual exposure and recommend entering the token through a trusted graphical Keychain interface instead.
-
Ensure exported credential files have restrictive permissions and are not synchronized to shared or untrusted storage.
-
Add an explicit warning not to paste tokens into shell commands, scripts, configuration committed to version control, issue reports, or terminal sessions being recorded.
-
Recommend revoking and rotating any token that may already have been entered using the documented plaintext commands.
-