CVE-2026-104105

Executive Summary

CVE-2026-104105 is an authentication weakness in FileRise, a self-hosted web-based file manager, affecting versions prior to 3.23.0. The application validates a TOTP code against the accepted time window but fails to record successful use of a given code for a given account and time step, permitting TOTP replay within the same time window. An attacker who already possesses a target account's valid primary credential and captures a TOTP code after its legitimate use can replay that code from a separate pending-login session, potentially completing authentication as the victim. The issue is fixed in version 3.23.0; no public exploit code, Nuclei template, or KEV entry is currently available.

Technical Analysis

The vulnerability class is CWE-287 (Improper Authentication), specifically a missing one-time-use enforcement for TOTP-based multi-factor authentication (MFA). TOTP (Time-based One-Time Password) algorithms derive a numeric code from a shared secret and a time step (typically a 30-second interval). By design, a TOTP code should be accepted at most once for a given account and time step; robust implementations track the last successfully used time step per account (and often reject reuse of any step equal to or lower than the last consumed step).

According to the NVD description, prior to version 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." In practical terms, the server-side validation path confirms the mathematical validity of the submitted code against the expected TOTP for the current window but does not persist or consult any record of prior successful consumption. As a result, the same code remains valid for acceptance for as long as the verification window remains open.

The attack surface is the remote, network-accessible authentication interface of the FileRise web application (AV:N). The flaw is not in the cryptographic derivation of the TOTP but in the state management of the login workflow: the absence of a consumed-code marker keyed by account and time step. This is a classic TOTP replay condition. Important scoping notes from the description:

• The issue does not, by itself, disclose either the primary credential or the TOTP code. It depends on the attacker already holding a valid primary credential and having captured a valid TOTP code after it was successfully used.
• The attack requires the interaction/participation of conditions outside the vulnerable code path (capture of the TOTP code and an existing valid primary credential), reflected in the CVSS vector AC:H and UI:R.
• There is no evidence in the provided data of code execution, memory corruption, privilege escalation, or lateral movement capability arising from this flaw itself. The impact is confined to completing authentication (authentication bypass/impersonation) and the resulting access to the target account's file management functions.

Because no specific function names, endpoints, parameter names, or file paths appear in the supplied NVD description or CNA title, no implementation-level identifiers are asserted in this report. The authoritative behavioral facts are limited to: TOTP validity window acceptance, absence of account/time-step consumption recording, replayability from another pending-login session before window close, and remediation in 3.23.0.

Exploitation Scenarios

No public PoC is available; the attack chain below is inferred strictly from the vulnerability class and the stated preconditions in the NVD description.

1. Reconnaissance / target identification: The attacker identifies an Internet-exposed or reachable FileRise instance (self-hosted file manager) with an account of interest. Reconnaissance is limited to confirming the application and its login/MFA flow exists; no specific endpoint or parameter is documented in the provided data.

2. Precondition acquisition: The attacker requires two things, both explicitly stated as prerequisites in the NVD description:

   • The target account's valid primary credential.
   • A valid TOTP code captured after it has been successfully used by the legitimate user (i.e., observation of the code during or after a successful login within the current time window).

3. Triggering the flaw (vulnerability-class level): Before the accepted TOTP time window closes, the attacker initiates a separate authentication attempt ("another pending-login session" per the description) using the already-valid primary credential plus the previously used TOTP code. Because the server validates the code against the current time window but does not record that the same account and time step already succeeded, the replayed code is accepted.

4. Execution method: This is a credential/authentication workflow abuse, not a payload delivery or code injection technique. No network payload, shellcode, or injection string is associated with the vulnerability class as described.

5. Post-exploitation impact: Successful replay results in authentication as the target account. The attacker then gains access to the file management capabilities of that account in FileRise (multi-file upload, editing, and batch operations, per the description). Further actions depend entirely on the privileges of the compromised account and are not specified by the vulnerability data.

Key constraints to retain in any assessment: the flaw alone does not leak the primary credential or the TOTP code; success requires prior capture of the code and possession of the primary credential; and success is bounded by the TOTP acceptance window.

Impact Assessment

Per the supplied CVSS v3.1 vector (CVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:U/C:H/I:H/A:N), base score 6.4 (Medium):

• Attack Vector: Network (AV:N) — the login interface is remotely reachable.
• Attack Complexity: High (AC:H) — success depends on capturing a valid TOTP code after its successful use and acting within the acceptance window, rather than a repeatable, deterministic condition.
• Privileges Required: Low (PR:L) — the attacker must already hold a valid primary credential for the target account. This significantly bounds the population of capable attackers.
• User Interaction: Required (UI:R) — a legitimate authentication event (and the capture of its TOTP code) must occur for the replayed code to exist.
• Scope: Unchanged (S:U) — impact is confined to the FileRise application's security context.
• Confidentiality: High (C:H) — successful impersonation exposes the target account's accessible files and data through the file manager.
• Integrity: High (I:H) — the account's file management functions, including editing and batch operations, become attacker-controllable.
• Availability: None (A:N) — no denial-of-service component is described.

Business impact: For organizations running self-hosted FileRise, this is an MFA-weakening condition rather than a standalone remote compromise. When combined with a compromised or re-used primary credential, it reduces the practical protective value of TOTP for the duration of the code window, enabling account impersonation and unauthorized access to, modification of, or bulk operations against files the victim account can reach. Blast radius is limited to accounts whose primary credentials are already known to the attacker plus code-capture capability; it is not a broad unauthenticated exposure. No known threat actor campaigns or exploit-in-the-wild evidence are associated in the provided data, and EPSS is not yet scored by FIRST.org.

Detection Guidance

Sigma Rule

title: FileRise TOTP Replay - Repeated MFA Validation Success for Same Account Window
id: 8f3c1a52-7d64-4e21-9b0a-filerisemfa001
status: experimental
description: Detects multiple successful TOTP/MFA validations for the same account within a short interval, consistent with TOTP code replay prior to FileRise 3.23.0.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-104105
author: valtersit.com
date: 2026-01-01
logsource:
  category: authentication
  product: web
detection:
  selection_app:
    service: 'filerise'
  selection_event:
    EventType: 'MFA_SUCCESS'
  timeframe: 5m
  condition: selection_app and selection_event | count(user) by user > 1
fields:
  - user
  - src_ip
  - session_id
falsepositives:
  - Legitimate users re-authenticating across sessions with the same code due to clock drift
  - Administrative multi-session testing
level: medium

YARA Rule

rule CVE_2026_104105_FileRise_TOTP_Replay_Log_Indicator
{
    meta:
        description = "Detects log/config artifacts referencing FileRise version and MFA replay indicators"
        author = "valtersit.com"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-104105"
        date = "2026-01-01"
    strings:
        $app = "FileRise" ascii nocase
        $a1 = "TOTP" ascii nocase
        $a2 = "totp" ascii
        $vuln = "3.22" ascii
        $fixed = "3.23.0" ascii
    condition:
        uint16(0) == 0x3C or
        ($app and ($a1 or $a2) and $vuln and not $fixed)
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-104105 FileRise Possible TOTP Replay Multiple MFA Success Responses"; flow:established,to_client; content:"FileRise"; http_server_body; nocase; content:"Set-Cookie"; http_header; threshold:type threshold, track by_src, count 3, seconds 60; classtype:attempted-user; reference:cve,2026-104105; sid:2026104105; rev:1;)

Elastic Detection

sequence by user.name with maxspan=2m
  [ authentication where event.outcome == "success" and service.name == "filerise" and event.action == "mfa_validation" ]
  [ authentication where event.outcome == "success" and service.name == "filerise" and event.action == "mfa_validation" ]

Splunk SPL Query

index=weblog sourcetype=filerise action=mfa_validation status=success
| stats count values(src_ip) as source_ips values(session_id) as sessions by user, time_step
| where count > 1 and mvcount(sessions) > 1
| table _time user time_step count source_ips sessions

Wazuh OSSEC Rule

<group name="filerise,authentication,">
  <rule id="1041050" level="10">
    <decoded_as>json</decoded_as>
    <field name="app">FileRise</field>
    <field name="event">mfa_validation</field>
    <field name="status">success</field>
    <description>CVE-2026-104105: FileRise MFA/TOTP validation success recorded - possible TOTP replay</description>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>
  <rule id="1041051" level="12" frequency="2" timeframe="300">
    <if_matched_sid>1041050</if_matched_sid>
    <same_field>user</same_field>
    <description>CVE-2026-104105: Repeated FileRise MFA success for same account within window (TOTP replay suspected)</description>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). The following guidance is based solely on the NVD description stating the issue is fixed in version 3.23.0.

1. Immediate mitigations (no official workaround documented):

• Treat version 3.23.0 per the description as fixed; where upgrade is not yet possible, restrict network exposure of FileRise to trusted networks/VPN and enforce network-layer access control.
• Prioritize testing and upgrade of any instance where the same primary credential may have been exposed or shared, since the flaw only yields value once a primary credential is held by the attacker.
• Reduce the TOTP acceptance window through available configuration where the product supports it, to shrink the replay opportunity; this reduces but does not eliminate the condition described.
• Add monitoring for repeated successful MFA validations for the same account within a single time step (see Detection Guidance) and alert on it.

2. Patch/upgrade steps:

• Upgrade FileRise to version 3.23.0 or later. Confirm the running version after upgrade and verify that TOTP codes are consumed per account and time step (a single successful use should invalidate reuse within the window).
• Rotate TOTP secrets and passwords for accounts suspected of being targeted during the exposure period.
• Review authentication logs for repeated MFA successes tied to the same account and time step during the exposure window.

3. Long-term hardening:

• Enforce one-time-use semantics for all OTP verification, keyed by account and time step, as a design standard for MFA flows; explicitly track and reject previously consumed time steps.
• Require phishing-resistant MFA (e.g., FIDO2/WebAuthn) where feasible to remove replayable-code exposure.
• Apply rate limiting and anomaly detection to authentication endpoints, and centralize MFA success logging with account/time-step correlation for detection coverage.
• Maintain a version-inventory discipline for self-hosted web applications to shorten exposure to future authentication flaws.

References

• NVD — CVE-2026-104105: https://nvd.nist.gov/vuln/detail/CVE-2026-104105
• FileRise project (self-hosted web-based file manager) — consult the official project repository/releases page for the 3.23.0 release and any advisory.
• CWE-287 — Improper Authentication: https://cwe.mitre.org/data/definitions/287.html
• MITRE ATT&CK T1078 — Valid Accounts: https://attack.mitre.org/techniques/T1078/
• FIRST EPSS — not yet scored for this CVE at time of writing: https://www.first.org/epss/
• CISA KEV Catalog — CVE-2026-104105 is not listed: https://www.cisa.gov/known-exploited-vulnerabilities-catalog