FileRise CVE-2025-62509

Requires a valid low-privilege (non-admin) authenticated account on a multi-user FileRise instance running a version prior to 1.4.0 (PR:L). Exploitation succeeds against default configurations of these versions because the application inferred ownership/visibility from folder names and omitted server-side ownership checks on delete/rename/move/view file-operation endpoints; the attacker references victim resources by predictable names (e.g., a top-level folder named after another username). Limiting factors: the attacker must already have an account on the instance; single-user or admin-only deployments are not meaningfully exposed; and upgrading to 1.4.0+ (or applying the workaround of read-only non-admin users / disabled delete-rename APIs / per-user bypassOwnership controls) removes the condition.

This is a genuine access-control vulnerability (CWE-280) rated CVSS 8.1 with vector AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, meaning network-reachable, low-complexity exploitation by an already-authenticated low-privilege user with high confidentiality and integrity impact but no availability impact. The signals are moderately but not maximally alarming: the CVSS vector requires PR:L (an attacker must hold a valid low-privilege account), which meaningfully narrows the exploit population versus a fully unauthenticated flaw. No EPSS score was supplied in the input, so exploitation probability cannot be quantified. The CVE is NOT listed in CISA KEV and no public proof-of-concept is referenced, so this is 'no public exploit identified at time of analysis.' Exploitability is nonetheless straightforward in principle because the root cause - inferring ownership from predictable folder names and missing server-side authorization - means an attacker only needs to reference resources by guessable names (classic IDOR), with no memory-corruption or race conditions involved. Overall this is a real, actionable priority for anyone running multi-user FileRise instances below 1.4.0, but its real-world blast radius is tempered by the low deployment footprint of the product and the requirement for a pre-existing account rather than being a wormable, unauthenticated internet-wide threat.

A multi-user FileRise instance (prior to 1.4.0) hosts separate folders per user. A low-privilege authenticated user crafts API requests referencing another user's predictably-named folder/files (e.g., a folder named after the victim's username) and, because the server never verifies ownership, reads, modifies, or deletes those files. No public exploit code is referenced, but the attack requires only normal API calls with guessed resource names and no special tooling.