Which versions of Flarum are affected by EUVD-2026-53389?

Flarum forum software before version 1.8.16 contains a critical account takeover vulnerability (CVSS 9.2) allowing unauthenticated attackers to reset user passwords via token reuse; no public exploit…. A patch is available.

How to fix or mitigate EUVD-2026-53389?

Within 24 hours, identify all Flarum deployments in your infrastructure and determine current versions; if running versions before 1.8.16, immediately restrict external access to password reset endpoints and review access logs for anomalous password reset or login activity. Within 7 days, apply vendor-released patch by upgrading all affected instances to Flarum 1.8.16 or later. Within 30 days, complete a comprehensive review of account access logs covering the past 90 days to identify any unauthorized account modifications, validate that all administrative accounts remain under proper control, and implement enhanced monitoring on password reset and account modification events.

Flarum EUVD-2026-53389

Q: What is the CVSS score of EUVD-2026-53389?

EUVD-2026-53389 has a CVSS 4.0 base score of 9.2 (Critical). CVSS vector: CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X. EPSS exploitation probability: 0.3%.

| CVE-2026-39923 CRITICAL

Use of a Key Past its Expiration Date (CWE-324)

2026-08-05 VulnCheck

GHSA-3mr9-883x-4f3x

Authentication Bypass Flarum Flarum Framework

9.2

CVSS 4.0 · Vendor: VulnCheck

Severity by source

Vendor (VulnCheck) PRIMARY

9.2 CRITICAL

CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

vuln.today AI

8.1 HIGH

Remote unauthenticated account takeover (PR:N/UI:N) yields full C/I/A over the victim account, but AC:H because the attacker must first obtain a real unconsumed reset token.

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

Primary rating from Vendor (VulnCheck).

CVSS VectorVendor: VulnCheck

Attack Vector

Network

Attack Complexity

High

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Source Code Evidence Fetched

Aug 05, 2026 - 15:45 vuln.today

Analysis Generated

Aug 05, 2026 - 15:45 vuln.today

CVE Published

Aug 05, 2026 - 14:38 cve.org

CRITICAL 9.2

DescriptionCVE.org

Flarum before 1.8.16 contains a password reset token expiry bypass vulnerability that allows unauthenticated attackers to reuse expired password reset tokens by submitting them directly to the reset processing endpoint. The SavePasswordController::handle() method calls PasswordToken::findOrFail() without performing any expiry validation, allowing attackers to bypass the 24-hour token lifetime enforced only during form rendering and change any account's password to gain an authenticated session.

AnalysisAI

Account takeover in Flarum forum software before 1.8.16 lets remote unauthenticated attackers reuse expired password reset tokens by POSTing them directly to the reset endpoint, bypassing the 24-hour token lifetime that is only enforced when the reset form is rendered. Because SavePasswordController::handle() calls PasswordToken::findOrFail() with no expiry check, anyone holding a stale-but-still-existing token can set a new password and log in as that user. Reported by VulnCheck; no public exploit identified at time of analysis, and it is not listed in CISA KEV.

Technical ContextAI

Flarum is a PHP-based open-source forum framework (cpe:2.3:a:flarum:flarum_framework). Its password reset flow issues a PasswordToken record and enforces a 24-hour validity window only in the GET path that renders the reset form. The vulnerable POST path, SavePasswordController::handle(), looks the token up via Eloquent's findOrFail() and proceeds to overwrite the account password without re-validating the token's created_at/expiry. This is the essence of CWE-324 (Use of a Key Past its Expiration Date): a security-relevant credential remains honored after it should have been rejected, because expiry enforcement lives in the presentation layer rather than the state-changing handler. The upstream fix (PR #4545) moves expiry enforcement into the submission handler; companion fixes invalidate active sessions on password change (PR #4546) and delete stale tokens when a new reset is requested (PR #4547).

RemediationAI

Vendor-released patch: upgrade to Flarum 1.8.16 (https://github.com/flarum/framework/releases/tag/v1.8.16), which enforces the expiry check on token submission (PR #4545), invalidates active sessions when a password changes (PR #4546), and deletes stale password tokens when a new reset is requested (PR #4547). If you cannot upgrade immediately, reduce exposure by shortening or clearing outstanding password_tokens rows (e.g., purge tokens older than 24 hours from the database on a schedule) so no reusable expired token exists - the trade-off is that legitimately pending resets within the window may also be invalidated. Additionally, minimize token leakage by ensuring reset links are delivered over TLS, stripped from referrer headers, and not logged by reverse proxies. These are stopgaps; applying 1.8.16 is the definitive fix.