T09 · Insecure Skill Coding Practices
- Location
SKILL.md:204- Finding
Hardcoded PostgreSQL Administrative Credentials
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 204-205
Vulnerability Type: Hardcoded plaintext database credentials
Risk Level: HighVulnerable code snippet:
yaml username: postgres password: postgresTechnical Analysis
The skill documentation exposes a static PostgreSQL username and password. The
postgresaccount is commonly configured as a database superuser, while the password is identical to the username and is easily guessed.Although the example uses a localhost database URL, developers may copy this configuration into shared, containerized, testing, or production environments. If PostgreSQL is reachable from another host and the documented credentials remain active, an attacker can authenticate without needing to discover or crack a secret.
Attack Path
- An attacker obtains the skill documentation or recognizes that a target uses the documented PigX configuration.
- The attacker identifies a reachable PostgreSQL service associated with the deployment.
- The attacker attempts authentication using the disclosed
postgresusername andpostgrespassword. - If the documented default remains active, the attacker authenticates as the PostgreSQL account.
- Depending on the account configuration, the attacker reads or modifies application data, creates additional database roles, changes permissions, or executes database features available to that account.
Exploitation requires the credentials to remain unchanged and the database to be accessible to the attacker.
Impact Assessment
A successful attacker could obtain access to all databases and records available to the
postgresaccount. If it retains its usual superuser privileges, the scope may include complete database confidentiality, integrity, and availability compromise, role and permission administration, and access to database-server capabilities exposed to PostgreSQL superusers.- Remediation
View remediation
Remediation Suggestions
- Remove functional usernames and passwords from the documentation.
- Replace them with explicit nonfunctional placeholders such as
${DB_USERNAME}and${DB_PASSWORD}. - Load credentials from environment variables, mounted secret files, or a managed secrets platform.
- Generate a unique, high-entropy database password for every environment.
- Avoid using the PostgreSQL superuser for application connections. Create a dedicated role with only the required schema and operation privileges.
- Restrict PostgreSQL network exposure through firewall rules, private networks, and restrictive
pg_hba.confentries. - Rotate
postgres/postgresimmediately in every deployment where it may have been copied or retained. - Add secret scanning to documentation and repository CI checks to prevent future credential disclosure.