CVE-2026-104106

Executive Summary

CVE-2026-104106 is a missing-authentication-strength vulnerability in FileRise, a self-hosted web-based file manager, affecting all versions prior to 3.23.0. An authenticated attacker holding a valid session and CSRF token can disable the account's existing TOTP second factor, or initiate TOTP enrollment, without a recent full reauthentication. The core integrity failure is that the enrollment path persists and activates a newly generated TOTP secret before possession of that secret is verified by a code — so an attacker who controls an already-authenticated session can permanently alter the account's second-factor state. This is a second-factor bypass of an existing authentication control, not a direct overwrite of an active authenticator, and it grants the attacker durable, exclusive control over the MFA state of the compromised account.

Technical Analysis

FileRise is a self-hosted file manager supporting multi-file upload, editing, and batch operations. The vulnerability sits in the TOTP (time-based one-time password) management workflow rather than in the main authentication or file-handling surface. The affected logic is reachable only by an already-authenticated session; there is no unauthenticated path described.

Two distinct behaviors are identified in the NVD description:

1. Disabling an existing second factor without recent authentication. A session presenting a valid CSRF token can disable TOTP without the application re-verifying the user's identity via a recent full reauthentication (e.g., a password or MFA re-prompt). The CSRF token is present and valid, so the request passes any anti-CSRF check; the missing control is fresh authentication bound to the current session, not CSRF protection. This maps to CWE-306 (Missing Authentication for Critical Function) as scored by the NVD.

2. Enrollment when no TOTP secret exists. If the account currently has no configured TOTP secret, the enrollment endpoint can be used to begin enrollment. A critical detail is supplied by the NVD description: the enrollment endpoint returns HTTP 409 rather than directly overwriting an already-configured secret. This means the design does attempt to prevent overwriting an active authenticator — but a second flaw undercuts that protection: the enrollment flow persists and activates the newly generated secret before a TOTP code is submitted to verify possession. The secret becomes live in the datastore and is treated as the account's TOTP secret prior to any proof that the requester actually holds the corresponding seed. The possession-verification step is therefore decoupled from (and ordered after) the state-changing operation.

The pivot point for an attacker is the combination of these behaviors. Where the account already has TOTP configured, the first behavior (disable without reauth) removes the factor entirely. Where the account has no TOTP configured, the second behavior lets the attacker enroll a new authenticator seed that they control. In both cases the integrity of the authentication process is modified using only the privileges of an existing session, with no re-authentication barrier.

Attack surface: the web application's HTTP interface for TOTP configuration, requiring an authenticated session cookie and a valid CSRF token. There is no described network-level, file-parsing, or memory-safety component. No SQL injection, deserialization, or RCE primitive is described or implied.

The specific endpoint paths, parameter names, HTTP methods, and function/class identifiers are not disclosed in the NVD description or CNA title. Nothing in this report should be read as naming them; any such specifics would be fabrication.

Structural root cause: the enrollment state machine orders "generate → persist → activate" before "verify possession via submitted code," and the disable path does not require a fresh authentication event. Both are authorization/session-binding defects, not cryptographic weaknesses in TOTP itself.

Exploitation Scenarios

The following chain is described at the vulnerability-class level, strictly bounded by the NVD description. No public proof-of-concept, exploit code, or Nuclei template exists for this CVE; the chain below is inferred from the disclosed behavior and CWE-306 class, and no private function names or endpoints are invented.

1. Reconnaissance / target identification. FileRise is identifiable as a self-hosted deployment, potentially discoverable via its login page title and application-specific HTML. The attacker values any FileRise instance with at least one account that has an authenticated session recoverable or usable by the attacker. Practical avenues for obtaining an existing session include session-token theft (XSS elsewhere, cookie exfiltration, shared/kiosk browser, or a long-lived session that was never revalidated). Because the flaw requires a valid session and CSRF token, the victim/target account is the one whose session the attacker controls.

2. Triggering the flaw. With the session and a valid CSRF token for the account, the attacker reaches the TOTP management functionality.

   • Case A — existing TOTP configured: the attacker disables TOTP. No recent full reauthentication is demanded, so the session alone is sufficient to turn off the second factor.
   • Case B — no TOTP configured: the attacker initiates enrollment. The endpoint will not overwrite an active secret (it returns 409), but because no active secret exists, enrollment proceeds. The newly generated secret is persisted and activated before the attacker submits a verifying code.

3. Payload / execution. Execution is a series of authenticated HTTP requests carrying the session credential and the CSRF token. No exploit payload, shellcode, or injection string is involved — the "payload" is legitimate-looking TOTP configuration traffic. The attacker does not need to crack TOTP or predict a code; they exploit the order of operations in the enrollment workflow (secret activated pre-verification) and the absence of a reauth barrier on disable. For Case B, the attacker necessarily learns or sets the seed material as part of the enrollment they initiated, which is precisely why activating it before verification is dangerous.

4. Post-exploitation impact. The attacker now controls the second-factor state of the account:

   • If the factor was disabled, the account no longer enforces TOTP, and the attacker (and anyone else holding valid primary credentials) can authenticate with the password alone.
   • If a new secret was enrolled, the attacker possesses the seed and can produce valid TOTP codes for that account, while the legitimate user loses the expected behavior of their prior authenticator setup. This constitutes durable modification of the authentication process (T1556.006), enabling persistent, attacker-favored access and undermining the account-recovery and MFA-prompts-assume-second-factor workflows. Whether the attacker proceeds to abuse file-management features (upload, edit, batch operations) depends on the privileges of the hijacked account; the NVD description does not restrict or extend beyond the MFA-state impact.

Constraint on scope: the NVD description explicitly states this is not a direct overwrite of an active authenticator. The 409 response blocks naive overwrite of a configured secret. Analysts must not overstate the primitive: the attacker cannot silently replace an existing active TOTP seed; they can disable it, or enroll when none exists.

Impact Assessment

CVSS v3.1 base score: 6.5 (Medium) — CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N.

Subscore reading:

• AV:N (Network): the flaw is reachable over the network via the web interface.
• AC:L (Low): no special conditions or race timing are described; straightforward requests suffice.
• PR:L (Low): the attacker must be authenticated (session required). This is the dominant score limiter — the flaw cannot be reached anonymously.
• UI:N (None): no victim user interaction is required once the attacker holds the session and CSRF token.
• S:U (Unchanged): impact does not cross security authority boundaries beyond the affected account.
• C:N (None): no confidentiality impact is claimed by the vector — consistent with a control state change rather than data disclosure.
• I:H (High): the authentication process and the account's MFA state are fully modifiable — the core integrity failure.
• A:N (None): no availability impact is claimed.

Business impact. TOTP is frequently the last defense against credential-stuffing, password reuse, and phishing-captured passwords. An attacker who can disable or subvert it converts a protected account into a password-only account. For FileRise deployments — commonly self-hosted by teams storing documents, uploads, and batch-managed files — this raises the risk of unauthorized file access, data exfiltration, and tampering with stored content, particularly if the compromised account is an administrator.

Blast radius. Scoped to accounts whose sessions are controlled by the attacker. In multi-user FileRise instances, an admin session compromise cascades to all users and files that admin manages. Because the action is a persistent state change, the impact outlives the attacker's use of the session: the weakened/modified MFA posture remains until manually corrected.

Exploitability and threat context. EPSS is not yet scored by FIRST.org — no value is asserted here. CISA KEV: NO — no confirmed exploitation in the wild. No public PoC or exploit code is available. The vulnerability is rated medium and requires pre-existing authenticated access, which moderates immediate risk while leaving the integrity failure intact for any attacker who achieves session compromise. Patch confidence is 0/4 (UNPATCHED — no patch evidence from any tracked source), meaning no vendor fix or workaround evidence is currently captured by tracked sources, despite the NVD description citing version 3.23.0 as the fixed release.

Detection Guidance

Detection must focus on authenticated TOTP-configuration traffic and impossible or suspicious MFA-state transitions. Because endpoint identifiers are not disclosed, the rules below detect at the behavior/log level and are intentionally generic; tune field names to your FileRise deployment.

Sigma Rule

title: FileRise TOTP Disable or Enrollment Without Reauthentication (CVE-2026-104106)
id: 6bd5c2e9-1d47-4a3c-9a2f-filerise-totp-001
status: experimental
description: Detects TOTP disable or enrollment actions in FileRise that occur without a recent full reauthentication, consistent with CVE-2026-104106.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2026-104106
author: valtersit.com
date: 2026/01/01
tags:
  - attack.persistence
  - attack.defense_evasion
  - attack.t1556.006
logsource:
  product: filerise
  category: application
detection:
  selection_action:
    action|contains:
      - 'totp/disable'
      - 'totp/enroll'
      - 'mfa/disable'
      - 'mfa/enroll'
      - 'disable2fa'
      - 'enable2fa'
  selection_result:
    status:
      - 'success'
      - '200'
      - '204'
  filter_reauth:
    reauth_within_seconds|gte: 300
  condition: selection_action and selection_result and not filter_reauth
falsepositives:
  - Legitimate MFA changes immediately following a password re-prompt not captured in logs
level: high

YARA Rule

rule CVE_2026_104106_FileRise_TOTP_Preauth_Enroll
{
    meta:
        description = "Detects FileRise source/log artifacts referencing TOTP enrollment activated prior to possession verification (CVE-2026-104106)"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-104106"
        author = "valtersit.com"
        date = "2026-01-01"
        severity = "medium"
    strings:
        $app   = "FileRise" ascii nocase
        $a1    = "totp" ascii nocase
        $a2    = "enroll" ascii nocase
        $a3    = "secret" ascii nocase
        $b1    = "disable" ascii nocase
        $b2    = "csrftoken" ascii nocase
        $c1    = "409" ascii
    condition:
        $app and
        (2 of ($a*)) and
        (any of ($b*)) and
        $c1
}

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-104106 FileRise TOTP enroll/disable request (possible MFA modification)"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"totp"; nocase; http.uri; content:"enroll"; nocase; classtype:attempted-admin; reference:cve,CVE-2026-104106; sid:2026104106; rev:1;)

alert http any any -> any any (msg:"CVE-2026-104106 FileRise TOTP disable request (MFA removal)"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"totp"; nocase; http.uri; content:"disable"; nocase; classtype:attempted-admin; reference:cve,CVE-2026-104106; sid:2026104107; rev:1;)

Note: URI keywords above are illustrative of the functional area (TOTP enroll/disable) and are not disclosed endpoint paths. Validate and replace with observed deployment paths before production use.

Elastic Detection

sequence by user.name with maxspan=5m
  [ authentication where event.outcome == "success" ]
  [ any where event.category == "web"
      and event.action in ("totp_disable", "totp_enroll", "mfa_disable", "mfa_enroll")
      and event.outcome == "success" ]

Splunk SPL Query

index=web OR index=filerise
(uri_path="*totp*" OR uri_path="*mfa*" OR action IN ("totp_disable","totp_enroll","mfa_disable","mfa_enroll"))
status IN (200,204)
| eval reauth_recent=if(isnull(reauth_ts) OR (now()-reauth_ts)>300, "no", "yes")
| where reauth_recent="no"
| stats count min(_time) as first_seen max(_time) as last_seen values(uri_path) as paths values(status) as codes by src_ip, user, session_id
| where count >= 1
| sort - count

Wazuh OSSEC Rule

<group name="filerise,web,mfa,">
  <rule id="104106" level="10">
    <decoded_as>json</decoded_as>
    <field name="app">FileRise</field>
    <field name="action">totp_disable|totp_enroll|mfa_disable|mfa_enroll</field>
    <field name="status">200|204|success</field>
    <description>CVE-2026-104106: FileRise TOTP second-factor modification without recent reauthentication</description>
    <mitre>
      <id>T1556.006</id>
    </mitre>
    <group>authentication_change,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source). Although the NVD description states the issue is fixed in FileRise 3.23.0, no vendor advisory, commit reference, or release note is captured by tracked sources. Treat the environment as unpatched until you independently confirm 3.23.0 is available from the vendor and that its changelog addresses this CVE.

1) Immediate mitigations (until a verified fix is deployed):

• Enforce fresh reauthentication for MFA changes. Where FileRise or a fronting proxy allows it, require a recent full re-login (password and, where still enforced, existing TOTP) immediately before any TOTP enable/disable/enroll action. This directly counters the missing-reauth defect.
• Protect sessions. Because exploitation requires a valid session and CSRF token, harden session handling: short session timeouts, bind sessions to source IP/device where feasible, invalidate sessions on password change, and remove stale or shared sessions. Reducing session theft directly reduces exposure.
• Alert and audit. Turn on and centralize logs for all authentication and MFA-state changes. Treat any TOTP disable/enroll as a high-severity event requiring confirmation from the account owner (see Detection Guidance).
• Restrict exposure. Do not expose FileRise directly to the internet if avoidable; place it behind a VPN or zero-trust access proxy, and restrict administrative accounts to trusted networks.
• Manual MFA posture review. Periodically inventory which accounts have TOTP active versus disabled. Unexpected "TOTP disabled" or "TOTP re-enrolled" states are the strongest signal of exploitation.
• Backup credentials and recovery codes to enable safe re-enrollment after an incident.

2) Patch/upgrade steps:

• Upgrade to FileRise 3.23.0 or later, per the NVD description, once you have independently verified the release from the vendor's official distribution channel and confirmed the fix is present in that build.
• Verify the artifact (checksums/signatures) before deployment.
• After upgrade, re-validate TOTP behavior: confirm a fresh-authentication challenge is required for disable/enroll and that no secret is activated before possession is verified.
• Rotate all MFA seeds and session tokens for accounts that may have been exposed during the vulnerable window.

3) Long-term hardening:

• Architect MFA state changes as verified-possession-first workflows: never persist or activate a new secret before a submitted code confirms the requester holds it.
• Bind all security-relevant state changes (MFA, password, email, recovery) to a recent, explicit reauthentication event, independent of CSRF protection.
• Apply step-up authentication and change-confirmation notifications for sensitive account settings.
• Adopt MFA-with-recovery governance: log, alert, and require user or admin confirmation for every second-factor transition.
• Regularly review self-hosted software for CVEs; subscribe to the vendor's security channel and track NVD for FileRise.

References

1. NVD — CVE-2026-104106: https://nvd.nist.gov/vuln/detail/CVE-2026-104106
2. CWE-306 — Missing Authentication for Critical Function: https://cwe.mitre.org/data/definitions/306.html
3. MITRE ATT&CK T1556.006 — Modify Authentication Process: Multi-Factor Authentication: https://attack.mitre.org/techniques/T1556/006/
4. FileRise project (self-hosted web-based file manager) — official distribution/release channel: verify version 3.23.0 availability directly with the vendor.
5. CISA Known Exploited Vulnerabilities Catalog — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (CVE-2026-104106 not listed as of this report).

Threat actor / exploit-in-the-wild status: No public proof-of-concept, exploit code, or Nuclei template exists for CVE-2026-104106 as of this report. No threat-actor campaign or exploitation-in-the-wild evidence is associated with this CVE, and it is not listed in CISA KEV. EPSS has not yet been scored by FIRST.org. All exploit-chain content above is inferred from the disclosed behavior and CWE-306 class and must not be treated as observed activity.