FileRise CVE-2026-77427

Exploitation requires a narrow combination: (1) a MANUAL (non-Docker) FileRise install on versions 3.9.0 to before 3.22.0; (2) no PERSISTENT_TOKENS_KEY environment variable set AND no metadata/persistent_tokens.key file present, so the instance runs on the published legacy compatibility key; and (3) the attacker must SEPARATELY obtain the ciphertext-bearing files (e.g. persistent_tokens.json, adminConfig.json, or the users file) that hold encrypted TOTP secrets and credentials, via filesystem access, exposed backups, a misconfigured directory, or a separate vulnerability. Limiting factors: Docker installations already generate a unique persistent key and are NOT affected; the hardcoded key yields nothing without the encrypted state files; and existing installs are deliberately not auto-rotated (remaining on the legacy path until an admin performs controlled rotation), so the issue is impactful only when state confidentiality is already compromised.

The base CVSS of 5.9 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N) is medium, and the real-world risk is lower than a raw 'network, unauthenticated' reading suggests because exploitation is heavily gated. The vector correctly encodes this: AC:H reflects that the published legacy key is useless on its own - the attacker must SEPARATELY obtain ciphertext-bearing files (account/config state), and impact is confidentiality-only (C:H, I:N, A:N). No EPSS score, KEV listing, POC, or SSVC decision data was provided in the input, so exploitation probability cannot be quantified from signals - on available evidence this is 'no public exploit identified at time of analysis,' not active exploitation. This is best treated as a defense-in-depth / cryptographic-hygiene issue (a hardcoded fallback key, CWE-798) rather than a standalone remotely-triggerable exploit: it meaningfully amplifies the damage of a SEPARATE file-exposure incident but does not by itself grant access. Priority is moderate for affected manual installs and low where state files are not otherwise exposed.

An attacker who has separately obtained a backup, a misconfigured/world-readable metadata directory, or exfiltrated state files from a pristine manual FileRise install (3.9.0-3.21.x) notices it was never given a PERSISTENT_TOKENS_KEY. Because such installs fall back to the published legacy compatibility key, the attacker uses that known key to decrypt the stored TOTP secrets and credentials offline, then reuses them to take over accounts. No public exploit code is identified in the provided data, and the attack hinges on first acquiring the ciphertext files (hence CVSS AC:H).