T09 · Insecure Skill Coding Practices
- Location
SKILL.md:110- Finding
Hardcoded Weak PostgreSQL Credential in a Host-Exposed Container
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:110
Vulnerability Type: Hardcoded weak credential and unsafe database exposure
Risk Level: MediumVulnerable Code:
bash # Database container docker run -d --name postgres -e POSTGRES_PASSWORD=secret -v postgres-data:/var/lib/postgresql/data -p 5432:5432 postgres:15Technical Analysis
The documented command configures PostgreSQL with the predictable password
secretand publishes the database port using-p 5432:5432. Docker normally publishes such a port on the host's available interfaces unless a specific bind address is supplied. Consequently, the database may be reachable from other systems depending on host firewall and network configuration.The password is also supplied directly in the command line. It may remain in shell history and can be recovered through container configuration inspection by users or processes with sufficient local Docker access. Because the documentation presents this as a ready-to-run workflow, users may execute it without replacing the example credential or constraining network exposure.
Attack Path
- A user executes the documented command without changing the password or port mapping.
- Docker starts PostgreSQL with
POSTGRES_PASSWORD=secretand publishes TCP port 5432 on the host. - An attacker identifies a network path to the host's published PostgreSQL port.
- The attacker connects using the PostgreSQL account initialized by the image and the documented password
secret. - If authentication succeeds, the attacker accesses or modifies databases according to that account's PostgreSQL privileges.
A local attacker with adequate access to shell history, Docker metadata, or container inspection may alternatively recover the plaintext credential and use it to authenticate.
Impact Assessment
Successful exploitation could permit unauthorized PostgreSQL access with the privileges of the initializ ...[truncated 418 chars]
- Remediation
View remediation
Remediation Suggestions
-
Remove the literal password and require a strong, independently generated credential.
-
Avoid passing secrets directly on the command line. Use a protected environment file with restrictive permissions, the image's supported secret-file mechanism, or a container secret manager.
-
For local development, bind the published port to loopback only:
bash docker run -d \ --name postgres \ --env-file .postgres.env \ -v postgres-data:/var/lib/postgresql/data \ -p 127.0.0.1:5432:5432 \ postgres:15 -
Ensure
.postgres.envis permission-restricted and excluded from version control. -
If host access is unnecessary, do not publish port 5432; connect through a private Docker network instead.
-
Add an explicit warning that example credentials must never be reused in production.
-
Apply host firewall restrictions and limit database access to trusted clients.
-
Prefer pinning the image to an approved immutable digest for reproducible deployment.
-