Filament EUVD-2026-65118

Exploitation requires three concurrent conditions: (1) the attacker must possess valid first-factor credentials (username and password) for a target Filament panel account - MFA bypass is not reachable without passing the password step; (2) the targeted account must have app-based (TOTP authenticator app) MFA enabled, not email-based MFA; and (3) recovery codes must be enabled on that account. If recovery codes are disabled, the isRecoverable flag is false and the vulnerability logic does not produce the unsafe state. The exploit is further limited to Filament panel instances running versions prior to 4.12.0 or 5.7.0. What limits exploitation: the credential prerequisite means mass unauthenticated exploitation is not possible; targeted attacks against known users with known passwords are the realistic threat model.

The provided CVSS 8.1 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N) is well-calibrated. PR:L correctly reflects that exploitation requires the attacker to first possess the target user's primary credentials (password) to reach the MFA challenge - this is a second-factor bypass, not a full unauthenticated takeover. Attack complexity is genuinely Low: triggering the bypass requires only toggling a UI toggle and submitting a form with blank fields, requiring no special tooling. The C:H/I:H combination reflects full account compromise once MFA is bypassed. Real-world risk is meaningfully bounded by two conditions that must both hold: the attacker must already have the target's password, and the target account must have app-based MFA with recovery codes enabled. Applications relying on MFA as a compensating control for credential-stuffing or phishing scenarios are most exposed. No EPSS data was provided; no KEV listing exists, suggesting exploitation has not been confirmed at scale. The straightforward nature of the logic flaw means practical exploit construction requires minimal skill.

An attacker who has obtained a target user's Filament panel credentials through phishing or credential stuffing navigates to the panel login, enters the credentials, and is presented with the app-based MFA challenge. The attacker clicks the 'use recovery code' toggle to switch the form to recovery code mode, then submits the form with both the TOTP code field and recovery code field left completely blank. Because the required-field validation is incorrectly computed, the form passes server-side validation and the attacker is granted full session access to the panel. No public exploit code has been identified, but the bypass is mechanically trivial to reproduce from the commit diff.