T09 · Insecure Skill Coding Practices
- Location
SKILL.md:130- Finding
LLM API Key Exposed Through Command-Line Arguments
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 130–139
Vulnerability Type: Credential exposure through process arguments and shell history
Risk Level: MediumVulnerable Documentation Snippet:
bash kannaka config set llm.provider anthropic|openai|ollama kannaka config set llm.api_key sk-... kannaka config set llm.model claude-sonnet-4-5|gpt-4o-mini|llama3 kannaka config set llm.base_url https://... # optional (OpenAI-compatible / Ollama)text API key fallback: `cfg.llm.api_key` → `ANTHROPIC_API_KEY` / `OPENAI_API_KEY` → `KANNAKA_LLM_API_KEY`.Technical Analysis
The documented configuration procedure places an LLM API key directly in a command-line argument. Depending on the operating system and shell, command arguments may be exposed through process-inspection interfaces while the command is running. The command may also be retained in shell history, terminal logs, command auditing systems, or support bundles.
The documentation additionally permits storing the key in application configuration but does not describe file-permission enforcement, encryption, or integration with an operating-system secret store. The implementation is not included in the audited project, so the security properties of configuration-file storage cannot be verified.
An attacker must generally have local access, access to shell-history backups, or access to process and audit telemetry. This is not evidence of intentional exfiltration, but it is an unsafe credential-handling pattern.
Attack Path
- A user follows the documented command and substitutes a valid provider API key for
sk-.... - The shell records the complete command in its history, or a local process-monitoring facility captures its arguments.
- A local attacker, another account with sufficient process visibility, an administrator, or a compromised diagnostics collector reads the exposed argument.
- The attacker submits ...[truncated 660 chars]
- A user follows the documented command and substitutes a valid provider API key for
- Remediation
View remediation
Remediation Suggestions
- Remove examples that pass secrets as command-line arguments.
- Add a hidden interactive prompt that reads the key without echoing it and without placing it in process arguments.
- Prefer integration with an operating-system keychain, dedicated secret manager, or credential helper.
- If configuration-file storage is unavoidable, create the file with owner-only permissions, reject insecure permissions, and avoid printing secret values through configuration-listing commands.
- Redact credentials from logs, diagnostics, error messages, and telemetry.
- Clearly document the security implications of environment variables, which can also be exposed in some environments.
- Advise users who followed the existing example to remove the command from shell history and rotate the affected key.
- Support short-lived and narrowly scoped provider credentials where available.