CVE-2026-103977
Executive Summary
CVE-2026-103977 is an improper restriction of excessive authentication attempts (CWE-307) in FileRise, a self-hosted web-based file manager. Prior to version 3.23.0, the application tracked failed TOTP (time-based one-time password) verification attempts in the per-session $_SESSION store rather than a durable, account-wide counter. An attacker who already holds a target account's valid primary credential (username/password) can repeatedly restart the login workflow in fresh sessions, resetting the second-factor attempt allowance and enabling continued online TOTP guessing beyond the intended five-attempt limit. With a CVSS v3.1 base score of 8.1, successful exploitation results in high confidentiality and integrity impact to the targeted account, though availability is not affected.
This record — and 170,000+ others — are available via the ValtersIT API. One endpoint replaces five: NVD + GitHub CVE + CISA KEV + EPSS + Nuclei + Exploit-DB, unified.
No signup required
Technical Analysis
The vulnerability resides in FileRise's multi-factor authentication (MFA) login flow. Per the NVD description, "FileRise stores failed TOTP verification attempts in $_SESSION." PHP's $_SESSION is a per-session superglobal whose data is keyed to a client-side session identifier (typically a session cookie). Because the failed-attempt counter is scoped to the session rather than the account, its lifetime is bound to the session rather than to the authentication challenge itself.
The attack surface is the pending-login TOTP verification handler. Following successful validation of the primary credential (first factor), the application transitions to a pending-login state in which the user must supply a valid TOTP code to complete authentication. The intended control is a limit of five failed TOTP attempts. However, because the counter is stored in $_SESSION, an attacker can discard the current session (for example, by dropping the session cookie) and initiate a new login, which the application provisions as a fresh session with a reset attempt allowance. The description explicitly states: "The pending-login TOTP handlers did not share a durable account-wide limit." This design gap — a control scoped per-session instead of per-account — is the root cause.
Exploitation therefore does not require breaking the first factor; it requires possessing it. This lowers the effective security of the second factor from "something you have" to a rate-limited guessing problem against a typically six-digit numeric code. Without a durable account-wide throttle, the five-attempt ceiling becomes trivially bypassable by session churn, converting TOTP from a strong second factor into a weakness limited only by the attacker's request throughput and the TOTP time window.
The CVSS vector reflects this: network attack vector (AV:N), low attack complexity (AC:L), low privileges required (PR:L, reflecting possession of a valid primary credential), no user interaction (UI:N), unchanged scope (S:U), with high confidentiality (C:H) and high integrity (I:H) impact and no availability impact (A:N). Note that no public proof-of-concept, exploit code, or Nuclei template was identified for this CVE, and no EPSS score has been assigned by FIRST.org.
Exploitation Scenarios
The following attack chain is derived strictly from the NVD description. No public PoC exists; the sequence below is inferred from the vulnerability class (CWE-307) and the described mechanism.
Reconnaissance / target identification. The attacker identifies an internet- or intranet-exposed FileRise instance (self-hosted file manager, versions prior to 3.23.0). Because FileRise is self-hosted, exposed instances are discovered via web-scanning and service fingerprinting rather than a SaaS platform.
First-factor acquisition (precondition). The attacker must already possess a target account's valid primary credential. This could result from credential stuffing, password reuse, phishing, or prior breach data. This precondition is reflected in the PR:L metric of the CVSS vector. No exploitation is possible without it.
Triggering the vulnerable flow. Using the valid primary credential, the attacker authenticates and reaches the pending-login TOTP verification step. The application presents a TOTP challenge and begins tracking failed attempts in the session.
Session churn to bypass the attempt limit. Instead of exhausting the five allowed attempts, the attacker restarts the login workflow in a new session (for example, by discarding the current session identifier and re-authenticating). Because the failed-attempt count is stored per-session in
$_SESSIONand is not shared account-wide, the new session starts with a fresh allowance. The attacker repeats this cycle across many sessions, obtaining effectively unlimited TOTP guesses.Post-exploitation impact. Once a valid TOTP code is guessed within the current time window, the attacker completes authentication and gains full access to the victim's FileRise account. Given FileRise's role as a file manager with multi-file upload, editing, and batch operations, this yields high confidentiality and integrity impact: the attacker can read, modify, upload, and delete the victim's files. Availability is not directly impacted per the CVSS vector, though destructive batch operations remain possible.
Impact Assessment
Successful exploitation requires a valid primary credential, but defeats the second factor intended to protect the account. Per the CVSS v3.1 vector (8.1, High), impact is high to confidentiality and integrity, with no availability impact. Affected systems are self-hosted FileRise deployments prior to version 3.23.0 that have TOTP-based MFA enabled. Because FileRise is a file manager with multi-file upload, editing, and batch operations, a compromised account can expose, tamper with, or exfiltrate stored data. The blast radius is limited to accounts whose primary credentials the attacker already holds, but any such account with MFA enabled is at elevated risk because its second factor provides materially less protection than intended. Organizations relying on TOTP as a compensating control for high-value file repositories should treat this as a meaningful weakening of their MFA posture.
Detection Guidance
Sigma Rule
title: FileRise Repeated TOTP Verification Failures Across Sessions
id: 6f1a2c9e-8b3d-4e57-9c2a-filerise103977
status: experimental
description: Detects repeated failed TOTP verification attempts against FileRise accounts, especially across multiple sessions indicating attempt-limit reset abuse (CVE-2026-103977, CWE-307).
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-103977
author: valtersit.com
date: 2026/01/01
logsource:
category: application
product: filerise
detection:
selection_action:
event:
- 'totp_verification_failed'
- 'pending_login_totp_failed'
- 'totp_failed'
timeframe: 15m
condition: selection_action | count() by src_ip, user > 5
fields:
- src_ip
- user
- session_id
level: high
tags:
- attack.credential_access
- attack.t1110
YARA Rule
rule CVE_2026_103977_FileRise_TOTP_Session_Counter
{
meta:
author = "valtersit.com"
description = "Detects FileRise handlers that track TOTP attempts in $_SESSION rather than a durable account-wide counter (CVE-2026-103977)"
reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-103977"
date = "2026-01-01"
strings:
$s1 = "$_SESSION" ascii
$s2 = "totp" ascii nocase
$s3 = "attempt" ascii nocase
condition:
all of them
}
Suricata IDS Rule
alert http any any -> any any (msg:"CVE-2026-103977 FileRise TOTP Attempt-Limit Reset Abuse"; flow:established,to_server; http.method; content:"POST"; http.uri; content:"login"; nocase; http.cookie; content:"PHPSESSID"; nocase; threshold:type both, track by_src, count 10, seconds 60; classtype:attempted-user; reference:cve,2026-103977; sid:2026103977; rev:1;)
Elastic Detection
sequence by source.ip with maxspan=15m
[any where event.action == "totp_verification_failed"]
[any where event.action == "totp_verification_failed"]
[any where event.action == "totp_verification_failed"]
[any where event.action == "totp_verification_failed"]
[any where event.action == "totp_verification_failed"]
[any where event.action == "totp_verification_failed"]
Splunk SPL Query
index=web sourcetype=filerise (event=totp_verification_failed OR event=totp_failed OR message="*TOTP*fail*")
| stats count as failures, dc(session_id) as sessions by src_ip, user
| where failures > 5 AND sessions > 1
| sort - failures
Wazuh OSSEC Rule
<group name="web,filerise,">
<rule id="103977" level="12" frequency="6" timeframe="900">
<if_matched_sid>103976</if_matched_sid>
<same_source_ip />
<description>FileRise: multiple failed TOTP verifications across sessions - possible CVE-2026-103977 attempt-limit reset abuse</description>
<mitre>
<id>T1110</id>
</mitre>
</rule>
<rule id="103976" level="4">
<decoded_as>json</decoded_as>
<field name="event">totp_verification_failed</field>
<description>FileRise: TOTP verification failed</description>
</rule>
</group>
Mitigation & Patch Guidance
Patch confidence: 0/4 (UNPATCHED — no patch evidence from any tracked source).
Immediate mitigations. Because the failed-attempt counter is stored per-session in
$_SESSION, mitigate by enforcing rate limiting and account lockout at a layer outside the application session — for example, at the reverse proxy or WAF, throttle requests to the pending-login TOTP verification endpoint by source IP and by authenticated account. Restrict FileRise exposure to trusted networks or place it behind a VPN until a fix is applied. Consider monitoring for a high volume of TOTP failures across many distinct sessions for the same account as a compensating detective control.Patch / upgrade steps. The NVD description states the issue "is fixed in version 3.23.0." Upgrade FileRise to version 3.23.0 or later. No patch evidence was available from tracked sources at the time of writing, so verify the fix directly with the vendor and confirm the deployed version in your environment. No workaround was documented by the CNA.
Long-term hardening. Require unique, strong primary credentials and enforce MFA on all file-management accounts to reduce the likelihood that an attacker can obtain the first factor. Implement account-wide (not session-scoped) attempt counters for all authentication and step-up verification flows. Prefer phishing-resistant second factors (for example, hardware security keys) that are not vulnerable to code guessing. Centralize authentication logging so that attempt-limit resets and cross-session failure patterns are detectable.
References
- NVD — CVE-2026-103977: https://nvd.nist.gov/vuln/detail/CVE-2026-103977
- CWE-307 — Improper Restriction of Excessive Authentication Attempts: https://cwe.mitre.org/data/definitions/307.html
- MITRE ATT&CK T1110 — Brute Force: https://attack.mitre.org/techniques/T1110/
- FileRise project (self-hosted web-based file manager) — vendor source and release notes for version 3.23.0
- No CISA KEV entry, public PoC, exploit code, or Nuclei template was identified for this CVE; no EPSS score has been assigned by FIRST.org. No known threat actor campaigns or exploit-in-the-wild evidence are available at the time of writing.
What is this? Security researchers use these exact search queries on Shodan.io (a search engine for internet-connected devices) to find vulnerable systems globally. You can copy these dorks to see if your organization's IP space is exposed.