Filament CVE-2026-104181

Requires an already-authenticated Filament user session - the attacker must have hijacked a session cookie, be using an unlocked/shared authenticated browser, or be a malicious insider; there is no path to unauthenticated sign-in via this flaw. The attacker must also be able to supply an existing valid app TOTP code or an existing recovery code to complete the MFA management action. Scope is limited to APP-based MFA management (set-up, disable, regenerate recovery codes) in Filament 4.0.0 through < 4.13.3 and the 5.x line before 5.8.3; email-based MFA is explicitly NOT affected. The principal limiting factor is the required authenticated session, which bounds real-world impact to account-takeover-amplification and victim lockout rather than initial access.

This is a genuinely moderate-risk issue that correctly lands in the medium band rather than being inflated by a high headline number. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L, base 5.4) is internally consistent with the description: PR:L reflects the hard prerequisite that the attacker already holds an authenticated user session, and the impact is limited to Integrity (altering MFA configuration) and Availability (locking the legitimate user out), with no confidentiality breach (C:N). CWE-306 (Missing Authentication for Critical Function) accurately captures the root cause - the app-MFA management actions do not re-verify the current password. No EPSS score was provided, there is no CISA KEV listing, and no public exploit code was supplied - only the vendor patch (PR #20522) and advisory, so exploitation status is 'no public exploit identified at time of analysis.' The absence of KEV/EPSS signals combined with the mandatory pre-existing authenticated session strongly indicates this is a defense-in-depth / step-up-authentication weakness rather than an internet-facing mass-exploitation threat. One nuance to verify: the EUVD affected-version ranges (< 5.8.2 and < 4.13.2) are off-by-one from the description's stated fixed versions (5.8.3 and 4.13.3) - treat 4.13.3 and 5.8.3 as the confirmed patched releases.

An attacker who has obtained a victim's authenticated Filament session (for example via a hijacked/stolen session cookie, an unlocked shared workstation, or a malicious insider) navigates to the app-based MFA management actions. Because the current password is not consistently required, the attacker supplies an existing app code or recovery code to disable or reconfigure app-MFA, harvest recovery codes, or regenerate them - all without knowing the account password, potentially locking the legitimate user out. No public proof-of-concept was provided; the vendor fix (PR #20522) adds the missing current-password field to the set-up, disable, and regenerate-recovery-codes forms.