FileRise EUVD-2026-101669

Exploitation requires ALL of: (1) an authenticated low-privileged account on a multi-user FileRise instance prior to 3.18.0; (2) attacker control over a folder whose logical path flattens - via replacement of '/', '\\', and spaces with hyphens - to the same '<name>_metadata.json' file as the victim's folder (e.g. 'team/docs' vs 'team-docs'); (3) prior read_own access to the target folder; and (4) knowledge of the exact target file basename. Reading the victim file needs only this ownership-spoof; MODIFYING it additionally requires the attacker to hold edit-own permission. Limiting factors: this is not remote-unauthenticated (PR:L) and carries high complexity (AC:H) because it depends on a crafted naming collision plus specific pre-existing access and target knowledge; single-tenant/single-user deployments are effectively unaffected since no second user exists to victimize.

This is a moderate-severity, authorization-bypass issue (CWE-706, incorrectly resolved name/reference) rated CVSS 7.1 with vector AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L. The signals are internally consistent and point to a real-but-constrained risk rather than a drop-everything emergency. The network attack vector (AV:N) is offset by high attack complexity (AC:H) and a required low privilege level (PR:L): the attacker must already be an authenticated low-privileged user, must control one folder whose name collides with the victim's under FileRise's flattening scheme (e.g. 'team-docs' vs 'team/docs'), must know the target file's basename, and must already hold read_own access to the target folder. No EPSS score, KEV listing, SSVC decision, or POC was supplied in the intelligence. With KEV=NO and POC=NO, exploitation status is: no public exploit identified at time of analysis. The absence of EPSS data means automated exploitation probability cannot be weighed. Because the flaw requires attacker-controlled folder naming plus prior access and specific knowledge, it reads as a targeted insider/multi-tenant privilege issue, not a mass-exploitable remote bug. Priority is driven mainly by confirmed C:H/I:H impact on shared-tenancy deployments; single-user self-hosted instances face negligible real-world risk.

On a multi-user FileRise instance (pre-3.18.0), a low-privileged user who already has read_own access to a victim's folder creates or controls a second folder whose name flattens to the same metadata filename (e.g. 'team-docs' colliding with 'team/docs'). By writing metadata through their colliding folder, they make a known victim file appear attacker-owned, letting them read it and-if edit-own permission is also granted-modify it. No public exploit code was identified at time of analysis.