CVE-2026-61844 in FileRise
Summary
by MITRE • 10/14/2026
FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 3.18.0, FileRise flattens logical folder paths into metadata filenames by replacing separators and spaces with hyphens, so distinct folders such as team/docs and team-docs can share one metadata file. Because uploader metadata is used to authorize read_own and ownership-restricted edits, a low-privileged user who controls one colliding folder, knows the target basename, and already has read_own access to the target folder can alter the metadata used by that folder, make the victim file appear attacker-owned, read it, and modify it when edit-own permission is also available. This issue is fixed in version 3.18.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
FileRise operates as a self-hosted web-based file management solution designed to facilitate multi-file uploads, editing capabilities, and batch operations for organizational data storage. The application relies on metadata files associated with specific directories to manage access control policies, including permissions such as read_own and edit_own which dictate whether users can view or modify content within those folders based on ownership attributes. In versions prior to 3.18.0, the system employs a mechanism that normalizes logical folder paths into flat filenames for metadata storage by replacing path separators and spaces with hyphens. This normalization process introduces a critical collision vulnerability where distinct directory structures can map to identical filename identifiers due to ambiguous character substitution rules.
The core technical flaw lies in the lack of unique identifier generation or strict canonicalization during the creation of metadata files. Specifically, logical paths such as team/docs and team-docs are both transformed into the same hyphenated string representation for their respective metadata filenames. Because the application uses these flattened names to locate and apply access control rules, it fails to distinguish between two separate directories that happen to produce identical filename strings after normalization. This ambiguity allows an attacker who has write access or administrative privileges over one of the colliding folders to manipulate the shared metadata file intended for another folder with a different logical path but the same normalized name.
This vulnerability enables a low-privileged user to escalate their effective permissions through indirect object reference manipulation. By controlling one of the colliding directories, an attacker can modify the metadata file that is also used by a target directory they do not directly control. If the attacker knows the basename of the target folder and already possesses read_own access to it, they can alter the ownership attributes within the shared metadata file. This modification causes the system to incorrectly attribute ownership of files in the victim folder to the attacker. Consequently, when edit-own permissions are enabled for that directory type, the application grants the attacker write access to files they do not actually own, allowing them to read sensitive information and modify or delete data belonging to other users or departments.
From a security classification perspective, this issue aligns with CWE-284 Improper Access Control, as the vulnerability stems from insufficient checks on user authorization relative to specific resources. It also relates to CWE-697 Incorrect Comparison During Authorization Checks, where the system fails to correctly associate access control policies with their intended logical entities due to identifier collision. In terms of attack vectors, this behavior is consistent with ATT&CK technique T1083 File and Directory Discovery combined with T1222 File Permission Modification, as it involves discovering accessible resources and altering permissions or ownership attributes to gain unauthorized access.
The operational impact of this vulnerability includes the potential for complete data confidentiality breach and integrity compromise within affected directories. Sensitive documents can be exfiltrated by attackers who previously only had read-only rights, and critical business files can be altered or destroyed without detection since the system believes the attacker is acting as an authorized owner. This undermines the fundamental trust model of a file management system where access controls are expected to strictly enforce boundaries between different teams or project folders that may have similar naming conventions.
To mitigate this vulnerability, organizations must upgrade FileRise to version 3.18.0 or later, which resolves the path normalization logic by ensuring unique and unambiguous metadata filename generation for each distinct logical folder path. Until an upgrade is possible, administrators should enforce strict directory naming policies that avoid using hyphens in ways that could cause collisions with standard separators like slashes or underscores. Additionally, implementing additional validation layers at the application level to verify ownership against actual file system attributes rather than relying solely on metadata files can provide a temporary defense-in-depth measure. Regular audits of access control lists and monitoring for unusual modification patterns by users who do not own specific directories may also help in detecting exploitation attempts before significant damage occurs.