Target: langgenius/dify · Type: CWE-1188 Insecure Default Initialization · Severity: Critical · Published on huntr.com.

This is not an accidental secret leak in one repo — it is an insecure default in the official `docker-compose.yaml` used by thousands of self-hosted installs. Because the values are static across every default deployment, one attacker technique works everywhere.

The chain

The default deployment ships two problems that combine into full compromise:

• A hardcoded `SECRET_KEY` used to sign session tokens (docker/docker-compose.yaml).
• A default Postgres password (difyai123456) that often stays unchanged.

An unauthenticated attacker who can reach the database reads the administrator's account_id, then uses the known signing key to forge a valid admin session cookie.

Proof of concept

1. Connect to the exposed Postgres instance with the default credentials and read the admin id:

psql -h TARGET -U postgres -d dify
SELECT id, email FROM accounts;
-- e.g. 033ef83b-6643-449c-b957-a12eadc3aa8c

1. Sign that id with the leaked static key using HMAC-SHA256:

import hmac, hashlib
key = b'<hardcoded SECRET_KEY from docker-compose.yaml>'
msg = b'033ef83b-6643-449c-b957-a12eadc3aa8c'
print(hmac.new(key, msg, hashlib.sha256).hexdigest())

1. The resulting signature forges a valid administrator session — login is bypassed entirely.

Why this is in-scope (not "just a secret in a repo")

The software never forces secret rotation or unique key generation at setup, so every default install is vulnerable by design. The correct fix is to generate a unique SECRET_KEY on first boot (and refuse to start with the documented default), and to require a non-default database password.