FileRise vulnerabilities

FileRise before version 3.28.0 contains a privilege escalation vulnerability that allows authenticated low-privilege attackers to gain unauthorized read and write access by exploiting improper session isolation between the WebDAV interface and the web application session context. Attackers can combine valid Basic-Auth credentials with an active admin PHPSESSID cookie to bypass authorization boundaries.

FileRise before 3.16.0 is vulnerable to path traversal in the shared-folder upload endpoint (/api/folder/uploadToSharedFolder.php), leading to arbitrary file write and administrator account takeover. The upload filename validation permits URL-encoded sequences.

FileRise is a self-hosted web-based file manager. From 3.9.0 until 3.22.0, pristine manual FileRise installations without PERSISTENT_TOKENS_KEY or metadata/persistent_tokens.key can activate a published legacy compatibility key. If an attacker separately obtains ciphertext-bearing account or configuration files, the known fallback key can enable decryption of TOTP secrets or credentials. This issue is fixed in version 3.22.0.

FileRise is a self-hosted web-based file manager. Prior to 3.21.0, FileRise returns the stored branding.footerHtml value through the unauthenticated public site configuration API without server-side sanitization. The FileRise frontend already sanitizes this value before rendering it into the page, but the unauthenticated public config API exposed raw admin-provided footer HTML to clients. An administrator must first store the malicious footer value. This issue is fixed in version 3.21.0.

FileRise is a self-hosted web-based file manager. Prior to 3.21.0, FileRise tracks failed logins only by the combination of source IP address and username. A remote unauthenticated attacker can rotate usernames to obtain a fresh per-account attempt budget for each name, enabling password spraying from one source beyond the intended limit. This issue is fixed in version 3.21.0.

FileRise is a self-hosted web-based file manager. Prior to 3.21.0, FileRise enforces disableFormLogin, disableBasicAuth, and disableOIDCLogin in the client interface but not consistently in the corresponding server-side authentication flows. A user with otherwise valid credentials for a disabled method can call its backend endpoint directly and authenticate despite the administrator's login-method policy. This issue is fixed in version 3.21.0.

Prior to 3.20.0, FileRise /api/file/snippet.php does not apply the standard authenticated-session guard before processing short text preview requests. The endpoint still performs FileRise ACL checks, so normal installations do not expose an unauthenticated arbitrary file read, but unauthenticated requests can reach ACL evaluation instead of receiving an immediate 401 response. Only additional unusual proxy-header or ACL misconfiguration is documented as allowing requests to proceed into path and file-content handling.

FileRise prior to 3.19.0 does not reject dot-dot path segments in the folderName string before FolderModel::createFolder() constructs and creates the destination. An authenticated low-privileged user with a valid CSRF token and create or owner permission on the parent can submit traversal segments to POST /api/folder/createFolder.php and create directories outside UPLOAD_DIR.

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. A low-privileged user who controls one colliding folder and knows the target basename can alter the metadata, make the victim file appear attacker-owned, then read and modify it.

Prior to 3.18.0, FileRise upload-enabled shared-folder and upload-only links do not reject a destination filename that already exists. An unauthenticated visitor with a valid share token and password can upload a file with the same name and silently replace its content while the original uploader metadata remains. The same gap affects ordinary authenticated uploads via /api/upload/upload.php and authenticated upload-only users lacking edit authority.

FileRise prior to 3.16.0 stores the isAdmin flag in remember-me tokens and restores that stale value during automatic login instead of resolving the account's current role from users.txt. A user who was issued a token while an administrator can retain administrator access after demotion, and token rotation copies the stale privilege into each replacement token.

Prior to 3.16.0, FileRise treats an empty or missing users.txt file as a fresh installation even after setup previously completed. If storage loss, truncation, or another failure empties the user store, an unauthenticated remote caller can detect that setup mode reopened and create the next initial administrator account. The application lacked a durable setup-complete marker independent of the mutable user store.

FileRise prior to 3.16.0 does not apply UploadNamePolicy::isAllowedForWrite() before ZipArchive::extractTo() writes entries into the destination directory. An authenticated user with upload and extract permissions can place a blocked extension such as a PHP-family file inside a ZIP and cause it to be written to disk even when normal uploads reject that filename.

Prior to 3.16.0, when an administrator has enabled WebDAV, FileRise WebDAV Basic authentication validates only the account username and password through AuthModel::authenticate() and does not enforce the account's configured TOTP factor. An attacker who knows valid primary credentials for a TOTP-enabled account can authenticate to the enabled WebDAV service without supplying the second factor and exercise the account's WebDAV file permissions. The browser login path enforces TOTP, but the separate public/webdav.php authentication callback did not.

Prior to 3.16.0, FileRise deployments with AUTH_BYPASS enabled trust the configured reverse-proxy identity header without verifying that the request originated from FR_TRUSTED_PROXIES. When the backend application port is reachable directly, an unauthenticated attacker can supply X-Remote-User and obtain a session for the asserted account, including an administrator account, without a password or MFA. The flaw is limited to deployments that enable proxy-header authentication and expose an untrusted path to the backend.

FileRise before 3.23.0 validates archive entry names but extracts them directly into the destination before validating resolved paths. If the destination already contains a symlink to a directory outside the storage root, an authenticated non-administrator with extract permission can place an archive entry beneath the link and overwrite or delete an external file.

Prior to 3.23.0, FileRise maps an authenticated OIDC identity to a local account using mutable preferred_username or email claims and does not require email_verified for email-based naming. An attacker able to obtain provider-issued claims colliding with an existing local username can be logged in as that account, including the built-in administrator, even when automatic provisioning is disabled.

In FileRise 3.22.0, the /api/file/saveFile.php operation accepts dot and dot-dot segments in its attacker-controlled folder input before ACL inheritance evaluates the uncanonicalized string. An authenticated non-administrator with a valid CSRF token and inherited edit permission can create files outside the authorized folder and, where backend credentials permit, outside the configured WebDAV root.

FileRise before 3.23.0 permits an authenticated session with a valid CSRF token to disable TOTP without recent full reauthentication or to begin enrollment when the account has no TOTP secret. The newly generated secret is persisted and activated before a TOTP code verifies possession, allowing an attacker controlling an existing session to disable or enroll a second factor.

FileRise before 3.23.0 verifies that a TOTP code is valid for the accepted time window but does not record that the same account and time step already succeeded. An attacker with the target account's valid primary credential who captures a TOTP code after its successful use can replay that code from another pending-login session before the window closes.

FileRise before 3.23.0 in /api/folder/renameFolder.php authorizes an authenticated, non-folder-scoped, non-administrator with a valid CSRF token against the source folder but does not independently authorize a changed destination parent. A user who owns a source folder can move that tree beneath another user's folder or into the root namespace, and the operation rekeys ownership and ACL records to the new path.

Prior to 3.23.0, FileRise stores failed TOTP verification attempts in $_SESSION. An attacker who already possesses a target account's valid primary credential can restart the login workflow in a new session and restore the second-factor attempt allowance, permitting continued online TOTP guessing beyond the intended five-attempt limit.

In FileRise prior to 3.15.0, public shared-folder links with subfolder browsing enabled can follow a symbolic link inside the shared folder to a sibling directory under the upload root. An unauthenticated holder of a valid share token can use shared-folder listing, direct download, or ZIP creation to access files outside the folder that was actually shared.

FileRise prior to 3.14.0 authenticates requests to the file creation and share-link creation handlers but does not enforce the server-side CSRF token check used by adjacent state-changing operations. The POST endpoints /api/file/createFile.php and /api/file/createShareLink.php do not reject a missing or invalid X-CSRF-Token header. A request with a logged-in user's session can create an empty file or a share link with that user's permissions, although the default SameSite=Lax session cookie reduces ordinary cross-site POST reachability.

FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 2.2.3, a stored XSS vulnerability exists due to improper handling of uploaded SVG files; the application accepts SVG uploads without sanitizing or restricting embedded script content, allowing execution of malicious scripts in the application context.

FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. In version 1.4.0, a regression allowed folder visibility/ownership to be inferred from folder names. Low-privilege users could see or interact with folders matching their username and, in some cases, other users’ content. This issue has been patched in version 1.5.0, where it introduces explicit per-folder ACLs (owners/read/write/share/read_own) and strict server-side checks across list, read, write, share, rename, copy/move, zip, and WebDAV paths.

FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to version 1.4.0, a business logic flaw in FileRise’s file/folder handling allows low-privilege users to perform unauthorized operations (view/delete/modify) on files created by other users. The root cause was inferring ownership/visibility from folder names (e.g., a folder named after a username) and missing server-side authorization/ownership checks across file operation endpoints. This amounted to an IDOR pattern: an attacker could operate on resources identified only by predictable names. This issue has been patched in version 1.4.0 and further hardened in version 1.5.0. A workaround for this issue involves restricting non-admin users to read-only or disable delete/rename APIs server-side, avoid creating top-level folders named after other usernames, and adding server-side checks that verify ownership before delete/rename/move.