CVE-2026-84307 in filament
Summary
by MITRE • 09/01/2026
Filament is a collection of full-stack components for accelerated Laravel development. From 4.0.0 until 4.12.5 and 5.7.5, packages/panels/src/Auth/Pages/Login.php presents the multi-factor authentication challenge before evaluating canAccessPanel(). For an account that canAccessPanel() denies, submitting the correct password renders the MFA challenge while an incorrect password returns the generic authentication failure, allowing an unauthenticated attacker to confirm whether a candidate password is valid for that account. When email-based MFA is configured, the correct-password path also sends a login code to the account holder. The issue applies only to accounts that have MFA enabled and are denied panel access. Authentication is not bypassed because canAccessPanel() still runs after the challenge, and no session is created. This issue is fixed in versions 4.12.5 and 5.7.5.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/01/2026
The vulnerability identified within Filament panels prior to version 4.12.5 and 5.7.5 represents a significant information disclosure flaw rooted in the authentication flow logic, specifically affecting accounts that have multi-factor authentication enabled but are denied access via custom authorization rules. The core technical issue lies in the execution order of security checks during the login process. In the affected versions, the system initiates the multi-factor authentication challenge before evaluating whether the user is permitted to access the panel through the canAccessPanel() method. This inversion of priority creates a side-channel that allows an unauthenticated attacker to perform username enumeration and password validation against specific target accounts.
When an attacker submits credentials for an account with MFA enabled, the application's behavior diverges based on the validity of the provided password rather than the authorization status of the user. If the submitted password is incorrect, the system returns a generic authentication failure message, which does not reveal whether the username exists or if the password was close to being correct. However, if the attacker submits the correct password for such an account, the application proceeds to trigger the MFA challenge and, in cases where email-based multi-factor authentication is configured, sends a login code to the associated email address. This distinct behavioral difference allows an observer to confirm with high certainty that they have guessed the correct password for a valid user account who has MFA enabled but lacks panel access permissions.
This behavior facilitates targeted brute-force attacks and credential stuffing campaigns against specific users. An attacker can iteratively test passwords, using the presence of an MFA challenge or the receipt of an email code as a positive signal that the current guess is correct for that username. This effectively bypasses rate-limiting protections designed to prevent password guessing because the feedback mechanism provides clear confirmation upon success without requiring further interaction with the system's primary authorization logic. The vulnerability exploits the principle of least privilege failure by leaking information about account validity and credential correctness through operational side effects rather than direct error messages, which aligns with CWE-203: Observable Discrepancy and CWE-284: Improper Access Control.
From a threat intelligence perspective, this flaw can be mapped to the ATT&CK technique T1110.001: Brute Force: Password Guessing, as it aids in validating credentials during automated attacks. It also relates to T1078: Valid Accounts, specifically regarding the enumeration of valid usernames and passwords through differential responses. Although the vulnerability does not result in a direct authentication bypass or session creation for unauthorized users, it significantly lowers the barrier for attackers aiming to compromise high-value accounts that are protected by multi-factor authentication but restricted from panel access via custom policies.
The operational impact is primarily centered on credential validation efficiency for attackers and potential privacy violations through email notification leakage. For organizations relying on Filament panels with strict role-based or policy-based access controls, this flaw undermines the security posture of user accounts that have MFA enabled. Even though these users cannot log in to the panel due to authorization denials, their account existence and password strength can be verified by external actors. This information is valuable for subsequent attack phases such as phishing campaigns tailored to specific individuals or further exploitation attempts if other services reuse credentials.
Mitigation strategies require immediate upgrading of the Filament framework to version 4.12.5 or later, where the authentication flow has been corrected to evaluate access permissions before initiating multi-factor challenges. For environments that cannot immediately upgrade, administrators should review custom authorization policies and consider implementing uniform error responses for all failed login attempts regardless of MFA status or password correctness. Additionally, monitoring for unusual patterns in email delivery logs can help detect ongoing enumeration attacks targeting accounts with enabled multi-factor authentication. Ensuring that the application logic strictly adheres to a sequence where access control checks precede any user-specific feedback mechanisms is critical to preventing similar information disclosure vulnerabilities in future development cycles.