CVE-2026-33072
Received Received - Intake
Hardcoded Key in FileRise Enables Arbitrary File Upload, Data Decryption

Publication date: 2026-03-20

Last updated on: 2026-03-23

Assigner: GitHub, Inc.

Description
FileRise is a self-hosted web file manager / WebDAV server. In versions prior to 3.9.0, a hardcoded default encryption key (default_please_change_this_key) is used for all cryptographic operations β€” HMAC token generation, AES config encryption, and session tokens β€” allowing any unauthenticated attacker to forge upload tokens for arbitrary file upload to shared folders, and to decrypt admin configuration secrets including OIDC client secrets and SMTP passwords. FileRise uses a single key (PERSISTENT_TOKENS_KEY) for all crypto operations. The default value default_please_change_this_key is hardcoded in two places and used unless the deployer explicitly overrides the environment variable. This issue is fixed in version 3.9.0.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-20
Last Modified
2026-03-23
Generated
2026-05-07
AI Q&A
2026-03-20
EPSS Evaluated
2026-05-05
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
filerise filerise to 3.9.0 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-1188 The product initializes or sets a resource with a default that is intended to be changed by the product's installer, administrator, or maintainer, but the default is not secure.
CWE-798 The product contains hard-coded credentials, such as a password or cryptographic key.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-33072 is a critical vulnerability in FileRise versions prior to 3.9.0 caused by the use of a hardcoded default encryption key (`default_please_change_this_key`) for all cryptographic operations.

This default key is embedded in the Dockerfile and configuration files and is used unless explicitly overridden by the deployer. It is used for HMAC token generation, AES encryption of admin configuration files, and session tokens.

Because the key is publicly known and reused across multiple security functions, an unauthenticated attacker can forge upload tokens to upload arbitrary files to shared folders, decrypt sensitive admin configuration secrets such as OIDC client secrets and SMTP passwords, and potentially hijack sessions if combined with other vulnerabilities.

The vulnerability arises from the reuse of a hardcoded key without requiring users to change it, and the lack of a key derivation function in encryption.

This issue was fixed in FileRise version 3.9.0 by removing the baked-in default key, auto-generating unique keys per installation, adding key rotation features, and warning administrators if legacy keys are in use.


How can this vulnerability impact me? :

This vulnerability can have several serious impacts:

  • Unauthenticated attackers can forge upload tokens to upload arbitrary files to shared folders, potentially leading to unauthorized file uploads.
  • Attackers who gain read access to admin configuration files can decrypt sensitive secrets such as OIDC client secrets, SMTP passwords, and JWT secrets, leading to full disclosure of confidential information.
  • There is a theoretical risk of session hijacking if an attacker can exploit additional vulnerabilities to write to persistent token storage, allowing impersonation of users including administrators.

Overall, the vulnerability exposes deployments that do not change the default key to significant risks of unauthorized access, data disclosure, and potential compromise of the system.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

[{'type': 'paragraph', 'content': 'This vulnerability can be detected by checking if your FileRise deployment is using the default hardcoded encryption key `default_please_change_this_key` for cryptographic operations. Specifically, you should verify whether the environment variable `PERSISTENT_TOKENS_KEY` is set or if the default key is still in use.'}, {'type': 'paragraph', 'content': 'To detect this on your system, you can inspect the environment variables or configuration files for the presence of the default key. For example, you can run commands to check environment variables or search configuration files for the default key string.'}, {'type': 'list_item', 'content': 'Check environment variable in a running container or system: `echo $PERSISTENT_TOKENS_KEY`'}, {'type': 'list_item', 'content': "Search for the default key in configuration files: `grep -r 'default_please_change_this_key' /path/to/filerise/config`"}, {'type': 'list_item', 'content': 'Check Dockerfile or Docker environment variables for the default key: `docker inspect <container_id> | grep PERSISTENT_TOKENS_KEY`'}, {'type': 'paragraph', 'content': 'If the output shows the default key or the environment variable is unset or empty, your system is vulnerable.'}] [1]


What immediate steps should I take to mitigate this vulnerability?

To mitigate this vulnerability immediately, you should upgrade your FileRise installation to version 3.9.0 or later, where the issue is fixed by removing the baked-in default encryption key and introducing unique key generation.

If upgrading immediately is not possible, you should explicitly override the default encryption key by setting the environment variable `PERSISTENT_TOKENS_KEY` to a strong, unique value different from the default.

After upgrading to 3.9.0 or later, use the new admin-only key rotation feature to generate a new persistent-token key, re-encrypt stored secrets, and expire all existing sessions to prevent token forgery or session hijacking.

  • Upgrade FileRise to version 3.9.0 or newer.
  • Set a unique `PERSISTENT_TOKENS_KEY` environment variable if not upgrading immediately.
  • Use the admin panel to rotate keys and expire sessions after upgrade.

Additionally, review access controls to ensure that unauthorized users cannot read sensitive configuration files like `adminConfig.json` or write to `persistent_tokens.json`.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart