PatchSiren

PatchSiren cyber security CVE debrief

CVE-2026-84306 filamentphp CVE debrief

The Filament app-based MFA system incorrectly isolates accepted timesteps 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 within the configured time window. This issue arises from the use of AppAuthentication::verifyCode() with a used-code cache key derived from both the app authentication secret and the submitted TOTP code. An attacker with the target account's password and one app-based MFA code can use that code for the remainder of the configured window, approximately four minutes with default settings, even after the legitimate account holder logs in with a newer code. Email-based MFA is not affected. The vulnerability has been fixed in versions 4.12.6 and 5.7.6. To verify, defenders should review the installed filament versions, apply vendor patches, and monitor for suspicious login attempts.

Vendor
filamentphp
Product
filament
CVSS
MEDIUM 6.5
CISA KEV
Not listed in stored evidence
Original CVE published
2026-09-01
Original CVE updated
2026-09-04
Advisory published
2026-09-01
Advisory updated
2026-09-04

Who should care

Developers and administrators using Filament versions between 4.0.0 and 4.12.6 or 5.7.6 and earlier, especially those relying on app-based MFA for security, should be aware of this vulnerability and take necessary actions to protect their systems. This includes reviewing and applying vendor patches, monitoring for suspicious login attempts, and considering additional security measures for multi-factor authentication. Email-based MFA is not affected by this vulnerability. System administrators should verify the integrity of their systems and user accounts, and implement compensating controls if patches cannot be applied immediately. Security teams should also review system logs for potential exploitation attempts. Filament users should prioritize patching to versions 4.12.6 or 5.7.6 to mitigate this vulnerability. Additionally, users should consider implementing additional security measures such as IP restrictions, user agent verification, or behavioral analysis to detect and prevent potential attacks. Regular security audits and penetration testing can also help identify and address potential vulnerabilities. By taking these steps, organizations can reduce the risk of exploitation and protect their systems from potential attacks. It is also recommended to track exceptions, retest remediated assets, and close the item only after evidence is documented. This vulnerability highlights the importance of multi-factor authentication and the need for secure implementation and configuration. By being aware of this vulnerability and taking necessary actions, developers and administrators can help protect their systems and prevent potential attacks. To further mitigate this vulnerability, organizations should consider implementing a defense-in-depth approach, including multiple layers of security controls, to detect and prevent potential attacks. This can include network segmentation, intrusion detection and prevention systems, and incident response planning. By prioritizing patching, implementing additional security measures, and maintaining a robust security posture, organizations can reduce the risk of exploitation and protect their systems from potential attacks. Filam

Technical summary

The Filament app-based MFA system incorrectly isolates accepted timesteps 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 within the configured time window. This issue arises from the use of AppAuthentication::verifyCode() with a used-code cache key derived from both the app authentication secret and the submitted TOTP code. The vulnerability has been fixed in versions 4.12.6 and 5.7.6.

Defensive priority

Medium priority due to the required combination of password and MFA code for exploitation.

Recommended defensive actions

  • Inventory and verify installed filament versions.
  • Apply vendor patches in versions 4.12.6 and 5.7.6.
  • Monitor for suspicious login attempts.
  • Consider implementing additional security measures for multi-factor authentication.
  • Review system logs for potential exploitation attempts.
  • Implement compensating controls if patches cannot be applied immediately.
  • Track exceptions, retest remediated assets, and close the item only after evidence is documented.

Evidence notes

The issue is caused by the use of AppAuthentication::verifyCode() with a used-code cache key derived from both the app authentication secret and the submitted TOTP code, isolating the newest accepted timestep by code instead of by secret. This allows an attacker who obtains the target account's password and one app-based MFA code to use that code for the remainder of the configured window, approximately four minutes with default settings, even after the legitimate account holder logs in with a newer code. Email-based MFA is not affected. The vulnerability has been fixed in versions 4.12.6 and 5.7.6. To verify, defenders should review the installed filament versions, apply vendor patches, and monitor for suspicious login attempts.

Sources and references

Verified primary and authoritative sources

  • CVE-2026-84306 CVE Program record

    Publisher, destination, and source semantics verified

    URL: https://www.cve.org/CVERecord?id=CVE-2026-84306

    CVE Program - Official CVE Program record with source-provided CVE metadata.

  • CVE-2026-84306 NVD vulnerability detail

    Publisher, destination, and source semantics verified

    URL: https://nvd.nist.gov/vuln/detail/CVE-2026-84306

    NIST National Vulnerability Database - Official NIST NVD detail page and source-specific vulnerability assessment.

Supplemental references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.