T09 · Insecure Skill Coding Practices
- Location
scripts/system_health.py:46- Finding
Hard-Coded PostgreSQL Credentials Exposed in Source Code and Process Arguments
- Content
View full analysis
Vulnerability Details
File Location:
scripts/system_health.py, lines 46, 99–102, 270–272, and 376–378
Vulnerability Type: Hard-coded credentials and plaintext credential exposure
Risk Level: MediumVulnerable Code
python # Postgres connection (Willow defaults) PG_DSN = "postgresql://willow:willow@localhost:5432/willow"python result = subprocess.run( ["python3", "-c", f"import psycopg2; c=psycopg2.connect('{PG_DSN}'); c.close(); print('ok')"], capture_output=True, text=True, timeout=6, )python result = subprocess.run( ["psql", PG_DSN, "-t", "-c", "SELECT COUNT(*) FROM knowledge_atoms WHERE domain != 'archived';"], capture_output=True, text=True, timeout=10, )python result = subprocess.run( ["psql", PG_DSN, "-t", "-A", "-F", "\t", "-c", query.strip()], capture_output=True, text=True, timeout=15, )Technical Analysis
The script embeds a PostgreSQL username and password directly in its source code through the
PG_DSNconstant. Anyone able to read the distributed Skill files can recover the credentials without needing to compromise a secret store or privileged configuration.The complete DSN is also interpolated into a child Python process and passed directly as an argument to
psql. Depending on the operating system and process-monitoring configuration, command-line arguments may be visible to other local users, monitoring agents, crash diagnostics, audit logs, or process inspection utilities. This expands exposure beyond users who can read the source file.Although the database is configured on
localhost, local-only accessibility does not eliminate the vulnerability. Any untrusted process, compromised local account, or code execution primitive on the same host could attempt to reuse the credentials. Risk increases if the default credentials are retained in production, the PostgreSQL service listens o ...[truncated 1619 chars]- Remediation
View remediation
Remediation Suggestions
- Remove the password-bearing DSN from source code and repository history.
- Prefer PostgreSQL peer authentication for local diagnostics where deployment constraints permit it.
- Alternatively, use a protected
.pgpassfile with permissions restricted to the owning user, or obtain the DSN from an approved runtime secret manager. - Do not place passwords in command-line arguments. Configure
psqlthrough a service definition, protected connection file, or another mechanism that does not expose secrets in process listings. - Replace known default credentials and require installation-specific, randomly generated credentials.
- Create a dedicated diagnostic database role with only the minimum read permissions required for the health queries. Do not grant schema modification, role management, database creation, or superuser privileges.
- Restrict PostgreSQL to the necessary local interface and enforce appropriate host-based authentication rules in
pg_hba.conf. - Rotate the exposed credential after deploying the fix, because removing it from current source does not invalidate previously distributed copies.
- Review repository history, logs, monitoring data, and deployment artifacts for additional copies of the DSN.
