Question2Answer EUVD-2026-47782

Exploitation requires the attacker to already hold a valid persistent 'Remember me' (qa_session) cookie issued BEFORE the password reset occurs - this cookie must have been obtained through a separate means (theft, XSS, device access). The specific trigger is the victim completing the forgot-password reset flow (qa_finish_reset_user), which fails to clear the sessioncode field. Limiting factors: the attack only works on accounts where persistent login was enabled and a cookie was captured pre-reset; it does not grant fresh initial access and cannot be launched with no prior foothold. It is effective specifically against Question2Answer <= 1.8.8 where the forgot-password path omits sessioncode invalidation.

The vendor CVSS 4.0 score is 9.1 (AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:N), but that headline number overstates real-world priority for most defenders. The high score comes from network vector and high confidentiality/integrity impact, yet AC:H correctly reflects a hard prerequisite: the attacker must ALREADY possess a valid persistent cookie stolen before the reset. This is a post-compromise persistence/lockout-evasion weakness, not an initial-access flaw - a victim resetting a password specifically to evict an attacker will fail to do so. No EPSS score, KEV listing, or SSVC decision data was provided, and no public POC is indicated, so widespread opportunistic exploitation is unlikely. Note a taxonomy discrepancy: the VulnCheck advisory title calls this 'session fixation,' while the description and CWE-613 describe insufficient session expiration/invalidation - the latter is the accurate characterization and should guide remediation reasoning.

An attacker who earlier obtained a victim's persistent qa_session cookie (e.g., via XSS, cookie theft, or a shared/compromised device) retains a copy. The victim, suspecting compromise, uses the forgot-password flow to reset their password - but because sessioncode is never cleared, the attacker's old cookie still authenticates them to the account. No public POC is identified, but the exploitation logic is trivial once a valid pre-reset cookie is held.