phpMyFAQ CVE-2026-76213

Exploitation requires the attacker to already know a valid first-factor password for a phpMyFAQ account that has TOTP two-factor authentication enabled, and the target must be running a version before 4.1.7. The specific enabling condition is the session-scoped failure counter on the 2FA step that resets on each successful password re-authentication, allowing the five-attempt limit to be bypassed by obtaining a fresh session cookie and re-authenticating. Limiting factors: the attack is probabilistic (AC:H/AT:P - many requests needed to guess the 6-digit TOTP within its time window), it is useless without valid credentials, and it only applies to accounts protected by phpMyFAQ's TOTP 2FA; accounts without 2FA are unaffected by this specific flaw.

The CVSS 4.0 vector (AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:N, base 9.1) captures high confidentiality and integrity impact reachable over the network, while AC:H and AT:P correctly reflect that success is probabilistic and requires repeated attempts rather than a single deterministic request. The most important caveat is that the vector encodes PR:N (unauthenticated), yet the description explicitly states the attacker must already possess a valid password - so this is realistically a privileged/credentialed attack against the SECOND factor, not a fully anonymous one; treat PR:N as understating the precondition. There is no EPSS score, no KEV listing, and no known public POC, so no public exploit identified at time of analysis and no evidence of active exploitation. Net: a genuinely serious weakness that undermines 2FA-as-compensating-control, but its real-world priority is gated by the attacker first obtaining valid credentials (via phishing, reuse, or prior breach), making it a strong escalation/second-stage risk rather than a mass-exploitable internet-wide threat.

An attacker who has phished or reused a valid phpMyFAQ user's password reaches the TOTP prompt, submits five wrong codes, then discards the session, requests a fresh session cookie, re-submits the same valid password, and receives five more guesses. Scripting this loop over the network lets the attacker cycle through TOTP values until one is accepted, completing login and taking over the account. No public POC is known, but the technique is straightforward to automate given the described behavior.