FileRise versions prior to 3.16.0 with AUTH_BYPASS enabled are vulnerable to an authentication bypass vulnerability. This occurs because the application trusts the reverse-proxy identity header without verifying the request's origin from trusted proxies. An attacker can exploit this by directly accessing the backend port and supplying the X-Remote-User header to impersonate any user, including administrators, without authentication. The vulnerability is fixed in version 3.16.0.
FileRise versions prior to 3.15.0 contain a vulnerability where public shared-folder links with subfolder browsing enabled can follow symbolic links to access sibling directories outside the intended shared folder. This allows an unauthenticated user with a valid share token to list, download, or create ZIP archives of files outside the shared folder boundary. The issue arises because symlink resolution does not enforce the original shared folder as a boundary. The vulnerability is fixed in version 3.15.0.
FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 3.14.0, FileRise 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 invoke FileController::createFile and FileController::createShareLink without rejecting a missing or invalid X-CSRF-Token header. A request issued with a logged-in user's session can create an empty file or create a share link with that user's permissions, although the default SameSite=Lax session cookie reduces ordinary cross-site POST reachability. This issue is fixed in version 3.14.0.
FileRise versions prior to 3.12.0 contain a vulnerability where the /api/totp_setup.php endpoint can be accessed by sessions that have only passed the password check but are not fully authenticated. If the target account has TOTP configured, this endpoint returns the user's existing TOTP secret embedded in the QR code image. An attacker with the victim's password can extract this secret, generate valid one-time codes, and bypass the need for the victim's authenticator device to fully authenticate. This vulnerability is fixed in version 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 `read_own` 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 `read_own` enforcement for hover previews. Version 3.11.0 fixes the issue.
CVE-2026-33330 is a high-severity broken access control vulnerability in FileRise versions prior to 3.10.0, specifically in its ONLYOFFICE integration. Authenticated users with read-only access can exploit this flaw to obtain a signed save callbackUrl and forge save callbacks, allowing them to overwrite files with malicious content. This vulnerability impacts confidentiality and integrity but does not affect availability. Exploitation requires authentication but no user interaction beyond that. The issue has been patched in version 3.10.0. Organizations using vulnerable FileRise versions should upgrade immediately and review access controls to mitigate risk.
CVE-2026-33329 is a high-severity path traversal vulnerability in FileRise, a self-hosted web file manager and WebDAV server. Versions from 1.0.1 up to but not including 3.10.0 are affected. The issue arises because the resumableIdentifier parameter in the chunked upload handler is concatenated directly into filesystem paths without sanitization. An authenticated user with upload permissions can exploit this flaw to write files to arbitrary directories, delete directories during cleanup, and probe for file or directory existence. No user interaction beyond authentication is required, and the vulnerability allows significant integrity and availability impact. The vulnerability has been patched in version 3.
CVE-2026-33072 is a high-severity vulnerability in FileRise versions prior to 3.9.0 caused by the use of a hardcoded default encryption key. This key, 'default_please_change_this_key', is used for all cryptographic operations including HMAC token generation, AES configuration encryption, and session tokens. Because the key is hardcoded and widely known, unauthenticated attackers can forge upload tokens to upload arbitrary files to shared folders and decrypt sensitive admin configuration secrets such as OIDC client secrets and SMTP passwords. The vulnerability arises from the failure to override the default key via environment variables. This issue is fixed in version 3.9.0. The CVSS score is 8.
CVE-2026-33071 is a medium severity vulnerability in FileRise versions prior to 3.8.0, a self-hosted web file manager and WebDAV server. The vulnerability arises because the WebDAV upload endpoint does not validate file extensions, allowing attackers to upload files with dangerous server-side executable extensions such as . php, . phtml, and . htaccess. This bypasses the filename validation enforced on the regular upload path. In deployments without Apache's LocationMatch protection, this can lead to remote code execution. The flaw is due to the createFile() and put() methods accepting filenames directly from WebDAV clients without validation.
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. 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 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-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.