Flarum EUVD-2026-53392

The attacker must first acquire a valid session token or API bearer token for the target account through a separate prior compromise - credential theft, phishing, session hijacking, or XSS are all viable precursors. No special non-default Flarum configuration is required beyond the attacker already holding that initial token; any Flarum instance prior to v1.8.16 with the default session management is affected. The 'remember me' feature (which generates long-lived RememberAccessToken entries) extends the window of persistent unauthorized access but is not strictly required for exploitation. Exploitation is limited by the AC:H prerequisite: the initial token acquisition is a hard dependency that reduces the at-scale risk significantly. Victims who attempt recovery by requesting an administrator-forced password reset via the user update endpoint receive no protection, as that code path also fails to clear the access_tokens table.

The CVSS 4.0 vector (AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) accurately characterizes this as a high-impact but conditionally exploitable vulnerability. AC:H is the critical limiting factor: the attacker must first successfully obtain a valid session token through a separate prior compromise event before this vulnerability becomes relevant. This makes it a post-compromise persistence mechanism, not an initial access vector - the attacker has already breached the account, and this flaw prevents the victim from evicting them. No CISA KEV listing is present, no POC has been publicly identified, and no EPSS data was provided, so mass or opportunistic exploitation is not currently confirmed. The real-world risk is concentrated in scenarios of targeted account takeover where the victim's natural recovery action (password change) is expected to terminate attacker access but does not. The high VC and VI scores are justified given that retained session tokens grant full read/write access to the account and its privileges. The absence of an availability impact (VA:N) is consistent with the description - this is an access-retention flaw, not a denial of service.

An attacker who previously obtained a valid Flarum session token through credential stuffing, phishing, or an XSS-based session hijack discovers that the victim has changed their password to recover their account. Because the access_tokens table is never purged on password change, the attacker's stolen RememberAccessToken or API bearer token remains valid, granting continued full access to the account including posting, moderation actions, and private message access. If the compromised account held administrative privileges, the attacker retains those privileges indefinitely until the patch is applied or tokens are manually purged from the database.