FileRise implementations before version 3.18.0 transform folder paths into a single metadata filename by removing separators and spaces. This logic allows two originally distinct folders, such as "team/docs" and "team-docs", to point to the same metadata file. When file metadata is used to enforce the "read_own" and "edit‑own" permissions, a user who can create a folder whose normalized name collides with the target file’s metadata and who already has read‑own access to that target folder may modify the metadata. The attacker can then make the victim file appear to belong to them, read it, and, if possessing edit‑own permission, alter its contents. The vulnerability is an access‑control weakness that permits credential‑less elevation of privileges on data the user is only supposed to read.

This issue affects the self‑hosted file manager FileRise developed by error311. Any installation of FileRise versions earlier than 3.18.0 is vulnerable. Versions 3.18.0 and later include the fix and are not impacted.

The CVSS score of 7.1 indicates a high severity vulnerability. EPSS data is not available, and the vulnerability is not listed in the CISA KEV catalog, which suggests current public exploitation is unknown. The likely attack vector is local or privileged during normal operation: a low‑privileged user must be able to create a folder whose name, when normalized, collides with the target file’s metadata. Because this requires interaction with the FileRise web interface and knowledge of the target basename, the exploit would typically proceed through manual or automated use of the web application rather than via an arbitrary remote code execution. Overall the risk is moderate to high for environments where many users can create or manage folders and where sensitive files are stored.