Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "3.7",
  "pubDate": "2026-09-01T20:17:24.717Z",
  "pubdate": "2026-09-01T20:17:24.717Z",
  "executiveSummary": "A side-channel authentication oracle vulnerability exists within Filament's Login process, specifically affecting configurations where Multi-Factor Authentication (MFA) is active. The vulnerability stems from an improper sequence of operations within packages/panels/src/Auth/Pages/Login.php, where the MFA challenge is rendered prior to the validation of the canAccessPanel() authorization gate.\nThis flaw allows unauthenticated attackers to perform user enumeration and password validation. By observing the application's response to login attempts, an attacker can distinguish between incorrect passwords and valid passwords for accounts that are denied panel access. While this does not bypass authentication or establish a session, it facilitates brute-force or credential-stuffing attacks and potentially leads to unauthorized email/MFA traffic generation. The issue affects Filament versions 4.0.0 through 4.12.4 and 5.0.0 through 5.7.4. Remediation requires upgrading to the patched versions, 4.12.5 or 5.7.5, which ensure authorization checks precede MFA challenges.",
  "technicalDetails": "The root cause of this vulnerability lies in a logic error within the authentication flow of the Login class located at packages/panels/src/Auth/Pages/Login.php. In affected versions, the application executes the multi-factor authentication (MFA) challenge workflow before verifying if the authenticated subject possesses the required permissions via the canAccessPanel() function.\nThe attack flow follows a predictable pattern based on the server's response: 1. An attacker submits a set of credentials for a target account. 2. If the password is incorrect, the application returns a generic authentication failure. 3. If the password is correct, the application proceeds to render the MFA challenge interface. 4. If the account is configured with email-based MFA, the application proactively dispatches a login code to the legitimate user upon the successful validation of the password, even if the account is ultimately restricted by the canAccessPanel() gate.\nBecause the MFA challenge is rendered before the execution of the canAccessPanel() check, the application effectively acts as an authentication oracle. An unauthenticated attacker can confirm the validity of a password for any account that has MFA enabled but is denied access to the Filament panel. While the system correctly prevents session creation and does not authorize access to the panel, the disclosure of whether a password is valid provides a significant reconnaissance capability.\nThis vulnerability is restricted to accounts with MFA enabled and those that have been configured with restricted access via canAccessPanel(). The impact includes the ability for an attacker to verify password validity with high confidence, aiding in password spraying or credential stuffing campaigns. Furthermore, it results in the leaking of MFA tokens or unnecessary triggering of security notifications, which may be leveraged for social engineering or to harass account holders. The vulnerability is mitigated by enforcing the canAccessPanel() check as the primary guard condition before any secondary authentication procedures or MFA prompts are invoked. This ensures that unauthorized accounts receive the same failure response regardless of the password validity, maintaining the integrity of the authentication process."
}