Hardcoded Default Cryptographic Key in FileRise
CVE-2026-33072 affects FileRise, a self-hosted web file manager and WebDAV server. In versions prior to 3.9.0, FileRise uses a hardcoded default key, "default_please_change_this_key", as the value of PERSISTENT_TOKENS_KEY unless the deployer explicitly overrides the environment variable. The same key is reused across multiple cryptographic functions, including HMAC token generation, AES encryption of configuration data, and session token handling. Because this default key is predictable and shared, an unauthenticated attacker can generate valid upload tokens for shared folders and decrypt encrypted administrator configuration secrets. Exposed secrets include OIDC client secrets and SMTP passwords. The issue is fixed in FileRise 3.9.0.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation allows unauthenticated attackers to forge upload tokens and upload arbitrary files to shared folders, resulting in integrity compromise of stored content. The attacker can also decrypt sensitive administrator configuration data protected with the same key, including OIDC client secrets and SMTP passwords, causing high confidentiality impact. Based on the provided information, no direct availability impact is described.
If you can’t patch tonight, do this now.
If immediate upgrade is not possible, explicitly override PERSISTENT_TOKENS_KEY with a strong, unique secret in the environment so the hardcoded default value is not used. Review deployments to confirm the default key was never left in place. Treat encrypted configuration data and tokens generated while the default key was active as potentially compromised; rotate exposed secrets and invalidate or regenerate relevant tokens and sessions where feasible. Restrict exposure of shared-folder upload functionality until remediation is complete.
Patch, then assume compromise.
Upgrade FileRise to version 3.9.0 or later, which fixes the hardcoded default key issue. Ensure that any deployment-specific cryptographic key material is unique and not derived from the previous default value. Because the vulnerable key may have exposed encrypted configuration data and enabled token forgery, rotate potentially compromised secrets after upgrading, including OIDC client secrets, SMTP credentials, and any other values protected by the vulnerable configuration encryption scheme.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
9 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.