CVE-2026-84306: stale TOTP code stays valid,

CISO Take

This is an MFA replay flaw in Filament, a widely used Laravel admin-panel toolkit: the used-code cache that should block TOTP code reuse is keyed by the submitted code rather than by the account's MFA secret, so an old app-based MFA code remains valid for the rest of its roughly four-minute window even after the legitimate user has already logged in with a newer code. Exploitation requires the attacker to already hold the victim's password plus one previously-issued TOTP code, which is a moderate bar reflected in the CVSS vector (6.5, AC:H); there is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template, so this is not an actively exploited or trivially weaponizable bug today. Filament itself is not an AI/ML package, but any AI ops, MLOps, or LLM-gateway admin console built on Filament (model registries, feature stores, internal compliance dashboards) inherits this weakness, narrowing the practical value of app-based MFA as a control on those consoles during the reuse window. Patch to Filament 4.12.6 or 5.7.6 now; if immediate patching isn't possible, monitor for repeated successful app-MFA logins to the same account within one TOTP time-step and treat any password-plus-MFA-code phishing hit against a Filament-backed console as a credential-compromise event requiring forced re-authentication.

Sources: NVD GitHub Advisory

What is the risk?

Medium risk overall. Confidentiality impact is high (full account takeover of the affected panel identity) but integrity impact is only low and availability is unaffected, consistent with the 6.5 CVSS score. Attack complexity is high because the attacker needs two independent prior compromises — the account password AND a valid app-based TOTP code from the same time window — not just one factor. There's no evidence of active exploitation (not in CISA KEV, no EPSS score published, no public PoC or Nuclei template), and the exposure window is narrow (~4 minutes with default TOTP settings). The realistic risk driver is less "this will be mass-exploited" and more "this quietly degrades MFA's guarantee" for any organization already dealing with credential-phishing campaigns that harvest both password and OTP in real time (e.g., adversary-in-the-middle phishing kits).

How does the attack unfold?

Credential & OTP theft

Attacker obtains the victim's Filament panel password and one valid app-based TOTP code, e.g. via real-time phishing or malware.

Replay within window

Attacker submits the stolen password and the stale TOTP code; because the used-code cache key is derived from the code itself rather than the account secret, the code is still accepted even though a newer code has since been used.

Account takeover

Attacker gains an authenticated session on the Filament panel, obtaining whatever access the victim's account holds for up to the remainder of the ~4-minute TOTP window.

Credential & OTP theft

Attacker obtains the victim's Filament panel password and one valid app-based TOTP code, e.g. via real-time phishing or malware.

Replay within window

Attacker submits the stolen password and the stale TOTP code; because the used-code cache key is derived from the code itself rather than the account secret, the code is still accepted even though a newer code has since been used.

Account takeover

Attacker gains an authenticated session on the Filament panel, obtaining whatever access the victim's account holds for up to the remainder of the ~4-minute TOTP window.

How severe is it?

CVSS 3.1

6.5 / 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 High

I Low

A None

What should I do?

1 step

1) Upgrade Filament to 4.12.6 (4.x branch) or 5.7.6 (5.x branch) — the fix changes the used-code cache key to be scoped by the app-authentication secret instead of the submitted code. 2) If immediate patching isn't feasible, reduce the app-MFA acceptance window in configuration where supported, and consider temporarily prioritizing email-based MFA (unaffected) for high-privilege accounts. 3) Detection: audit authentication logs for cases where a single account authenticates successfully via app-based MFA more than once within the same ~4-minute TOTP window, or from materially different IPs/devices/user-agents in quick succession — this pattern is the signature of this replay. 4) For accounts with elevated privileges on Filament-backed admin panels (including any managing AI/ML infrastructure), force password + MFA secret reset after upgrading, since a code observed pre-patch could theoretically have been captured and cached for reuse right up to the deployment moment.

How is it classified?

Auth Bypass Framework

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001

A.6.2.2 - Access controls for AI system components

Frequently Asked Questions

What is CVE-2026-84306?

This is an MFA replay flaw in Filament, a widely used Laravel admin-panel toolkit: the used-code cache that should block TOTP code reuse is keyed by the submitted code rather than by the account's MFA secret, so an old app-based MFA code remains valid for the rest of its roughly four-minute window even after the legitimate user has already logged in with a newer code. Exploitation requires the attacker to already hold the victim's password plus one previously-issued TOTP code, which is a moderate bar reflected in the CVSS vector (6.5, AC:H); there is no CISA KEV listing, no EPSS score, and no public exploit or Nuclei template, so this is not an actively exploited or trivially weaponizable bug today. Filament itself is not an AI/ML package, but any AI ops, MLOps, or LLM-gateway admin console built on Filament (model registries, feature stores, internal compliance dashboards) inherits this weakness, narrowing the practical value of app-based MFA as a control on those consoles during the reuse window. Patch to Filament 4.12.6 or 5.7.6 now; if immediate patching isn't possible, monitor for repeated successful app-MFA logins to the same account within one TOTP time-step and treat any password-plus-MFA-code phishing hit against a Filament-backed console as a credential-compromise event requiring forced re-authentication.

Is CVE-2026-84306 actively exploited?

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

How to fix CVE-2026-84306?

1) Upgrade Filament to 4.12.6 (4.x branch) or 5.7.6 (5.x branch) — the fix changes the used-code cache key to be scoped by the app-authentication secret instead of the submitted code. 2) If immediate patching isn't feasible, reduce the app-MFA acceptance window in configuration where supported, and consider temporarily prioritizing email-based MFA (unaffected) for high-privilege accounts. 3) Detection: audit authentication logs for cases where a single account authenticates successfully via app-based MFA more than once within the same ~4-minute TOTP window, or from materially different IPs/devices/user-agents in quick succession — this pattern is the signature of this replay. 4) For accounts with elevated privileges on Filament-backed admin panels (including any managing AI/ML infrastructure), force password + MFA secret reset after upgrading, since a code observed pre-patch could theoretically have been captured and cached for reuse right up to the deployment moment.

What systems are affected by CVE-2026-84306?

This vulnerability affects the following AI/ML architecture patterns: Admin/management consoles for AI platforms (MLOps dashboards, model registries, LLM-gateway config panels) when built on Filament.

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

CVE-2026-84306 has a CVSS v3.1 base score of 6.5 (MEDIUM).

What is the AI security impact?

Affected AI Architectures

Admin/management consoles for AI platforms (MLOps dashboards, model registries, LLM-gateway config panels) when built on Filament

Compliance Controls Affected

ISO 42001: A.6.2.2

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.6 and 5.7.6, packages/panels/src/Auth/MultiFactor/App/AppAuthentication.php uses AppAuthentication::verifyCode() with a used-code cache key derived from both the app authentication secret and the submitted TOTP code. This isolates the newest accepted timestep by code instead of by secret, allowing a previously issued app-based MFA code to be accepted after a newer code has already been used. Reuse of the exact same code was already prevented, but another code inside the accepted time window remained usable. An attacker who obtains the target account's password and one app-based MFA code can use that code for the remainder of the configured window, which is approximately four minutes with the default settings, even after the legitimate account holder logs in with a newer code. Email-based MFA is not affected. This issue is fixed in versions 4.12.6 and 5.7.6.

Exploitation Scenario

An attacker phishes or otherwise obtains a target admin's Filament panel password along with a single app-based TOTP code (for example, via a real-time adversary-in-the-middle phishing page that relays the OTP as the victim enters it, or by shoulder-surfing/malware capturing one code). Even if the legitimate admin subsequently logs in normally with a fresh TOTP code, the attacker can still submit the earlier code within its ~4-minute validity window because the used-code cache tracked the specific code value, not the account's MFA secret — so the "already used" check never fires for a different, still-time-valid code. The attacker authenticates as the admin and gains full access to the panel, which — if it fronts an AI/ML admin surface such as a model registry, MLOps dashboard, or compliance evidence store — hands them the ability to view, alter, or exfiltrate whatever that console manages within the attacker's session.

Weaknesses (CWE)

CWE-294 Authentication Bypass by Capture-replay Primary

CWE-294 — Authentication Bypass by Capture-replay: A capture-replay flaw exists when the design of the product makes it possible for a malicious user to sniff network traffic and bypass authentication by replaying it to the server in question to the same effect as the original message (or with minor changes).

[Architecture and Design] Utilize some sequence or time stamping functionality along with a checksum which takes this into account in order to ensure that messages can be parsed only once.
[Architecture and Design] Since any attacker who can listen to traffic can see sequence numbers, it is necessary to sign messages with some kind of cryptography to ensure that sequence numbers are not simply doctored along with content.

Source: MITRE CWE corpus.