CVE-2026-84306: Multi-Factor Authentication Bypass via Replay Attack in Filament

Filament is an administrative panel and full-stack rapid development framework built on top of Laravel. Within its core architecture, Filament provides built-in support for Multi-Factor Authentication (MFA), including Time-Based One-Time Passwords (TOTP) conforming to RFC 6238. This capability is used to secure high-privilege access to admin panels and backend management consoles, exposing an administrative attack surface to malicious actors.

A vulnerability designated as CVE-2026-84306 (GHSA-r3j6-gpjw-qfjr) was identified in the MFA verification logic of Filament. The software failed to enforce strict monotonic progression of the TOTP time-steps. As a result, older, unused TOTP codes within the accepted time-drift window could be successfully replayed even after a newer TOTP code had already been verified and processed.

This flaw belongs to the class of CWE-294 (Authentication Bypass by Capture-replay). By exploiting this vulnerability, an attacker who has already acquired a target user's primary credentials can bypass the secondary MFA challenge, gaining unauthorized administrative access to the application panel.

The security flaw resides in the packages/panels/src/Auth/MultiFactor/App/AppAuthentication.php component, specifically within the verifyCode method. According to the RFC 6238 specifications, once a TOTP code corresponding to a specific timestep is verified and accepted, the server must invalidate that entire timestep and all previous timesteps. This behavior ensures that the authentication state progresses strictly forward, preventing the validation of any older codes, even if those codes still fall within the configured clock drift window (typically around 4 minutes to accommodate network latency and client desynchronization).

In vulnerable versions of Filament, the code-tracking mechanism maintained state on a per-code basis rather than a per-secret basis. The application generated a unique cache key for each verification attempt using the following schema:

$cacheKey = 'filament.app_authentication_codes.' . md5($secret . $code);

Because the cache key incorporated both the user's multi-factor secret and the specific 6-digit verification code string submitted, each unique code generated its own distinct cache entry. While a user could not reuse the exact same 6-digit code within its active validity lifespan, the server treated any other valid code from a different timestep within the allowed clock drift window as entirely separate and untracked. Consequently, if a user logged in with a code from timestep T, an attacker possessing an unused code from timestep T-1 could submit it, bypass the tracking check, and successfully authenticate.

Analyzing the patch applied to packages/panels/src/Auth/MultiFactor/App/AppAuthentication.php reveals how the flaw was remedied. The tracking mechanism was modified to monitor the timestamp of the last validated code globally for each secret rather than monitoring individual 6-digit code strings.

Vulnerable Code Pattern

Before the patch, the verifyCode method tracked code reuse by incorporating the submitted code into the MD5 hash:

$cacheKey = 'filament.app_authentication_codes.' . md5($secret . $code);
$timestamp = $this->google2FA->verifyKeyNewer($secret, $code, cache()->get($cacheKey), $this->getCodeWindow());

Because each individual code generated a separate cache key, the underlying library's verifyKeyNewer function compared the current code's timestep against an empty or non-existent cached timestamp, allowing older but still mathematically valid codes to pass verification.

Patched Code Pattern

In the patched implementation, the cache key is generated using only the multi-factor secret, ensuring a single centralized record of the last authenticated timestamp per user:

$cacheKey = 'filament.app_authentication_codes.' . md5($secret);
 
$verifyCode = function () use ($cacheKey, $code, $secret): bool {
    // Retrieve the last used timestamp globally for this secret
    $timestamp = $this->google2FA->verifyKeyNewer($secret, $code, Cache::get($cacheKey), $this->getCodeWindow());
 
    if ($timestamp === false) {
        return false;
    }
 
    if ($timestamp === true) {
        $timestamp = $this->google2FA->getTimestamp();
    }
 
    // Save the timestamp of the verified code back into the cache
    Cache::put($cacheKey, $timestamp, ($this->getCodeWindow() + 1) * 60);
 
    return true;
};

Additionally, the patch implements a critical optimization using cache locks to block race conditions where an attacker could execute parallel, concurrent verification requests:

if (! (Cache::getStore() instanceof LockProvider)) {
    return $verifyCode();
}
 
return Cache::lock("{$cacheKey}.lock", 10)->block(10, $verifyCode);

This implementation ensures that concurrent operations must wait for the preceding validation to commit its state to the cache, eliminating race-condition windows.

An attack targeting this vulnerability is classified as highly complex because it requires a specific set of pre-existing conditions and access rights. An attacker cannot exploit this flaw to compromise an account unless they have already obtained the target user's primary credentials (username and password) and can intercept the TOTP codes transmitted by the legitimate user.

Attack Vector Diagram

Exploitation Methodology

1. Credential Harvest: The attacker steals the user's login credentials via phishing, malware, or credential stuffing.

2. TOTP Interception: The attacker intercepts the user's TOTP codes. For example, if the user receives TOTP codes via SMS or email, or if the attacker is in a position to monitor the network interface or local device storage, they can intercept a code from an earlier timestep (e.g., T-1 or T-2) that the user did not use because they had already generated a newer code (timestep T).

3. MFA Replay: The user authenticates with code T. The server accepts the code and writes a cache entry for that specific code. The attacker then authenticates using the intercepted, older code (T-1).

4. Bypass Verification: Since the older code T-1 has never been recorded in the cache, the server evaluates it as a valid, unused code because it falls within the acceptable clock drift window. The server grants the attacker full access to the administrative panel.

The security impact of CVE-2026-84306 is marked by the complete breakdown of multi-factor authentication integrity for affected Filament installations. When bypassed, the primary layer of credential protection is rendered ineffective, allowing attackers with compromised user credentials to elevate their privileges to that of the targeted administrative account.

Since Filament is frequently used as an administrative interface for business databases, customer information systems, and core application configurations, an administrative session compromise typically results in high confidentiality and integrity impacts. An attacker could extract database contents, manipulate system configuration parameters, or perform unauthorized actions on behalf of administrative users.

Despite the severity of a successful bypass, the exploitability of this vulnerability is limited by the strict prerequisites. The attacker must already hold valid primary credentials and have active visibility into the user's TOTP sequence within a tight time window of approximately four minutes. This requirement accounts for the CVSS score of 6.5 and the high-complexity classification.

To eliminate the exposure caused by CVE-2026-84306, administrators and developers must upgrade Filament to a patched release. No manual configuration changes to the codebase are required once the upgrade is completed.

Recommended Software Updates

• For applications utilizing Filament v4.x, update to version 4.12.6 or later.
• For applications utilizing Filament v5.x, update to version 5.7.6 or later.

Run the following commands in the root directory of the application:

# For v4 installations
composer update filament/filament:^4.12.6
 
# For v5 installations
composer update filament/filament:^5.7.6

Supporting Infrastructure Mitigations

To ensure the performance and security of the newly introduced mutex lock mechanism, the application's caching backend must support locking. Cache stores such as file, apc, or database drivers without locking support will fail silently back to non-locking verification, maintaining a small race-condition vulnerability window.

It is strongly advised to deploy a cache backend that supports native distributed locking, such as Redis or Memcached, and ensure that the CACHE_DRIVER environment variable is configured to utilize this backend in production.