FileRise CVE-2026-57492

Exploitation requires that users.txt becomes empty or missing AFTER initial setup previously completed - caused by storage loss, truncation, or another failure - because versions prior to 3.16.0 lacked a durable setup-complete marker independent of the mutable user store and therefore re-entered first-run setup. The attacker must then detect the reopened setup window and submit the setup/initial-admin-creation flow over the network before a legitimate operator restores accounts. Limiting factors: the triggering empty-user-store state is not directly attacker-controlled (hence AC:H), so instances with durable, reliable storage and intact users.txt are not exploitable; no authentication (PR:N) and no user interaction (UI:N) are needed once the condition exists. The fix in 3.16.0 also back-fills the marker for existing installs that already have users, keeping setup closed even if users.txt is later emptied.

This is a CWE-306 (Missing Authentication for Critical Function) flaw with a CVSS of 7.4 driven by AV:N, PR:N, UI:N and high confidentiality/integrity impact - meaning a remote, unauthenticated attacker can seize full administrator control. The critical tempering signal is AC:H: exploitation is not attacker-initiated but depends on an independent failure (storage loss, truncation, or corruption) emptying users.txt, after which FileRise wrongly reopens first-run setup. No EPSS score, KEV listing, or POC was provided in the input, so there is no evidence of active or widespread exploitation (no public exploit identified at time of analysis). Weighing the signals: the impact is severe and the attack surface is unauthenticated, but the precondition is outside the attacker's direct control, making this a conditional/opportunistic issue rather than a mass-exploitable one. Net assessment: a genuine high-severity bug that FileRise operators should patch promptly, but not a 'drop everything' internet-wide crisis in the absence of exploitation telemetry. Note the AC:H rating hinges on the triggering condition being non-attacker-controlled - an attacker who can themselves induce the user-store wipe (e.g., via a separate vulnerability or filesystem abuse) would effectively lower that barrier; verify your deployment's storage durability.

A FileRise instance suffers a storage failure or truncation that empties users.txt. An unauthenticated remote attacker polling the application detects that first-run setup has silently reopened, reaches the setup flow, and registers themselves as the new initial administrator before any legitimate operator notices, gaining full control of the file manager and its stored files. No public exploit code was provided in the input.