CVE-2026-103977

Summary

FileRise versions before 3.23.0 stored failed TOTP verification attempts in PHP session state. The counter limited attempts within one session but did not persist across newly created sessions.

An attacker who already possesses a target account's valid primary credential could restart the login workflow, receive a new pending-login session, and restore the TOTP attempt allowance. Repeating this process permitted continued online TOTP guessing beyond the intended five-attempt limit.

Details

The TOTP verification flow maintained its failure counter in $_SESSION. After five failed submissions, further attempts in that session returned HTTP 429.

However, successfully completing primary authentication in a new session created new pending-login state with a new TOTP failure counter. The previous account's TOTP failures were therefore not carried forward.

The issue also affected another pending-login TOTP handler that did not enforce the same durable limit. The remediation was consequently applied centrally across all pending-login TOTP verification paths.

This issue is classified as CWE-307: Improper Restriction of Excessive Authentication Attempts.

Impact

Exploitation requires possession of the target account's valid primary credential, such as a password obtained through credential reuse, phishing, or another compromise.

The vulnerability does not disclose credentials or immediately bypass TOTP. It permits continued automated TOTP guessing without a durable account-wide limit. A successful guess completes authentication with the privileges of the affected account, potentially including administrator privileges.

Accounts without TOTP enabled are not affected by this specific second-factor rate-limit issue.

Remediation

FileRise 3.23.0 introduces centralized persistent TOTP attempt limiting:

• Each account is limited to five TOTP verification attempts per 15-minute window.
• The account limit persists across PHP sessions and client-address changes.
• A higher source-wide limit restricts attempts distributed across accounts.
• Attempts are reserved before verification using locked persistent state.
• All pending-login TOTP verification paths use the same limiter.
• Successful TOTP verification clears the account attempt budget.
• Password or identity-provider authentication does not reset TOTP failures.

Existing accounts, TOTP secrets, sessions, Docker installations, and deployment configuration require no migration.

Users should upgrade to FileRise 3.23.0 or later.

Maintainer Response

Thank you for the responsible disclosure and detailed reproduction steps.

We reviewed the TOTP verification workflow and confirmed the underlying issue. Failed TOTP submissions were limited only by a PHP session counter in the primary frontend verification endpoint. Repeating the successful primary-authentication step in a fresh session could therefore restore the second-factor attempt budget. Our review also identified another pending-login TOTP handler that did not apply the same attempt counter, so the remediation has been applied centrally across the verification paths rather than only to the reported endpoint.

The fix has been implemented for FileRise v3.23.0:

• Syntactically valid TOTP submissions now reserve an attempt from a persistent account-wide budget before verification.
• The account budget is independent of PHP session and client address, so replacing the session or rotating source addresses does not restore attempts.
• A higher persistent source-wide budget limits attempts distributed across accounts.
• Both pending-login TOTP handlers use the same limiter, covering form, Basic Auth, and OIDC-established pending-login sessions.
• Password or identity-provider success no longer resets the second-factor failure budget.
• Successful TOTP verification clears the account budget and removes the successful reservation from the source budget, so ordinary successful users on shared networks do not accumulate failures.
• Attempt state uses hashed account/source identifiers, locked updates, atomic file replacement, automatic expiry, and fail-closed handling if the limiter store is unavailable or corrupt.
• Successful recovery-code use clears the account's TOTP attempt state.

The account limit is five attempts in a 15-minute window. The source-wide limit is intentionally higher at 50 attempts in the same window to reduce false positives for shared networks. Existing accounts, TOTP secrets, sessions, Docker installations, and deployment configuration require no migration.

---

Credit: Pervin Zahidli (@ech0void ) Ref : https://github.com/error311/FileRise/security/advisories/GHSA-4hfj-6478-5cv7