T09 · Insecure Skill Coding Practices
- Location
SKILL.md:240- Finding
Hardcoded Weak PostgreSQL Credential with Public Port Exposure
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 240–247
Vulnerability Type: Hardcoded weak credential and unsafe network exposure
Risk Level: HighVulnerable Code:
bash docker run -d \ --name postgres \ -e POSTGRES_PASSWORD=secret \ -e POSTGRES_DB=mydb \ -v postgres-data:/var/lib/数据库/data \ -p 5432:5432 \ postgres:15Technical Analysis
The documented workflow initializes PostgreSQL with the predictable password
secret. The-p 5432:5432option publishes the database port on all host interfaces by default rather than restricting access to the loopback interface.If an agent executes this example on a host whose firewall or cloud security rules permit inbound TCP traffic to port 5432, an attacker can reach the database and attempt authentication using the credential disclosed by the skill. Because
POSTGRES_PASSWORDnormally configures the password for PostgreSQL's default administrative account, successful authentication could grant extensive control over the database service.This is an insecure configuration example rather than evidence of an intentionally malicious payload. Nevertheless, an agent following the instructions can create an exploitable service.
Attack Path
- A user asks the agent to deploy a PostgreSQL container using the documented workflow.
- The agent executes the example with
POSTGRES_PASSWORD=secret. - Docker publishes container port 5432 on the host's available interfaces.
- A remote attacker identifies the exposed PostgreSQL service by scanning or otherwise discovering the host.
- The attacker connects to port 5432 and authenticates using the known default administrative username and documented password.
- Subject to PostgreSQL configuration and network controls, the attacker accesses, modifies, or deletes databases managed by the container.
Impact Assessment
Successful exploitation may permit unauthorized admini ...[truncated 555 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove the literal password and require a strong, independently generated secret.
- Supply credentials through Docker secrets or another managed secret store. If an environment file is necessary for local development, restrict its permissions and exclude it from version control.
- Bind development-only database access to loopback:
bash -p 127.0.0.1:5432:5432 - Prefer an internal Docker network without publishing the database port when only other containers require access.
- Add explicit warnings that sample credentials must never be used in production.
- Restrict inbound access with host firewalls, cloud security groups, and PostgreSQL access-control rules.
- Rotate the password immediately if this example has already been deployed.
- Pin the PostgreSQL image to a reviewed immutable digest and maintain a documented image-update process.
- Require user confirmation before the agent executes a command that publishes a database service.
A safer illustrative workflow is:
bash docker network create app-internal docker run -d \ --name postgres \ --network app-internal \ -e POSTGRES_PASSWORD_FILE=/run/secrets/postgres_password \ -e POSTGRES_DB=mydb \ -v postgres-data:/var/lib/postgresql/data \ --secret postgres_password \ postgres@sha256:<reviewed-image-digest>