T09 · Insecure Skill Coding Practices
- Location
SKILL.md:62- Finding
Insecure Database Credential Storage Guidance
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 62–77
Vulnerability Type: Plaintext sensitive credential exposure
Risk Level: MediumVulnerable Code
ini [client] host = localhost user = your_username password = your_password database = your_databasebash export MYSQL_HOST=localhost export MYSQL_USER=your_username export MYSQL_PASSWORD=your_password export MYSQL_DATABASE=your_databaseTechnical Analysis
The skill instructs users to store a MySQL password directly in
~/.my.cnf, but it does not require restrictive file permissions or verify file ownership. If the file is readable by other local accounts or processes, the database credential can be recovered in plaintext.The alternative recommendation exposes the password through the
MYSQL_PASSWORDenvironment variable. Environment variables are inherited by child processes and may also be captured by diagnostic tooling, debugging utilities, process inspection mechanisms, or crash reports. This unnecessarily broadens credential exposure.The examples use placeholders rather than embedded real credentials; therefore, this is unsafe security guidance rather than a hardcoded-secret incident in the distributed project.
Attack Path
- A user follows the skill instructions and places a valid database password in
~/.my.cnfwithout applying restrictive permissions, or exports it throughMYSQL_PASSWORD. - A local user or compromised process reads the configuration file, inspects an accessible process environment, or obtains the environment from diagnostics or logs.
- The attacker extracts the MySQL username, password, host, and database name.
- The attacker authenticates to the configured MySQL server.
- The attacker performs any operation permitted to that account, potentially including reading records, modifying data, deleting data, changing schemas, or creating database exports.
Exploitation requires local process or account access sufficient to ret ...[truncated 716 chars]
- A user follows the skill instructions and places a valid database password in
- Remediation
View remediation
Remediation Suggestions
- Require restrictive ownership and permissions when using an option file:
bash touch ~/.my.cnf chmod 600 ~/.my.cnf chown "$(id -u):$(id -g)" ~/.my.cnf- Prefer MySQL’s encrypted login-path facility over a plaintext password:
bash mysql_config_editor set \ --login-path=project-db \ --host=localhost \ --user=your_username \ --passwordThen connect with:
bash mysql --login-path=project-db your_database-
For automated environments, retrieve credentials at runtime from a managed secret store and avoid placing secrets in source files, shell initialization files, command-line arguments, or long-lived environment variables.
-
Use a dedicated MySQL account with only the permissions required for the requested task. Separate read-only, write, backup, restore, and administrative roles.
-
Document credential rotation procedures and rotate credentials immediately if configuration files, environments, logs, diagnostics, or backups containing them may have been exposed.
-
Add explicit warnings that configuration files and SQL backups must not be committed to version control and must be protected using restrictive filesystem permissions and encryption where appropriate.