T09 · Insecure Skill Coding Practices
- Location
docker-compose.yml:5- Finding
Predictable Default Redis Credential Exposes Data on the Shared Docker Network
- Content
View full analysis
Vulnerability Details
File Location:
docker-compose.yml:5
Vulnerability Type: Predictable default credential and plaintext secret exposure
Risk Level: MediumVulnerable Code
yaml services: redis: image: redis:7.4-alpine container_name: ${REDIS_CONTAINER:-codai_redis} restart: unless-stopped command: redis-server --requirepass ${REDIS_PASSWORD:-redispass} --maxmemory ${REDIS_MAXMEMORY:-256mb} --maxmemory-policy allkeys-lruRelated credential exposure also appears in the health check at
docker-compose.yml:12-14:yaml healthcheck: test: ["CMD", "redis-cli", "-a", "${REDIS_PASSWORD:-redispass}", "ping"]The runtime script establishes the same fallback at
run.sh:26:bash REDIS_PASSWORD="${REDIS_PASSWORD:-redispass}"Technical Analysis
Redis starts with the fixed, publicly documented fallback password
redispassif the operator does not defineREDIS_PASSWORD. Althoughrun.shprints a warning for some operations, it does not prevent Redis from starting with this credential.The service joins the shared external Docker network
nginx-proxy_net. Docker containers attached to the same network can connect directly to Redis on port 6379, bypassing the localhost-only host-port binding. Consequently, the127.0.0.1port mapping does not protect Redis from other containers on the shared network.The password is also passed in Redis process arguments and embedded in Docker health-check configuration. Depending on Docker access and process visibility, it may be recoverable through container inspection or process information. However, the primary weakness is that an attacker does not need to recover it when the predictable default remains active.
Attack Path
- An attacker gains control of an existing container on
nginx-proxy_net, or starts a container attached to that network where local Docker permissions permit it. - Th ...[truncated 1455 chars]
- An attacker gains control of an existing container on
- Remediation
View remediation
Remediation Suggestions
-
Remove the fallback credential and make a strong password mandatory:
yaml command: - redis-server - --requirepass - ${REDIS_PASSWORD:?REDIS_PASSWORD must be set} - --maxmemory - ${REDIS_MAXMEMORY:-256mb} - --maxmemory-policy - allkeys-lru -
Prefer Docker secrets or another protected secret-management mechanism over placing credentials directly in Compose interpolation, command arguments, or health-check definitions.
-
Change the health check so it does not embed the password in inspectable Compose metadata. Use a protected credential file or an authenticated health-check wrapper with appropriately restricted access.
-
Fail securely in
run.shwhen no password is supplied instead of assigningredispass:bash : "${REDIS_PASSWORD:?REDIS_PASSWORD must be set to a strong, unique value}" -
Rotate the credential immediately for any existing deployment that may have used the default. Restart the service and update all clients atomically.
-
Restrict Redis to dedicated application networks rather than a broadly shared proxy network. Attach only containers that legitimately require Redis access.
-
Configure Redis ACLs with application-specific users and least-privilege command/key permissions instead of relying solely on one unrestricted password.
-
Keep the localhost-only host binding as defense in depth, but do not treat it as isolation from containers attached to the same Docker network.
-