FileRise EUVD-2026-101682

Requires an authenticated, non-administrator FileRise account that owns at least one source folder and can obtain a valid CSRF token for that source folder; the attacker must also know or guess an unused destination path beneath a victim's existing folder or in the root namespace. Exploitation is LIMITED by several factors: valid authentication and a source-folder CSRF token are mandatory (not remote-unauthenticated), the destination path must be unused so pre-existing victim files cannot be overwritten, and impact is confined to relocating and rekeying ownership/ACL rather than reading victim contents (the only disclosure is a path-existence oracle from distinct pre-fix errors). The flaw is meaningful only in multi-tenant deployments with more than one distinct folder owner; single-owner installs are not realistically affected.

This is a medium-severity broken-access-control flaw (CVSS 5.4, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N) in authorization (CWE-284), not an authentication bypass: the attacker is already an authenticated, non-administrator user with a valid CSRF token. The exploitation status is 'no public exploit identified at time of analysis' - no CISA KEV listing and no POC were provided, and no EPSS score was supplied, so widespread or automated exploitation cannot be inferred. The signals are internally consistent rather than conflicting: PR:L correctly reflects that only an authenticated folder-owner can trigger the move, and the limited C:L/I:L/A:N impacts match a flaw that relocates a folder tree and rekeys ownership/ACL records without disclosing directory listings or file contents and without overwriting victim files. One nuance worth noting: the scope is scored S:U, yet the operation crosses a per-user ownership boundary and rewrites another user's namespace, so a case for S:C (scope change) is arguable and would raise the score - treat S:U as the vendor/NVD choice, not a settled fact. Net: this is a genuine but bounded multi-tenant integrity/isolation issue, a real priority chiefly for shared FileRise deployments with multiple distinct folder owners, and a low priority for single-user or trusted-tenant installs. It is not a high-CVSS-but-trivial issue, but neither is it a drop-everything RCE.

An authenticated, non-administrator FileRise user who owns a source folder sends a /api/folder/renameFolder.php request with a valid CSRF token, setting the destination parent to another user's existing folder or the root namespace. Because the destination parent is not independently authorized, the move succeeds and the ownership and ACL records are rekeyed to the attacker-chosen path, planting the attacker's tree inside the victim's namespace. No public exploit is identified, but attack complexity is low (AV:N/AC:L), and the attacker can additionally use differing pre-fix error responses to probe whether a specific destination path exists.