phpMyFAQ EUVD-2026-103335

Requires an already-authenticated, hijacked user session in phpMyFAQ - the attacker must possess a valid session cookie and the matching CSRF token, since those are the only checks the api/user/data/update endpoint performs. No current account password is needed to change the email, which is the core flaw. Full takeover additionally requires that the targeted account (e.g., superadmin) does NOT have two-factor authentication enabled; 2FA-protected accounts resist the password-reset pivot. The need for a pre-existing valid session (PR:L) is the primary limiting factor that prevents fully unauthenticated, opportunistic exploitation.

This is a credible, actionable priority rather than a high-CVSS-but-low-risk issue, though the real-world footprint is modest. The provided CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:L) scores 8.7 (High) and, critically, requires PR:L - the attacker must already hold a low-privileged authenticated session, consistent with the description's premise of a 'hijacked session.' CWE-308 (missing step-up / single-factor authentication) is accurately matched: the account-email change omits a current-password re-authentication check, enabling a password-reset pivot to full account takeover including superadmin. On the exploitation-signal side there is NO active-exploitation or exploit-availability data: no CISA KEV listing, no POC reference, and no EPSS score were supplied, so the status is 'no public exploit identified at time of analysis.' The signals are therefore consistent rather than conflicting - a vendor/VulnCheck-confirmed logic flaw with high technical impact but no evidence of weaponization. The main limiting factor is the session-hijack precondition (PR:L): an attacker needs an existing authenticated session, which meaningfully constrains opportunistic mass exploitation. Note the impact caveat: full account takeover arguably warrants a higher availability/integrity impact than the input's VA:L suggests - verify impact scoring against the GHSA advisory.

An attacker who has obtained a valid user session (e.g., via XSS, stolen cookie, or shared/kiosk machine) calls api/user/data/update to change the victim account's email to an attacker-controlled mailbox, since no current-password confirmation is enforced. They then trigger the standard password-reset flow, receive the reset link at their own inbox, and seize the account - escalating to superadmin if that account lacks 2FA. No public exploit code is identified at time of analysis, but the flaw is a simple API call requiring low attack complexity (AC:L).