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, as the WebDAV layer incorrectly inherits elevated privileges from an ambient web session rather than enforcing independent stateless authentication per RFC 4918.

FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 3.12.0, /api/totpsetup.php is callable from a session that has only passed the password check (state pendingloginuser). When the target account already has TOTP configured, the endpoint decrypts and returns the user's existing TOTP secret inside the QR PNG instead of refusing or generating a new secret. An attacker who already possesses the victim's password can therefore retrieve the live TOTP secret, derive a valid one-time code, submit it to /api/totpverify.php, and obtain a fully authenticated session without ever possessing the victim's authenticator device. This vulnerability is fixed in 3.12.0.

FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. In versiosn 2.3.7 through 3.10.0, the file snippet endpoint /api/file/snippet.php allows an authenticated user with only readown access to a folder to retrieve snippet content from files uploaded by other users in the same folder. This is a server-side authorization flaw in the readown enforcement for hover previews. Version 3.11.0 fixes the issue.

FileRise is a self-hosted web file manager / WebDAV server. From version 1.0.1 to before version 3.10.0, the resumableIdentifier parameter in the Resumable.js chunked upload handler (UploadModel::handleUpload()) is concatenated directly into filesystem paths without any sanitization. An authenticated user with upload permission can exploit this to write files to arbitrary directories on the server, delete arbitrary directories via the post-assembly cleanup, and probe file/directory existence. This issue has been patched in version 3.10.0.

FileRise is a self-hosted web file manager / WebDAV server. Prior to version 3.10.0, a broken access control issue in FileRise's ONLYOFFICE integration allows an authenticated user with read-only access to obtain a signed save callbackUrl for a file and then directly forge the ONLYOFFICE save callback to overwrite that file with attacker-controlled content. This issue has been patched in version 3.10.0.

FileRise is a self-hosted web file manager / WebDAV server. In versions prior to 3.8.0, a missing-authentication vulnerability in the deleteShareLink endpoint allows any unauthenticated user to delete arbitrary file share links by providing only the share token, causing denial of service to shared file access. The POST /api/file/deleteShareLink.php endpoint calls FileController::deleteShareLink() which performs no authentication, authorization, or CSRF validation before deleting a share link. Any anonymous HTTP client can destroy share links. This issue is fixed in version 3.8.0.

FileRise is a self-hosted web file manager / WebDAV server. In versions prior to 3.9.0, a hardcoded default encryption key (defaultpleasechangethiskey) is used for all cryptographic operations — HMAC token generation, AES config encryption, and session tokens — allowing any unauthenticated attacker to forge upload tokens for arbitrary file upload to shared folders, and to decrypt admin configuration secrets including OIDC client secrets and SMTP passwords. FileRise uses a single key (PERSISTENTTOKENSKEY) for all crypto operations. The default value defaultpleasechangethiskey is hardcoded in two places and used unless the deployer explicitly overrides the environment variable. This issue is fixed in version 3.9.0.

FileRise is a self-hosted web file manager / WebDAV server. In versions prior to 3.8.0, the WebDAV upload endpoint accepts any file extension including .phtml, .php5, .htaccess, and other server-side executable types, bypassing the filename validation enforced by the regular upload path. In non-default deployments lacking Apache's LocationMatch protection, this leads to remote code execution. When files are uploaded via WebDAV, the createFile() method in FileRiseDirectory.php and the put() method in FileRiseFile.php accept the filename directly from the WebDAV client without any validation. In contrast, the regular upload endpoint in UploadModel::upload() validates filenames against REGEXFILENAME. This issue is fixed in version 3.8.0.

FileRise is a self-hosted web file manager / WebDAV server. Prior to 3.3.0, an HTML Injection vulnerability allows an authenticated user to modify the DOM and add e.g. form elements that call certain endpoints or link elements that redirect the user on active interaction. This vulnerability is fixed in 3.3.0.

FileRise is a self-hosted web file manager / WebDAV server. Versions prior to 3.3.0, the application contains an unauthenticated file read vulnerability due to the lack of access control on the /uploads directory. Files uploaded to this directory can be accessed directly by any user who knows or can guess the file path, without requiring authentication. As a result, sensitive data could be exposed, and privacy may be breached. This vulnerability is fixed in 3.3.0.

FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 2.2.3, a stored cross-site scripting (XSS) vulnerability exists in the Filerise application due to improper handling of uploaded SVG files. The application accepts user-supplied SVG uploads without sanitizing or restricting embedded script content. When a malicious SVG containing inline JavaScript or event-based payloads is uploaded, it is later rendered directly in the browser whenever viewed within the application. Because SVGs are XML-based and allow scripting, they execute in the origin context of the application, enabling full stored XSS. This vulnerability is fixed in 2.2.3.

FileRise is a self-hosted web file manager / WebDAV server. Versions prior to 2.7.1 are vulnerable to Stored Cross-Site Scripting (XSS) due to unsafe handling of browser-renderable user uploads when served through the sharing and download endpoints. An attacker who can get a crafted SVG (primary) or HTML (secondary) file stored in a FileRise instance can cause JavaScript execution when a victim opens a generated share link (and in some cases via the direct download endpoint). This impacts share links (/api/file/share.php) and direct file access / download path (/api/file/download.php), depending on browser/content-type behavior. Version 2.7.1 fixes the issue.

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.

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/readown) and strict server-side checks across list, read, write, share, rename, copy/move, zip, and WebDAV paths.