Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-01T19:17:31.023Z",
  "pubdate": "2026-09-01T19:17:31.023Z",
  "executiveSummary": "A flaw in Filament's AppAuthentication component allows for the reuse of Time-based One-Time Password (TOTP) codes within the valid time window.\nThe vulnerability resides in the cache key generation logic within packages/panels/src/Auth/MultiFactor/App/AppAuthentication.php, which incorrectly isolates the used-code cache by the specific TOTP code rather than the user's secret.\nThis logic error enables an attacker who has intercepted a single valid MFA code and the user's password to replay that code for the duration of the time window, even after the legitimate user has successfully authenticated with a subsequent, newer code.\nThis significantly expands the window of opportunity for unauthorized account access. The issue affects Filament versions 4.0.0 through 4.12.5 and 5.0.0 through 5.7.5. Email-based MFA implementations remain unaffected by this flaw.\nSuccessful exploitation requires the attacker to possess both the target account credentials and a previously captured TOTP code.",
  "technicalDetails": "The root cause of this vulnerability is improper cache key generation in the AppAuthentication::verifyCode() function located in packages/panels/src/Auth/MultiFactor/App/AppAuthentication.php. The implementation generates a cache key derived from the app authentication secret combined with the submitted TOTP code itself.\nUnder normal TOTP security standards, an application must track used codes globally per secret for the duration of the valid time window (typically 30 seconds, plus a drift margin) to prevent replay attacks. By including the TOTP code in the cache key, the system only prevents the reuse of the exact same string until it expires, rather than preventing any code from being used after a newer, valid code has already been processed for that specific secret.\nThe attack flow proceeds as follows: An attacker acquires the target user's password and a single valid TOTP code via interception or social engineering. The attacker attempts to log in using these credentials. Even if the legitimate user logs in later with a new, different TOTP code, the attacker's captured code remains valid within the configured grace period (approximately four minutes). Because the system's cache key does not invalidate all previous codes upon the successful usage of any new, valid code for that secret, the attacker’s replay attempt succeeds.\nThe vulnerable component is explicitly the app-based MFA verification logic. The lack of proper synchronization between the secret-level state and the code-level state allows the server to perceive the attacker's replayed code as distinct from the legitimate user's sequence, provided the attacker's code has not reached its specific expiry threshold. Consequently, the system fails to enforce strict chronological or sequential enforcement for TOTP validation. This defect exists in Filament versions 4.0.0 up to 4.12.6 and 5.7.6. The exploitation is strictly limited to app-based TOTP flows, as email-based authentication mechanisms do not utilize this specific validation logic."
}