Flarum EUVD-2026-53389

Exploitation requires the attacker to possess a valid PasswordToken value for the target account that still exists in the database - typically a reset the victim (or attacker, for their own or another account) previously triggered - and to submit it to the SavePasswordController POST reset endpoint rather than the form. The limiting factor is precisely this token possession: the flaw removes only the time-based expiry check, so an attacker cannot forge tokens and must acquire a real one (via leakage, interception, or a reset they can trigger), which is why the CVSS carries AC:H. No authentication, privileges, or user interaction beyond obtaining the token are needed, and default configurations of pre-1.8.16 Flarum are affected.

This is a genuine high-priority issue for internet-facing Flarum forums, but not a spray-and-pray mass-exploitation candidate. The CVSS 4.0 vector (AV:N/AC:H/PR:N/UI:N, VC:H/VI:H/VA:H) scores 9.2 because a successful bypass yields full account takeover with no authentication or user interaction; the AC:H reflects the real precondition that the attacker must first obtain a valid token value that has not been consumed. No EPSS score, KEV listing, or POC was provided, so exploitation appears theoretical/targeted rather than widespread at this time - consistent with a bug that requires possessing a leaked or intercepted reset token per target. The most dangerous framing is admin/moderator account takeover, which could cascade to forum-wide compromise. Treat as high priority to patch, especially where reset tokens might be exposed (proxy logs, referrer leakage, shared inboxes), while noting that the absence of a public exploit and the need for a token temper the immediacy.

An attacker obtains a password reset token for a target account that has expired but was never consumed - for example a token exposed in proxy logs, a forwarded email, or a shared support mailbox. Instead of using the normal reset form, the attacker POSTs the token and a chosen new password directly to Flarum's reset processing endpoint, which accepts it despite being past the 24-hour window, and then logs in as the victim. No public POC was provided, but the attack requires only standard HTTP tooling once a token is in hand.