CVE-2026-103977 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 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. The pending-login TOTP handlers did not share a durable account-wide limit. 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 that provides features such as multi-file upload, editing capabilities, and batch operations for managing digital assets. The software relies on two-factor authentication using Time-based One-Time Passwords (TOTP) to enhance the security of user accounts beyond standard username and password combinations. In versions prior to 3.23.0, a critical implementation flaw exists within the session management logic regarding how failed authentication attempts are tracked during the second factor verification process. This vulnerability allows an attacker who has already compromised or obtained valid primary credentials for a target account to bypass rate limiting controls designed to prevent brute-force attacks against TOTP codes.
The technical root cause of this vulnerability lies in the storage mechanism used for tracking failed login attempts. The application stores these failure counts within the PHP $_SESSION superglobal, which is inherently tied to specific browser sessions rather than being persisted at an account-wide level on the server side. When a user enters an incorrect TOTP code, the counter increments within that specific session context. However, if the authentication workflow fails or times out before completion, and the attacker initiates a new login sequence by creating a fresh HTTP session, the application initializes a new $_SESSION array with default values. Consequently, the count of previous failed attempts is reset to zero because the new session does not inherit the failure history from the previous one. This architectural decision effectively nullifies the intended security control that limits an attacker to five guessing attempts per login cycle.
From an operational perspective, this flaw significantly expands the attack surface for credential-based attacks. While TOTP codes are typically generated using a 6-digit numeric format providing approximately one million possible combinations, rate limiting is essential to make brute-force efforts computationally infeasible within a reasonable timeframe. By exploiting the session reset behavior, an attacker can systematically guess valid TOTP codes without ever hitting the five-attempt lockout threshold. The attacker simply needs to restart the login process after each failed attempt or batch of attempts that do not result in immediate account lockout due to other factors. This allows for a continuous online guessing attack where the effective number of allowed guesses is only limited by external network-level rate limiting, if any exists at all, rather than application-level logic.
This vulnerability aligns with CWE-307 Improper Restriction of Excessive Authentication Attempts, as the system fails to enforce adequate limits on repeated authentication attempts for a single account. Furthermore, it relates to CWE-613 Insufficient Session Expiration because the session state does not properly maintain security-relevant data across multiple interactions when the initial interaction is abandoned or reset. In terms of MITRE ATT&CK framework classification, this behavior facilitates Credential Access techniques such as Brute Force and Password Guessing, specifically allowing for online dictionary attacks against multi-factor authentication tokens which are generally considered more secure than single-factor passwords alone.
To mitigate this vulnerability, it is imperative to upgrade FileRise to version 3.23.0 or later where the issue has been resolved. The fix likely involves moving the failed attempt counter from volatile session storage to a persistent backend store such as a database or cache system that associates failure counts with the user account identifier rather than the transient session ID. Additionally, administrators should ensure that their deployment includes robust network-level rate limiting and monitoring for suspicious login patterns. Implementing IP-based throttling alongside application-level account-wide limits provides defense in depth against automated guessing tools. Regular security audits of authentication flows are recommended to identify similar state management flaws in other components of the web application infrastructure.