phpMyFAQ EUVD-2026-103333

Exploitation requires the attacker to already possess a hijacked authenticated session for the target user AND a valid matching CSRF token; with those, they POST unlimited TOTP guesses to the /api/user/remove-twofactor endpoint because removeTwofactorConfig() enforces no brute-force lockout. Limiting factors: this is a chained/second-stage attack dependent on prior session compromise (so not truly unauthenticated despite the published PR:N), it only affects versions 4.2.0-alpha.2 up to 4.2.0-beta, it requires the 2FA-removal feature/endpoint to be reachable, and success still depends on brute-forcing the TOTP space. Impact is limited to disabling the victim's 2FA, not direct data compromise.

This is a moderate-severity authentication-weakness issue (CWE-307, missing rate-limiting) rather than a direct code-execution or data-exfiltration flaw. The vendor/VulnCheck CVSS 4.0 vector (AV:N/AC:L/PR:N/UI:P, VI:H only) scores 7.1, but the published vector materially conflicts with the description: it marks PR:N (unauthenticated), yet the description states exploitation requires 'a hijacked session and CSRF token' and targets 'authenticated attackers' - meaning the attacker must already have stolen a valid victim session plus a matching CSRF token before brute-forcing TOTP codes. That precondition is a substantial real-world limiter not reflected by AC:L/PR:N, so the practical risk is lower than the 7.1 suggests. There is no EPSS score, no CISA KEV listing, and no public exploit code in the provided data, so exploitation status is 'no public exploit identified at time of analysis.' Impact is confined to integrity of the account's security posture (permanently disabling the victim's 2FA), with no confidentiality or availability impact. Net: a legitimate hardening gap worth patching, but it is a second-stage/chained issue dependent on prior session compromise, not a standalone network-exploitable priority.

An attacker who has already hijacked a logged-in phpMyFAQ user's session and obtained a valid CSRF token repeatedly POSTs TOTP guesses to /api/user/remove-twofactor. Because the removeTwofactorConfig() endpoint enforces no lockout or rate limit, the attacker can brute-force the 6-digit code until it matches and permanently disables the victim's 2FA, weakening the account for future takeover. No public proof-of-concept is identified in the provided data.