T09 · Insecure Skill Coding Practices
- Location
SKILL.md:50- Finding
Database Credentials Exposed Through Command-Line Arguments
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 50–52 and 65–71
Vulnerability Type: Command-line credential exposure
Risk Level: MediumVulnerable Code
bash # PostgreSQL psql "postgresql://user:password@host:5432/dbname" -c "\dt" psql "postgresql://user:password@host:5432/dbname" -c "\d table_name" psql "postgresql://user:password@host:5432/dbname" -c "SELECT count(*) FROM table_name;" # MongoDB mongosh "mongodb://user:password@host:27017/dbname" --eval "db.getCollectionNames()" mongosh "mongodb://user:password@host:27017/dbname" --eval "db.collection_name.countDocuments()" # Redis redis-cli -h host -p 6379 -a password INFO keyspace redis-cli -h host -p 6379 -a password DBSIZE redis-cli -h host -p 6379 -a password KEYS "*"Technical Analysis
The examples place plaintext database passwords directly in command-line arguments. When an agent replaces the placeholders with real credentials, those secrets may become visible through shell history, command auditing, execution telemetry, debug logs, or process inspection available to other sufficiently privileged local users.
This guidance also conflicts with the safety rule at line 82:
markdown 4. **No passwords in history** — Use environment variables or connection strings, don't echo passwordsA connection string containing an embedded password remains sensitive when passed directly as a command-line argument. Merely using a URI does not prevent its disclosure.
Attack Path
- A user supplies valid PostgreSQL, MongoDB, or Redis credentials to the agent.
- The agent substitutes those credentials into one of the documented commands.
- The command, including its plaintext password, is recorded in shell history, agent logs, audit telemetry, or process metadata.
- An attacker with access to those records or sufficient local process-inspection privileges extracts the credential.
- The attacker connects t ...[truncated 922 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove all examples that embed passwords in command-line arguments or database URIs passed directly to client programs.
- Use each client's protected authentication mechanism:
- PostgreSQL: use
PGPASSFILEor.pgpasswith file permissions restricted to0600. - MySQL: use
mysql_config_editorand a named login path. - Redis: use
REDISCLI_AUTHwhile ensuring the execution environment and logs do not disclose environment variables. - MongoDB: use an interactive password prompt or an appropriately protected client configuration mechanism.
- PostgreSQL: use
- Display redacted commands before execution, replacing passwords with a fixed value such as
[REDACTED]. - Prevent secrets from being written to shell history, agent traces, debug output, or audit logs.
- Store any temporary credential files outside shared directories, apply restrictive permissions, and securely remove them after use.
- Prefer short-lived, narrowly scoped, read-only database credentials for exploration.
- Add an explicit rule that connection strings containing credentials are secrets and must never be printed or passed visibly on the command line.
- Update examples to use non-secret references, such as:
bash PGPASSFILE="$HOME/.pgpass" psql -h host -p 5432 -U user -d dbname -c "\dt" redis-cli -h host -p 6379 INFO keyspaceFor Redis, authentication should be supplied through a protected mechanism rather than the
-acommand-line option.