CVE-2026-104105 in FileRise
Summary
by MITRE • 10/14/2026
FileRise is a self-hosted web-based file manager with multi-file upload, editing, and batch operations. Prior to 3.23.0, FileRise 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 who has the target account's valid primary credential and captures a TOTP code after its successful use can replay that code from another pending-login session before the window closes. The issue does not by itself disclose the primary credential or TOTP code. This issue is fixed in version 3.23.0.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
FileRise is a self-hosted web-based file management solution designed to facilitate multi-file uploads, editing, and batch operations for users requiring centralized data handling capabilities. The software employs two-factor authentication using Time-Based One-Time Passwords (TOTP) to enhance account security by verifying that the user possesses both their primary credentials and access to an authenticator device generating valid codes within a specific time window. This mechanism is intended to prevent unauthorized access even if passwords are compromised, relying on the assumption that TOTP codes are single-use tokens with limited validity periods.
A critical vulnerability exists in versions prior to 3.23.0 regarding the implementation of this two-factor authentication logic. Specifically, while the application correctly validates whether a submitted TOTP code falls within the acceptable time window and matches the expected value for the current step, it fails to maintain state regarding the consumption of that specific code. The system does not record or flag that a particular account has already successfully authenticated using a specific TOTP code during its validity period. This omission creates a race condition where the same valid token can be processed multiple times within the short window in which it remains valid, effectively treating one-time passwords as reusable credentials under certain conditions.
The operational impact of this flaw allows an attacker who possesses the target account's primary credential and has captured or intercepted a TOTP code after its initial successful use to replay that same code from another pending login session. By submitting the reused token before the time window expires, the attacker can bypass the second factor of authentication on subsequent attempts. This vulnerability does not inherently disclose the user's password or the underlying secret key used for generating codes; rather, it exploits the lack of idempotency in the verification process to allow credential reuse. The severity is heightened by the fact that TOTP codes are often short and numeric, making them susceptible to interception via network sniffing if transmitted over unencrypted channels or through other side-channel attacks during legitimate login attempts.
This vulnerability aligns with CWE-294, which describes a security flaw related to accepting a token for authentication more than once, commonly known as replay attacks. In the context of the MITRE ATT&CK framework, this behavior relates to techniques involving credential reuse and potentially bypassing multi-factor authentication mechanisms due to improper state management in the application logic. The failure to enforce single-use semantics on time-based tokens undermines the fundamental security guarantee provided by TOTP systems, which rely heavily on the uniqueness and non-reusability of each generated code to ensure that possession of a past valid token does not grant future access.
To mitigate this risk, organizations running FileRise must upgrade immediately to version 3.23.0 or later, where the developers have implemented proper state tracking to ensure that once a TOTP code is successfully validated for an account within its time step, it cannot be reused for subsequent authentication attempts during that same window. Until the update is applied, administrators should enforce strict network security controls such as TLS encryption to prevent interception of TOTP codes in transit and consider implementing additional monitoring or alerting mechanisms to detect multiple rapid login failures or successes from different sessions using similar timing patterns. Regular audits of authentication logs can also help identify potential exploitation attempts where a single valid code appears to be used across concurrent requests, although the most effective defense remains patching the application to enforce strict one-time use policies for all multi-factor tokens.