Self-hosted Dify users may still share a public secret key after upgrades

Many self-hosted Dify installations are running with a critical security vulnerability due to a persistent configuration error. Users who installed the AI application platform before version 1.15.0 and subsequently upgraded their software likely still possess a default secret key that is publicly available in the project’s history. This oversight allows anyone with knowledge of the key to forge authentication tokens and access sensitive data.

What happened

The issue stems from how Dify handles configuration files during installation and upgrades. When users first set up Dify, they typically copy an example environment file to create their active configuration. This copy operation happens only once. Subsequent upgrades replace the container images and the Docker Compose file, but the local environment file remains untouched. Consequently, the security settings in that file reflect the state of the software at the time of initial installation, not the current version.

Up to version 1.14.x, the example configuration file shipped with a hardcoded, fixed SECRET_KEY. This key was a long string starting with sk-9f73s3lj. Although the documentation suggested generating a unique key, most users did not take this step. Starting with version 1.15.0, the example file was changed to leave the SECRET_KEY field empty, instructing the system to auto-generate a persistent key in the storage directory. However, users who installed earlier versions retained the old, public key in their local configuration even after upgrading to newer, more secure versions of the software.

This secret key is vital for security. It is used for signing session cookies, generating JWT authentication tokens, creating file URL signatures via HMAC-SHA256, and encrypting third-party OAuth credentials. Because the old key value is visible in Dify’s public GitHub history, any attacker can read it. Possession of this key allows an adversary to sign tokens that the Dify instance will accept as valid, effectively bypassing authentication mechanisms.

Key details

• Vulnerable versions: Any Dify instance installed before version 1.15.0 that has been upgraded but not had its .env file manually updated.
• The indicator: The presence of a SECRET_KEY starting with sk-9f73s3lj in the docker/.env file.
• Impact: Attackers can sign valid JWTs, access user sessions, and potentially decrypt stored OAuth credentials.
• Remediation command: Users can check for the vulnerable key using grep -c '^SECRET_KEY=sk-9f73s3lj' dify/docker/.env.
• Side effects of fixing: Rotating the key will immediately log out all users, invalidate existing file URLs, and break OAuth plugin integrations, requiring re-authorization.
• Additional risks: The same static configuration issue affects exposed ports, CORS settings, and default database passwords.

Background

In containerized applications like Dify, environment variables are often managed through a .env file. This file holds secrets and configuration parameters that customize the application for a specific deployment. When developers release updates, they often provide new example files (.env.example) with improved defaults or new required fields. However, package managers and Docker Compose do not automatically merge these changes into the user’s active .env file to prevent overwriting custom settings. This places the burden on the administrator to manually review and update configuration files after major upgrades.

The SECRET_KEY acts as the root of trust for many cryptographic operations within the application. If this key is compromised, the integrity of the entire session management system is undermined. In self-hosted scenarios, where the operator is responsible for both infrastructure and application security, maintaining hygiene in these configuration files is as critical as patching the software binaries themselves.

Why it matters

For teams running their own software, this incident highlights a common blind spot in maintenance routines. Many administrators assume that pulling the latest Docker image or running a compose upgrade command ensures full security. In reality, configuration drift can leave significant vulnerabilities open even on the latest software versions. This is particularly dangerous for AI platforms like Dify, which may handle sensitive corporate data, proprietary prompts, or internal knowledge bases.

The impact extends beyond immediate unauthorized access. Because the key encrypts third-party OAuth credentials, a compromise could lead to lateral movement into other connected services. Furthermore, the need to rotate the key causes operational disruption. All users are logged out, and integrations must be re-established. For IT leads and DevOps engineers, this means that security remediation is not just a technical fix but a change management event that requires communication with stakeholders and careful timing to minimize downtime.

What you can do

• Check your configuration: Run grep -c '^SECRET_KEY=sk-9f73s3lj' dify/docker/.env in your terminal. A result of 1 means you are vulnerable.
• Generate a new key: If vulnerable, back up your .env file and use openssl rand -base64 42 to generate a new random key, then update the file.
• Restart services: Apply the change by running docker compose up -d to restart the containers with the new secret.
• Restrict port exposure: Bind nginx and debugging ports to 127.0.0.1 in your .env file to prevent external access, using variables like EXPOSE_NGINX_PORT=127.0.0.1:8080.
• Secure CORS settings: Explicitly set CONSOLE_CORS_ALLOW_ORIGINS to your specific console URL instead of leaving it as the default wildcard *.
• Update to the latest version: Ensure you are running at least Dify 1.17.1 to address other advisories that may not have CVE IDs.