Filerise
Monthly
Authentication bypass in FileRise versions before 3.23.0 lets a remote attacker log in as an existing local account - including the built-in administrator - by presenting OIDC claims whose mutable preferred_username value, or an unverified email, collides with that account's local username; the flaw works even when OIDC automatic provisioning is disabled. Successful takeover yields full read, write, and delete control over the file manager and its stored files, consistent with the assessed CVSS 3.1 score of 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). Exploitation is conditional, not universal: the deployment must be configured for OIDC SSO and the identity provider must allow the colliding claim or omit email_verified, which is what drives the High attack-complexity rating; no public exploit code was identified at time of analysis and the issue is not listed in CISA KEV. The vulnerability is fixed in FileRise 3.23.0.
Online second-factor guessing against FileRise releases prior to 3.23.0 is permitted well beyond the intended limit because failed TOTP verification attempts are recorded only in the PHP session rather than in a durable account-wide budget. An attacker who already possesses a valid primary credential (username plus password) for an account with TOTP enabled can abandon the pending login, start a fresh session, or change source address to restore the five-attempt allowance and continue guessing time-based codes indefinitely. Exploitation therefore has a hard precondition - the primary credential - and each guess remains a probabilistic online attempt against a rotating code, but a successful guess yields full account compromise; the vendor addressed the flaw in v3.23.0 and no public exploit code has been identified at time of analysis.
Authorization bypass in FileRise prior to 3.18.0 allows an authenticated, low-privileged user to read - and, when they also hold edit-own permission, modify - files they do not own by exploiting a collision in folder metadata filenames. FileRise flattens logical folder paths into metadata filenames by replacing '/', '\\' and spaces with hyphens, so distinct folders such as team/docs and team-docs resolve to the same <name>_metadata.json file; an attacker who controls one colliding folder and knows the target basename can overwrite the uploader-ownership metadata that read_own and ownership-restricted edit checks rely on, making a victim file appear attacker-owned. The issue is rated CVSS 7.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L) and is fixed in 3.18.0; exploitation requires a multi-user deployment, a crafted colliding folder name, pre-existing read_own access to the target folder and knowledge of the exact victim basename, and no public exploit identified at time of analysis. Single-tenant or single-user installations are effectively unaffected because no second user exists to victimize.
File overwrite in FileRise prior to 3.18.0 allows an unauthenticated visitor who holds a valid upload-enabled shared-folder or upload-only link token - plus any configured share password - to re-upload a file using the exact name of an existing file and silently replace its contents while the original uploader metadata is preserved. The same missing replacement check affects ordinary authenticated uploads through /api/upload/upload.php and authenticated upload-only users who lack edit authority over the target file, so the outcome is a high-integrity, no-confidentiality loss (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L, 8.2). Exploitation requires that an administrator has actually created and shared an upload-capable link and that the attacker knows or guesses the target filename; impact is confined to overwriting existing files, with no data disclosure and no code execution path. No public exploit code was identified at time of analysis, and the vendor-released fix is FileRise 3.18.0.
Unauthenticated administrative account takeover in FileRise versions prior to 3.16.0: because the application treats an empty or missing users.txt as a fresh installation, a remote caller with no credentials can detect that first-run setup has silently reopened and create the next initial administrator account through the setup flow. The empty-user-store condition must first arise from storage loss, truncation, or another failure after setup previously completed (hence the AC:H rating), so reliably-stored, intact installations are not exposed; once that state exists, exploitation requires no authentication and no user interaction (PR:N/UI:N) and yields high confidentiality and integrity impact (CVSS 7.4). There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, though the flaw is trivially reproducible by anyone who notices the exposed setup page.
Multi-factor authentication bypass in FileRise WebDAV prior to 3.16.0 allows an attacker who already holds a valid username and password for a TOTP-enabled account to authenticate to the WebDAV endpoint without supplying the second factor, then operate within that account's WebDAV file permissions. The weakness is conditionally gated: the opt-in WebDAV service must have been enabled by an administrator, the targeted account must have TOTP configured, and the attacker must already know the account's primary credentials, which the CVSS vector reflects as authenticated access (PR:L); the normal browser login path was never affected. Rated CVSS 3.1 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) with high confidentiality and integrity impact and no availability impact; no public exploit code or active exploitation was identified at time of analysis. The issue is fixed in FileRise 3.16.0.
Authentication bypass in FileRise (CWE-290) lets unauthenticated remote attackers impersonate any account - including an administrator - without a password or MFA in deployments prior to 3.16.0 that enable proxy-header authentication (AUTH_BYPASS) and expose the backend port directly. The flaw is that the configured reverse-proxy identity header (X-Remote-User) was trusted without validating that the request actually came from an address in FR_TRUSTED_PROXIES; an attacker who can reach the backend application port therefore simply supplies the header and receives a session for the named account. Exploitation requires proxy-header auth to be enabled, the trusted-proxy check to be absent or ineffective (exactly what 3.16.0 fixes), and a network path to the backend that bypasses the proxy, which is why it is scored AV:N/AC:H/PR:N/UI:N with full confidentiality, integrity, and availability impact (CVSS 3.1: 8.1 High); no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis.
Authenticated low-privilege users of FileRise before version 3.28.0 can obtain unauthorized read and write access at administrator level through the WebDAV interface by supplying valid Basic-Auth credentials alongside an active administrator PHPSESSID cookie, because the WebDAV layer inherits the elevated privileges of the ambient web session rather than authenticating each request independently as RFC 4918 requires. Exploitation is not trivial and depends on a co-occurring privileged session: the attacker must already hold valid low-privilege credentials (PR:L) and obtain the session cookie of a live administrator session, which is the basis for the high attack complexity (AC:H) in the CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N, base 7.6) and the assessed CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N); availability is unaffected. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at the time of analysis, and the vendor has released FileRise 3.28.0, whose changelog describes refined, more consistent WebDAV request handling.
Unauthenticated administrator account takeover in FileRise before 3.16.0 is possible via a path traversal flaw in the shared-folder upload endpoint (/api/folder/uploadToSharedFolder.php), where URL-encoded path separators bypass filename validation and allow arbitrary file write outside the upload directory. Any actor holding a valid, non-expired, upload-enabled shared-folder token - tokens explicitly designed to be shared publicly - can overwrite users/users.txt to plant an admin account and, depending on configuration, achieve remote code execution. No public exploit identified at time of analysis, but the upstream fix in v3.16.0 documents the exact bypass, lowering the bar for weaponization.
A broken access control vulnerability in FileRise's ONLYOFFICE integration allows authenticated users with read-only permissions to overwrite files with malicious content by forging ONLYOFFICE save callbacks using legitimately obtained signed callbackUrls. FileRise versions prior to 3.10.0 are affected. There is no evidence of active exploitation (not in CISA KEV), but proof-of-concept details are available through the GitHub Security Advisory GHSA-6c3j-f4x4-36m3.
FileRise, a self-hosted web file manager and WebDAV server, contains a path traversal vulnerability in its Resumable.js chunked upload handler where the resumableIdentifier parameter is concatenated into filesystem paths without sanitization. Authenticated users with upload permissions can exploit this to write files to arbitrary directories, delete arbitrary directories, and probe filesystem structure. No evidence of active exploitation (not in CISA KEV) or public POC availability has been reported at this time.
FileRise, a self-hosted web file manager and WebDAV server, contains a critical hardcoded encryption key vulnerability in versions prior to 3.9.0. The default key 'default_please_change_this_key' is used for all cryptographic operations including HMAC token generation, AES configuration encryption, and session tokens, allowing unauthenticated attackers to forge upload tokens for arbitrary file upload and decrypt sensitive admin configuration data such as OIDC client secrets and SMTP passwords. No evidence of active exploitation (not in CISA KEV) is currently available, though the vulnerability is straightforward to exploit given the hardcoded nature of the default key.
Unauthenticated directory traversal in FileRise prior to version 3.3.0 allows remote attackers to read arbitrary files from the /uploads directory without authentication by directly accessing guessable file paths. Public exploit code exists for this vulnerability, enabling attackers to expose sensitive data and breach user privacy. No patch is currently available.
Authenticated archive extraction in FileRise prior to 3.23.0 can overwrite and then delete files outside the configured storage root, but only when the destination folder already contains a symlink pointing to a directory outside that root. Exploitation requires a low-privileged but authenticated (PR:L) account holding 'extract' permission that can also place an attacker-controlled ZIP, 7z, or RAR in the affected folder, plus a pre-existing symlink the advisory does not establish the attacker can create; the FileRise OS process must also already hold write or delete permission on the external target, which is why attack complexity is rated high (AC:H) despite the network vector. The resulting CVSS 3.1 base score is 6.8 (Medium) with high integrity and availability impact and no confidentiality impact, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Path traversal in FileRise 3.22.0 allows an authenticated non-administrator whose session holds inherited edit permission on a legitimate ancestor folder to supply dot and dot-dot segments through the /api/file/saveFile.php folder input, causing attacker-controlled files to be written outside the authorized folder and, where backend credentials permit, outside the configured WebDAV root. Exploitation requires a valid CSRF token plus an authenticated session with inherited edit rights (CVSS 3.1: 6.5, AV:N/AC:L/PR:L/UI:N, I:H only), and no public exploit identified at time of analysis; this is a moderate, authentication-gated integrity risk rather than a top-tier emergency. Vendor-released patch: 3.23.0.
Unauthenticated information disclosure in the FileRise Pro portal-detail endpoint (/api/pro/portals/get.php) lets any remote caller who knows or guesses a client portal's slug retrieve that portal's full internal record, including internal storage folder paths, client contact email addresses, form settings, and upload-policy details, instead of the curated branding fields that the public publicMeta.php endpoint intentionally exposes. The flaw affects only installations running the FileRise Pro add-on with at least one configured client portal; base-edition FileRise deployments are unaffected, and file contents or credentials are not exposed. The issue carries a self-consistent CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N (5.3, CWE-200), and no public exploit code or active exploitation has been identified at time of analysis; it is resolved in FileRise 3.24.0.
Successful TOTP second-factor codes in FileRise prior to 3.23.0 can be replayed from a separate pending-login session, allowing an attacker who already holds the target account's valid username and password to complete authentication and reach that account with high confidentiality and integrity impact. The flaw exists because the application (CWE-287, Improper Authentication) validates a submitted code against the accepted time window but never records that the same account and time step was already consumed, so a captured still-valid code keeps working until the window expires. Exploitation is a narrow, targeted race - it requires possession of the primary credential plus capture of a live code during a genuine victim login (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N, base 6.4) - and no public exploit code is identified at time of analysis; a vendor patch in version 3.23.0 is available.
FileRise versions prior to 3.23.0 allow an authenticated user who already holds a valid session and that session's CSRF token to change second-factor settings at the TOTP management endpoints without any recent full reauthentication, so the attacker can either disable an already-configured TOTP factor or activate a newly enrolled TOTP secret on an account that currently has none. The rated impact is integrity-only (CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N; CWE-306) because the enrollment endpoint returns HTTP 409 rather than overwriting an active authenticator, meaning a protected account can be weakened but not silently re-enrolled. The practical precondition is substantial - the attacker must already control an authenticated session plus its CSRF token - and no public exploit identified at time of analysis; the fix is shipped in 3.23.0.
Improper authorization in the FileRise folder-rename API (all versions prior to 3.23.0) lets an authenticated, non-administrator user who owns a source folder move that entire folder tree beneath another user's existing folder or into the admin-controlled root namespace, with the relocated tree's ownership and ACL records rekeyed to the new path. Exploitation requires valid authentication plus a CSRF token scoped to the source folder, and the chosen destination must be unused, so existing victim files cannot be overwritten and their contents are never exposed; the only disclosure is a path-existence oracle from distinct pre-fix error messages. It is rated CVSS 5.4 (medium) and is meaningful only in multi-tenant installations with more than one distinct folder owner; no public exploit identified at time of analysis.
FileRise versions prior to 3.21.0 track failed logins only as a source-IP plus username pair, so a remote unauthenticated attacker can rotate usernames to obtain a fresh failed-attempt budget for every account name attempted, enabling password spraying from a single source beyond the intended limit. Per-username limits still apply, which can additionally produce distinguishable throttling behavior against targeted accounts and aid username discovery. Rated CVSS 6.5 (medium), with no public exploit code identified at time of analysis and no evidence of active exploitation; the weakness degrades brute-force protection rather than bypassing authentication itself, so real-world impact depends on whether weak or guessable credentials exist on target accounts.
FileRise releases prior to 3.21.0 enforce administrator-configured login-method restrictions only in the browser client, so an authenticated user holding valid credentials for a method the administrator has disabled (form login, Basic Auth, or OIDC) can still authenticate by calling that method's backend endpoint directly. Exploitation is not credential-free - valid credentials for the disabled method are mandatory (CVSS vector PR:L) and only deployments that have actually disabled a method are affected, since a default all-enabled install has no policy to bypass - but the flaw fully defeats the login-method policy admins rely on for attack-surface reduction. Impact is bounded to policy enforcement rather than privilege escalation (CVSS 5.4, C:L/I:L/A:N), and no public exploit code or confirmed active exploitation was identified at time of analysis; the vendor fixes the issue in version 3.21.0.
Decryption of stored TOTP secrets and credentials in FileRise manual (non-Docker) installations from 3.9.0 before 3.22.0 is possible when the instance runs on a published legacy compatibility key because neither PERSISTENT_TOKENS_KEY nor metadata/persistent_tokens.key is present. An attacker must separately obtain the ciphertext-bearing account or configuration files (such as persistent_tokens.json, adminConfig.json, or the users file) before the known key can be used, so the medium CVSS 5.9 rating reflects high attack complexity and a narrow set of prerequisites. No public exploit code or confirmed active exploitation was identified at time of analysis. The issue is fixed in 3.22.0.
FileRise versions prior to 3.21.0 return the administrator-configured branding.footerHtml value verbatim through the unauthenticated public site-configuration API, so raw admin-supplied HTML reaches any client that consumes that endpoint. Because the official FileRise frontend already sanitizes the footer with a tag allowlist (a, b, strong, em, i, span, small, br) and safe-link handling before rendering, the bundled web client is not exploitable; realistic impact is confined to alternate or third-party clients, or future render paths, that display footerHtml without their own sanitization. Exploitation requires an authenticated administrator (PR:H) to first store a crafted value and a victim to load an affected client (UI:R), which is why this is rated defense-in-depth / low priority rather than an urgent threat, and no public exploit code has been identified at time of analysis.
FileRise deployments prior to 3.20.0 expose the /api/file/snippet.php short-text preview endpoint without the standard authenticated-session guard, allowing unauthenticated network requests to reach ACL evaluation rather than receiving an immediate 401. On default, correctly configured installations the ACL checks still block access, so arbitrary file read is not possible; actual short preview content disclosure requires an additional non-default reverse-proxy header configuration or ACL misconfiguration, making the assessed real-world risk LOW (CVSS 3.7). No public exploit identified at time of analysis.
Authenticated path traversal in FileRise versions prior to 3.19.0 lets a low-privileged user who already holds create or owner permission on a parent folder create directories outside the configured upload root by submitting dot-dot segments to the folder-creation API. The impact is limited to arbitrary directory creation (integrity and availability impact rated low, CVSS 3.1 base score 5.4, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) - there is no file read, overwrite, or code execution primitive, and the traversal only succeeds where the web-server operating-system account can already write. The issue requires a valid account, the appropriate parent-folder permission, and a valid CSRF token, so it cannot be triggered anonymously, and no public exploit identified at time of analysis; the vendor released a fix in 3.19.0 that rejects dot and dot-dot segments and validates that the parent path resolves inside the upload root.
Privilege retention in FileRise prior to 3.16.0 lets a demoted administrator keep administrator access by replaying a remember-me token that was issued while the account still held the administrator role. An authenticated attacker who possesses such a pre-demotion token and whose account was demoted rather than deleted can be restored to full administrative privileges through the automatic (remember-me) login path, because the application trusts the isAdmin flag stored in the token instead of re-resolving the account's current role from users.txt; token rotation copies the stale privilege into every replacement token. No public exploit code has been identified at time of analysis, and the flaw is fixed in version 3.16.0 per the vendor advisory and the referenced commit.
Authenticated FileRise users who hold both upload and archive-extraction permissions can bypass the application's blocked-extension upload policy by packaging a PHP-family file inside a ZIP archive and extracting it, because the filename policy is never applied before ZipArchive::extractTo() writes entries to disk (CWE-434). All FileRise versions prior to 3.16.0 are affected via the network with low privileges (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, 6.5); the guaranteed outcome is arbitrary-extension file write, and code execution occurs only on deployments whose web server actually executes content from the upload/storage directory. Exploitation is conditional rather than confirmed in the wild - no public exploit code has been identified at time of analysis and there is no CISA KEV entry - and the vendor addressed the flaw with upstream fix commit f7114ca2a4e624238dda0d097a07ad6b05c11bb6, released in version 3.16.0.
Cross-site request forgery in FileRise versions prior to 3.14.0 lets an attacker who lures an already-authenticated user into issuing a forged POST create an empty file or a share link under that user's identity, because the /api/file/createFile.php and /api/file/createShareLink.php handlers omit the server-side X-CSRF-Token check that adjacent state-changing endpoints enforce. The attacker does not need credentials of their own (PR:N), but the victim must hold an active session and be induced to make the request (UI:R); assessed severity is low (CVSS 4.3, AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N), and impact is bounded to file creation and share-link creation with the victim's permissions, not arbitrary content upload or account takeover. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the default SameSite=Lax session cookie is the decisive practical limiter, since a standard scripted cross-site POST will not carry the session cookie.
FileRise versions 2.3.7 through 3.10.0 suffer from improper access control in the file snippet endpoint, allowing authenticated users with read-only access to retrieve file content uploaded by other users in shared folders. An attacker with limited folder permissions can exploit this authorization bypass to view sensitive files beyond their intended access scope. The vulnerability affects FileRise running on PHP and is resolved in version 3.11.0.
FileRise, a self-hosted web file manager and WebDAV server, contains an unrestricted file upload vulnerability in its WebDAV endpoint that bypasses filename validation controls present in the regular upload path, allowing authenticated attackers to upload executable file types such as .phtml, .php5, and .htaccess. In non-default Apache configurations lacking LocationMatch protection, this enables remote code execution on the underlying web server. The vulnerability affects FileRise versions prior to 3.8.0 and has been patched; no public exploit code or active KEV listing is currently confirmed, but the presence of a GitHub security advisory indicates vendor acknowledgment of the threat.
FileRise, a self-hosted web file manager and WebDAV server, contains a missing-authentication vulnerability in the deleteShareLink endpoint that allows unauthenticated attackers to delete arbitrary file share links by providing only the share token, resulting in denial of service to legitimate users accessing shared files. All versions prior to 3.8.0 are affected. While the CVSS score is moderate at 3.7 due to high attack complexity, the vulnerability has a published proof-of-concept via the GitHub security advisory and represents a trivial attack surface requiring only knowledge of a share token.
FileRise versions before 3.3.0 contain an HTML injection vulnerability that allows authenticated users to manipulate the DOM and inject malicious form or link elements to redirect users or trigger unauthorized actions. Public exploit code exists for this medium-severity flaw, and no patch is currently available. The vulnerability requires user interaction and valid credentials to exploit, limiting its immediate impact but creating risk for organizations running affected FileRise instances.
Stored cross-site scripting in FileRise versions before 2.2.3 allows an authenticated user with upload rights to embed JavaScript in an SVG file that executes in the application origin when another user previews it. Exploitation requires victim interaction (opening the file list or preview modal) and can produce limited confidentiality and integrity impact within the FileRise origin; single-user instances have minimal cross-user risk, while multi-user deployments where low-privilege users upload files viewed by admins carry the real exposure. Publicly available exploit code exists, but EPSS is low at 0.04% (12th percentile) and no CISA KEV confirmation is present in the supplied data.
FileRise 1.4.0 exposes folder visibility and ownership decisions to authenticated low-privilege users because a regression derives access from folder names instead of an explicit access-control list, letting an attacker list, read, write, share, rename, copy/move, zip, and even reach over WebDAV folders they should not own - including folders named after their own username and, in some cases, other users' content. The flaw requires a valid low-privilege account (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, score 8.1), so it is an authenticated privilege-boundary failure rather than a pre-auth remote compromise, and it primarily matters in multi-user deployments where other users' files actually exist. No public exploit code has been identified at time of analysis and CISA KEV does not list this CVE; the vendor patched the issue in FileRise 1.5.0, which introduces explicit per-folder ACLs and removes name-based ownership assumptions.
Low-privilege users of FileRise versions prior to 1.4.0 can view, delete, or modify files owned by other users because the application infers ownership from folder names and lacks server-side authorization checks on file-operation endpoints (CWE-280). This IDOR-style access-control flaw is rated CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) and requires only an authenticated non-admin account on a multi-user instance; no public exploit code or active exploitation is identified in the provided data. Upgrading to 1.4.0 (further hardened in 1.5.0) or applying the vendor's workarounds removes the exposure.
Authentication bypass in FileRise versions before 3.23.0 lets a remote attacker log in as an existing local account - including the built-in administrator - by presenting OIDC claims whose mutable preferred_username value, or an unverified email, collides with that account's local username; the flaw works even when OIDC automatic provisioning is disabled. Successful takeover yields full read, write, and delete control over the file manager and its stored files, consistent with the assessed CVSS 3.1 score of 8.1 (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H). Exploitation is conditional, not universal: the deployment must be configured for OIDC SSO and the identity provider must allow the colliding claim or omit email_verified, which is what drives the High attack-complexity rating; no public exploit code was identified at time of analysis and the issue is not listed in CISA KEV. The vulnerability is fixed in FileRise 3.23.0.
Online second-factor guessing against FileRise releases prior to 3.23.0 is permitted well beyond the intended limit because failed TOTP verification attempts are recorded only in the PHP session rather than in a durable account-wide budget. An attacker who already possesses a valid primary credential (username plus password) for an account with TOTP enabled can abandon the pending login, start a fresh session, or change source address to restore the five-attempt allowance and continue guessing time-based codes indefinitely. Exploitation therefore has a hard precondition - the primary credential - and each guess remains a probabilistic online attempt against a rotating code, but a successful guess yields full account compromise; the vendor addressed the flaw in v3.23.0 and no public exploit code has been identified at time of analysis.
Authorization bypass in FileRise prior to 3.18.0 allows an authenticated, low-privileged user to read - and, when they also hold edit-own permission, modify - files they do not own by exploiting a collision in folder metadata filenames. FileRise flattens logical folder paths into metadata filenames by replacing '/', '\\' and spaces with hyphens, so distinct folders such as team/docs and team-docs resolve to the same <name>_metadata.json file; an attacker who controls one colliding folder and knows the target basename can overwrite the uploader-ownership metadata that read_own and ownership-restricted edit checks rely on, making a victim file appear attacker-owned. The issue is rated CVSS 7.1 (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:L) and is fixed in 3.18.0; exploitation requires a multi-user deployment, a crafted colliding folder name, pre-existing read_own access to the target folder and knowledge of the exact victim basename, and no public exploit identified at time of analysis. Single-tenant or single-user installations are effectively unaffected because no second user exists to victimize.
File overwrite in FileRise prior to 3.18.0 allows an unauthenticated visitor who holds a valid upload-enabled shared-folder or upload-only link token - plus any configured share password - to re-upload a file using the exact name of an existing file and silently replace its contents while the original uploader metadata is preserved. The same missing replacement check affects ordinary authenticated uploads through /api/upload/upload.php and authenticated upload-only users who lack edit authority over the target file, so the outcome is a high-integrity, no-confidentiality loss (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:L, 8.2). Exploitation requires that an administrator has actually created and shared an upload-capable link and that the attacker knows or guesses the target filename; impact is confined to overwriting existing files, with no data disclosure and no code execution path. No public exploit code was identified at time of analysis, and the vendor-released fix is FileRise 3.18.0.
Unauthenticated administrative account takeover in FileRise versions prior to 3.16.0: because the application treats an empty or missing users.txt as a fresh installation, a remote caller with no credentials can detect that first-run setup has silently reopened and create the next initial administrator account through the setup flow. The empty-user-store condition must first arise from storage loss, truncation, or another failure after setup previously completed (hence the AC:H rating), so reliably-stored, intact installations are not exposed; once that state exists, exploitation requires no authentication and no user interaction (PR:N/UI:N) and yields high confidentiality and integrity impact (CVSS 7.4). There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis, though the flaw is trivially reproducible by anyone who notices the exposed setup page.
Multi-factor authentication bypass in FileRise WebDAV prior to 3.16.0 allows an attacker who already holds a valid username and password for a TOTP-enabled account to authenticate to the WebDAV endpoint without supplying the second factor, then operate within that account's WebDAV file permissions. The weakness is conditionally gated: the opt-in WebDAV service must have been enabled by an administrator, the targeted account must have TOTP configured, and the attacker must already know the account's primary credentials, which the CVSS vector reflects as authenticated access (PR:L); the normal browser login path was never affected. Rated CVSS 3.1 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) with high confidentiality and integrity impact and no availability impact; no public exploit code or active exploitation was identified at time of analysis. The issue is fixed in FileRise 3.16.0.
Authentication bypass in FileRise (CWE-290) lets unauthenticated remote attackers impersonate any account - including an administrator - without a password or MFA in deployments prior to 3.16.0 that enable proxy-header authentication (AUTH_BYPASS) and expose the backend port directly. The flaw is that the configured reverse-proxy identity header (X-Remote-User) was trusted without validating that the request actually came from an address in FR_TRUSTED_PROXIES; an attacker who can reach the backend application port therefore simply supplies the header and receives a session for the named account. Exploitation requires proxy-header auth to be enabled, the trusted-proxy check to be absent or ineffective (exactly what 3.16.0 fixes), and a network path to the backend that bypasses the proxy, which is why it is scored AV:N/AC:H/PR:N/UI:N with full confidentiality, integrity, and availability impact (CVSS 3.1: 8.1 High); no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis.
Authenticated low-privilege users of FileRise before version 3.28.0 can obtain unauthorized read and write access at administrator level through the WebDAV interface by supplying valid Basic-Auth credentials alongside an active administrator PHPSESSID cookie, because the WebDAV layer inherits the elevated privileges of the ambient web session rather than authenticating each request independently as RFC 4918 requires. Exploitation is not trivial and depends on a co-occurring privileged session: the attacker must already hold valid low-privilege credentials (PR:L) and obtain the session cookie of a live administrator session, which is the basis for the high attack complexity (AC:H) in the CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N, base 7.6) and the assessed CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N); availability is unaffected. No public exploit code and no confirmed active exploitation (CISA KEV) were identified at the time of analysis, and the vendor has released FileRise 3.28.0, whose changelog describes refined, more consistent WebDAV request handling.
Unauthenticated administrator account takeover in FileRise before 3.16.0 is possible via a path traversal flaw in the shared-folder upload endpoint (/api/folder/uploadToSharedFolder.php), where URL-encoded path separators bypass filename validation and allow arbitrary file write outside the upload directory. Any actor holding a valid, non-expired, upload-enabled shared-folder token - tokens explicitly designed to be shared publicly - can overwrite users/users.txt to plant an admin account and, depending on configuration, achieve remote code execution. No public exploit identified at time of analysis, but the upstream fix in v3.16.0 documents the exact bypass, lowering the bar for weaponization.
A broken access control vulnerability in FileRise's ONLYOFFICE integration allows authenticated users with read-only permissions to overwrite files with malicious content by forging ONLYOFFICE save callbacks using legitimately obtained signed callbackUrls. FileRise versions prior to 3.10.0 are affected. There is no evidence of active exploitation (not in CISA KEV), but proof-of-concept details are available through the GitHub Security Advisory GHSA-6c3j-f4x4-36m3.
FileRise, a self-hosted web file manager and WebDAV server, contains a path traversal vulnerability in its Resumable.js chunked upload handler where the resumableIdentifier parameter is concatenated into filesystem paths without sanitization. Authenticated users with upload permissions can exploit this to write files to arbitrary directories, delete arbitrary directories, and probe filesystem structure. No evidence of active exploitation (not in CISA KEV) or public POC availability has been reported at this time.
FileRise, a self-hosted web file manager and WebDAV server, contains a critical hardcoded encryption key vulnerability in versions prior to 3.9.0. The default key 'default_please_change_this_key' is used for all cryptographic operations including HMAC token generation, AES configuration encryption, and session tokens, allowing unauthenticated attackers to forge upload tokens for arbitrary file upload and decrypt sensitive admin configuration data such as OIDC client secrets and SMTP passwords. No evidence of active exploitation (not in CISA KEV) is currently available, though the vulnerability is straightforward to exploit given the hardcoded nature of the default key.
Unauthenticated directory traversal in FileRise prior to version 3.3.0 allows remote attackers to read arbitrary files from the /uploads directory without authentication by directly accessing guessable file paths. Public exploit code exists for this vulnerability, enabling attackers to expose sensitive data and breach user privacy. No patch is currently available.
Authenticated archive extraction in FileRise prior to 3.23.0 can overwrite and then delete files outside the configured storage root, but only when the destination folder already contains a symlink pointing to a directory outside that root. Exploitation requires a low-privileged but authenticated (PR:L) account holding 'extract' permission that can also place an attacker-controlled ZIP, 7z, or RAR in the affected folder, plus a pre-existing symlink the advisory does not establish the attacker can create; the FileRise OS process must also already hold write or delete permission on the external target, which is why attack complexity is rated high (AC:H) despite the network vector. The resulting CVSS 3.1 base score is 6.8 (Medium) with high integrity and availability impact and no confidentiality impact, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Path traversal in FileRise 3.22.0 allows an authenticated non-administrator whose session holds inherited edit permission on a legitimate ancestor folder to supply dot and dot-dot segments through the /api/file/saveFile.php folder input, causing attacker-controlled files to be written outside the authorized folder and, where backend credentials permit, outside the configured WebDAV root. Exploitation requires a valid CSRF token plus an authenticated session with inherited edit rights (CVSS 3.1: 6.5, AV:N/AC:L/PR:L/UI:N, I:H only), and no public exploit identified at time of analysis; this is a moderate, authentication-gated integrity risk rather than a top-tier emergency. Vendor-released patch: 3.23.0.
Unauthenticated information disclosure in the FileRise Pro portal-detail endpoint (/api/pro/portals/get.php) lets any remote caller who knows or guesses a client portal's slug retrieve that portal's full internal record, including internal storage folder paths, client contact email addresses, form settings, and upload-policy details, instead of the curated branding fields that the public publicMeta.php endpoint intentionally exposes. The flaw affects only installations running the FileRise Pro add-on with at least one configured client portal; base-edition FileRise deployments are unaffected, and file contents or credentials are not exposed. The issue carries a self-consistent CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N (5.3, CWE-200), and no public exploit code or active exploitation has been identified at time of analysis; it is resolved in FileRise 3.24.0.
Successful TOTP second-factor codes in FileRise prior to 3.23.0 can be replayed from a separate pending-login session, allowing an attacker who already holds the target account's valid username and password to complete authentication and reach that account with high confidentiality and integrity impact. The flaw exists because the application (CWE-287, Improper Authentication) validates a submitted code against the accepted time window but never records that the same account and time step was already consumed, so a captured still-valid code keeps working until the window expires. Exploitation is a narrow, targeted race - it requires possession of the primary credential plus capture of a live code during a genuine victim login (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N, base 6.4) - and no public exploit code is identified at time of analysis; a vendor patch in version 3.23.0 is available.
FileRise versions prior to 3.23.0 allow an authenticated user who already holds a valid session and that session's CSRF token to change second-factor settings at the TOTP management endpoints without any recent full reauthentication, so the attacker can either disable an already-configured TOTP factor or activate a newly enrolled TOTP secret on an account that currently has none. The rated impact is integrity-only (CVSS 6.5, CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N; CWE-306) because the enrollment endpoint returns HTTP 409 rather than overwriting an active authenticator, meaning a protected account can be weakened but not silently re-enrolled. The practical precondition is substantial - the attacker must already control an authenticated session plus its CSRF token - and no public exploit identified at time of analysis; the fix is shipped in 3.23.0.
Improper authorization in the FileRise folder-rename API (all versions prior to 3.23.0) lets an authenticated, non-administrator user who owns a source folder move that entire folder tree beneath another user's existing folder or into the admin-controlled root namespace, with the relocated tree's ownership and ACL records rekeyed to the new path. Exploitation requires valid authentication plus a CSRF token scoped to the source folder, and the chosen destination must be unused, so existing victim files cannot be overwritten and their contents are never exposed; the only disclosure is a path-existence oracle from distinct pre-fix error messages. It is rated CVSS 5.4 (medium) and is meaningful only in multi-tenant installations with more than one distinct folder owner; no public exploit identified at time of analysis.
FileRise versions prior to 3.21.0 track failed logins only as a source-IP plus username pair, so a remote unauthenticated attacker can rotate usernames to obtain a fresh failed-attempt budget for every account name attempted, enabling password spraying from a single source beyond the intended limit. Per-username limits still apply, which can additionally produce distinguishable throttling behavior against targeted accounts and aid username discovery. Rated CVSS 6.5 (medium), with no public exploit code identified at time of analysis and no evidence of active exploitation; the weakness degrades brute-force protection rather than bypassing authentication itself, so real-world impact depends on whether weak or guessable credentials exist on target accounts.
FileRise releases prior to 3.21.0 enforce administrator-configured login-method restrictions only in the browser client, so an authenticated user holding valid credentials for a method the administrator has disabled (form login, Basic Auth, or OIDC) can still authenticate by calling that method's backend endpoint directly. Exploitation is not credential-free - valid credentials for the disabled method are mandatory (CVSS vector PR:L) and only deployments that have actually disabled a method are affected, since a default all-enabled install has no policy to bypass - but the flaw fully defeats the login-method policy admins rely on for attack-surface reduction. Impact is bounded to policy enforcement rather than privilege escalation (CVSS 5.4, C:L/I:L/A:N), and no public exploit code or confirmed active exploitation was identified at time of analysis; the vendor fixes the issue in version 3.21.0.
Decryption of stored TOTP secrets and credentials in FileRise manual (non-Docker) installations from 3.9.0 before 3.22.0 is possible when the instance runs on a published legacy compatibility key because neither PERSISTENT_TOKENS_KEY nor metadata/persistent_tokens.key is present. An attacker must separately obtain the ciphertext-bearing account or configuration files (such as persistent_tokens.json, adminConfig.json, or the users file) before the known key can be used, so the medium CVSS 5.9 rating reflects high attack complexity and a narrow set of prerequisites. No public exploit code or confirmed active exploitation was identified at time of analysis. The issue is fixed in 3.22.0.
FileRise versions prior to 3.21.0 return the administrator-configured branding.footerHtml value verbatim through the unauthenticated public site-configuration API, so raw admin-supplied HTML reaches any client that consumes that endpoint. Because the official FileRise frontend already sanitizes the footer with a tag allowlist (a, b, strong, em, i, span, small, br) and safe-link handling before rendering, the bundled web client is not exploitable; realistic impact is confined to alternate or third-party clients, or future render paths, that display footerHtml without their own sanitization. Exploitation requires an authenticated administrator (PR:H) to first store a crafted value and a victim to load an affected client (UI:R), which is why this is rated defense-in-depth / low priority rather than an urgent threat, and no public exploit code has been identified at time of analysis.
FileRise deployments prior to 3.20.0 expose the /api/file/snippet.php short-text preview endpoint without the standard authenticated-session guard, allowing unauthenticated network requests to reach ACL evaluation rather than receiving an immediate 401. On default, correctly configured installations the ACL checks still block access, so arbitrary file read is not possible; actual short preview content disclosure requires an additional non-default reverse-proxy header configuration or ACL misconfiguration, making the assessed real-world risk LOW (CVSS 3.7). No public exploit identified at time of analysis.
Authenticated path traversal in FileRise versions prior to 3.19.0 lets a low-privileged user who already holds create or owner permission on a parent folder create directories outside the configured upload root by submitting dot-dot segments to the folder-creation API. The impact is limited to arbitrary directory creation (integrity and availability impact rated low, CVSS 3.1 base score 5.4, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L) - there is no file read, overwrite, or code execution primitive, and the traversal only succeeds where the web-server operating-system account can already write. The issue requires a valid account, the appropriate parent-folder permission, and a valid CSRF token, so it cannot be triggered anonymously, and no public exploit identified at time of analysis; the vendor released a fix in 3.19.0 that rejects dot and dot-dot segments and validates that the parent path resolves inside the upload root.
Privilege retention in FileRise prior to 3.16.0 lets a demoted administrator keep administrator access by replaying a remember-me token that was issued while the account still held the administrator role. An authenticated attacker who possesses such a pre-demotion token and whose account was demoted rather than deleted can be restored to full administrative privileges through the automatic (remember-me) login path, because the application trusts the isAdmin flag stored in the token instead of re-resolving the account's current role from users.txt; token rotation copies the stale privilege into every replacement token. No public exploit code has been identified at time of analysis, and the flaw is fixed in version 3.16.0 per the vendor advisory and the referenced commit.
Authenticated FileRise users who hold both upload and archive-extraction permissions can bypass the application's blocked-extension upload policy by packaging a PHP-family file inside a ZIP archive and extracting it, because the filename policy is never applied before ZipArchive::extractTo() writes entries to disk (CWE-434). All FileRise versions prior to 3.16.0 are affected via the network with low privileges (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N, 6.5); the guaranteed outcome is arbitrary-extension file write, and code execution occurs only on deployments whose web server actually executes content from the upload/storage directory. Exploitation is conditional rather than confirmed in the wild - no public exploit code has been identified at time of analysis and there is no CISA KEV entry - and the vendor addressed the flaw with upstream fix commit f7114ca2a4e624238dda0d097a07ad6b05c11bb6, released in version 3.16.0.
Cross-site request forgery in FileRise versions prior to 3.14.0 lets an attacker who lures an already-authenticated user into issuing a forged POST create an empty file or a share link under that user's identity, because the /api/file/createFile.php and /api/file/createShareLink.php handlers omit the server-side X-CSRF-Token check that adjacent state-changing endpoints enforce. The attacker does not need credentials of their own (PR:N), but the victim must hold an active session and be induced to make the request (UI:R); assessed severity is low (CVSS 4.3, AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N), and impact is bounded to file creation and share-link creation with the victim's permissions, not arbitrary content upload or account takeover. There is no confirmed active exploitation (not in CISA KEV) and no public exploit identified at time of analysis; the default SameSite=Lax session cookie is the decisive practical limiter, since a standard scripted cross-site POST will not carry the session cookie.
FileRise versions 2.3.7 through 3.10.0 suffer from improper access control in the file snippet endpoint, allowing authenticated users with read-only access to retrieve file content uploaded by other users in shared folders. An attacker with limited folder permissions can exploit this authorization bypass to view sensitive files beyond their intended access scope. The vulnerability affects FileRise running on PHP and is resolved in version 3.11.0.
FileRise, a self-hosted web file manager and WebDAV server, contains an unrestricted file upload vulnerability in its WebDAV endpoint that bypasses filename validation controls present in the regular upload path, allowing authenticated attackers to upload executable file types such as .phtml, .php5, and .htaccess. In non-default Apache configurations lacking LocationMatch protection, this enables remote code execution on the underlying web server. The vulnerability affects FileRise versions prior to 3.8.0 and has been patched; no public exploit code or active KEV listing is currently confirmed, but the presence of a GitHub security advisory indicates vendor acknowledgment of the threat.
FileRise, a self-hosted web file manager and WebDAV server, contains a missing-authentication vulnerability in the deleteShareLink endpoint that allows unauthenticated attackers to delete arbitrary file share links by providing only the share token, resulting in denial of service to legitimate users accessing shared files. All versions prior to 3.8.0 are affected. While the CVSS score is moderate at 3.7 due to high attack complexity, the vulnerability has a published proof-of-concept via the GitHub security advisory and represents a trivial attack surface requiring only knowledge of a share token.
FileRise versions before 3.3.0 contain an HTML injection vulnerability that allows authenticated users to manipulate the DOM and inject malicious form or link elements to redirect users or trigger unauthorized actions. Public exploit code exists for this medium-severity flaw, and no patch is currently available. The vulnerability requires user interaction and valid credentials to exploit, limiting its immediate impact but creating risk for organizations running affected FileRise instances.
Stored cross-site scripting in FileRise versions before 2.2.3 allows an authenticated user with upload rights to embed JavaScript in an SVG file that executes in the application origin when another user previews it. Exploitation requires victim interaction (opening the file list or preview modal) and can produce limited confidentiality and integrity impact within the FileRise origin; single-user instances have minimal cross-user risk, while multi-user deployments where low-privilege users upload files viewed by admins carry the real exposure. Publicly available exploit code exists, but EPSS is low at 0.04% (12th percentile) and no CISA KEV confirmation is present in the supplied data.
FileRise 1.4.0 exposes folder visibility and ownership decisions to authenticated low-privilege users because a regression derives access from folder names instead of an explicit access-control list, letting an attacker list, read, write, share, rename, copy/move, zip, and even reach over WebDAV folders they should not own - including folders named after their own username and, in some cases, other users' content. The flaw requires a valid low-privilege account (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N, score 8.1), so it is an authenticated privilege-boundary failure rather than a pre-auth remote compromise, and it primarily matters in multi-user deployments where other users' files actually exist. No public exploit code has been identified at time of analysis and CISA KEV does not list this CVE; the vendor patched the issue in FileRise 1.5.0, which introduces explicit per-folder ACLs and removes name-based ownership assumptions.
Low-privilege users of FileRise versions prior to 1.4.0 can view, delete, or modify files owned by other users because the application infers ownership from folder names and lacks server-side authorization checks on file-operation endpoints (CWE-280). This IDOR-style access-control flaw is rated CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) and requires only an authenticated non-admin account on a multi-user instance; no public exploit code or active exploitation is identified in the provided data. Upgrading to 1.4.0 (further hardened in 1.5.0) or applying the vendor's workarounds removes the exposure.