CVE-2026-84307: MFA prompt leaks valid password

CISO Take

Filament's admin panel login flow evaluates multi-factor authentication before it checks whether the account is actually allowed into the panel, so an unauthenticated attacker who submits a correct password for a denied account sees the MFA challenge rendered while a wrong password returns a generic failure — turning the login form into a password-validity oracle, and in email-MFA setups it also fires a real login code to the account holder. This is not an authentication bypass (canAccessPanel() still gates session creation) and CVSS is low (3.7, AC:H) because it only affects accounts that have MFA enabled and are simultaneously denied panel access, with no public exploit code, no Nuclei template, and no CISA KEV listing. The AI/ML relevance here is indirect: this is a Laravel admin-panel framework, not an AI component, so treat it as infrastructure hygiene for any team running Filament to administer AI/ML platforms, MLOps dashboards, or model-serving control planes rather than as an AI-specific threat. Action: upgrade to Filament 4.12.5 or 5.7.5, and if immediate patching isn't possible, monitor for repeated login attempts against MFA-enabled-but-denied accounts and treat unexpected MFA emails as a signal of password-guessing activity.

Sources: NVD GitHub Advisory

What is the risk?

Low severity (CVSS 3.7, AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N). Confidentiality impact is limited to confirming password validity for a narrow subset of accounts (MFA-enabled AND denied panel access) — no session is created and no data beyond a binary password-correct/incorrect signal is exposed. Attack complexity is rated high because the attacker needs prior knowledge of which accounts meet both preconditions. No public exploit, scanner template, or KEV listing exists, and EPSS data is unavailable, consistent with a low-priority, non-urgent finding. The email-MFA side effect (sending a real login code on a correct-password guess) adds minor nuisance/social-engineering risk but does not change the overall low risk rating.

How does the attack unfold?

Credential list acquisition

Attacker obtains candidate email/password pairs from a breach dump or credential-stuffing list targeting the organization's Filament-based admin panel.

Password oracle probing

Attacker submits each candidate password on the login form; a rendered MFA challenge confirms the password is correct for that account, while a generic failure confirms it is wrong.

Credential validation and reuse

Attacker compiles a list of confirmed-valid passwords without ever gaining panel access, then attempts credential reuse against other systems or awaits a future MFA/session flaw to escalate.

Credential list acquisition

Attacker obtains candidate email/password pairs from a breach dump or credential-stuffing list targeting the organization's Filament-based admin panel.

Password oracle probing

Attacker submits each candidate password on the login form; a rendered MFA challenge confirms the password is correct for that account, while a generic failure confirms it is wrong.

Credential validation and reuse

Attacker compiles a list of confirmed-valid passwords without ever gaining panel access, then attempts credential reuse against other systems or awaits a future MFA/session flaw to escalate.

How severe is it?

CVSS 3.1

3.7 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AV Network

AC High

PR None

UI None

S Unchanged

C Low

I None

A None

What should I do?

1 step

Upgrade Filament to 4.12.5 (4.x line) or 5.7.5 (5.x line), where canAccessPanel() is evaluated before the MFA challenge is rendered. If immediate patching isn't feasible, consider rate-limiting and monitoring login attempts on Filament-based admin panels, especially repeated attempts against accounts known to be denied panel access. Audit which accounts have MFA enabled but lack canAccessPanel() authorization — these are the only accounts exposed to this oracle — and consider removing MFA configuration from accounts that shouldn't have panel access at all. Watch for unexpected email-MFA codes sent to account holders as a signal of active password-guessing attempts. Apply this patch as part of routine dependency hygiene for any admin dashboard fronting AI/ML infrastructure.

How is it classified?

Auth Bypass Data Leakage Framework

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.9 - Information security controls for AI systems

NIST AI RMF

GOVERN-4.1 - Organizational policies address AI risk arising from third-party software and infrastructure

Frequently Asked Questions

What is CVE-2026-84307?

Filament's admin panel login flow evaluates multi-factor authentication before it checks whether the account is actually allowed into the panel, so an unauthenticated attacker who submits a correct password for a denied account sees the MFA challenge rendered while a wrong password returns a generic failure — turning the login form into a password-validity oracle, and in email-MFA setups it also fires a real login code to the account holder. This is not an authentication bypass (canAccessPanel() still gates session creation) and CVSS is low (3.7, AC:H) because it only affects accounts that have MFA enabled and are simultaneously denied panel access, with no public exploit code, no Nuclei template, and no CISA KEV listing. The AI/ML relevance here is indirect: this is a Laravel admin-panel framework, not an AI component, so treat it as infrastructure hygiene for any team running Filament to administer AI/ML platforms, MLOps dashboards, or model-serving control planes rather than as an AI-specific threat. Action: upgrade to Filament 4.12.5 or 5.7.5, and if immediate patching isn't possible, monitor for repeated login attempts against MFA-enabled-but-denied accounts and treat unexpected MFA emails as a signal of password-guessing activity.

Is CVE-2026-84307 actively exploited?

No confirmed active exploitation of CVE-2026-84307 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-84307?

Upgrade Filament to 4.12.5 (4.x line) or 5.7.5 (5.x line), where canAccessPanel() is evaluated before the MFA challenge is rendered. If immediate patching isn't feasible, consider rate-limiting and monitoring login attempts on Filament-based admin panels, especially repeated attempts against accounts known to be denied panel access. Audit which accounts have MFA enabled but lack canAccessPanel() authorization — these are the only accounts exposed to this oracle — and consider removing MFA configuration from accounts that shouldn't have panel access at all. Watch for unexpected email-MFA codes sent to account holders as a signal of active password-guessing attempts. Apply this patch as part of routine dependency hygiene for any admin dashboard fronting AI/ML infrastructure.

What systems are affected by CVE-2026-84307?

This vulnerability affects the following AI/ML architecture patterns: AI/ML admin dashboards built on Filament, MLOps control-plane UIs, model-serving/administration consoles.

What is the CVSS score for CVE-2026-84307?

CVE-2026-84307 has a CVSS v3.1 base score of 3.7 (LOW).

What is the AI security impact?

Affected AI Architectures

AI/ML admin dashboards built on FilamentMLOps control-plane UIsmodel-serving/administration consoles

Compliance Controls Affected

ISO 42001: A.9

NIST AI RMF: GOVERN-4.1

What are the technical details?

Original Advisory

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.

Exploitation Scenario

An attacker has obtained a list of candidate email/password pairs for a Filament-based admin panel that fronts an organization's internal AI/ML platform (e.g., a model registry or MLOps console), sourced from a prior breach or credential-stuffing list. For each candidate account that is known or suspected to have MFA enabled but restricted panel access (e.g., a service account or ex-employee account), the attacker submits the login form: if the response renders the MFA challenge page, the password is confirmed valid; if it returns the generic auth failure, the password is wrong. Over many attempts, the attacker builds a validated-credentials list without ever gaining panel access, which they can later attempt to reuse against other systems (password reuse) or pair with a future MFA-bypass or session-fixation flaw to escalate into the AI admin console.

Weaknesses (CWE)

CWE-204 Observable Response Discrepancy Primary

CWE-204 — Observable Response Discrepancy: The product provides different responses to incoming requests in a way that reveals internal state information to an unauthorized actor outside of the intended control sphere.

[Architecture and Design] Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
[Implementation] Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended). The messages should not reveal the methods that were used to determine the error. Attackers can use detailed information to refine or optimize their original attack, thereby increasing their chances of success. If errors must be captured in some detail, record them in log messages, but consider what could occur if the log messages can be viewed by attackers. Highly sensitive information such as passwords should never be saved to log files. Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.

Source: MITRE CWE corpus.