phpMyFAQ CVE-2026-56737

Exploitation requires the target phpMyFAQ account (e.g. an administrator) to have TOTP two-factor authentication enabled; the flaw is in the PUBLIC 2FA verification flow of index.php. The attacker must supply the account's numeric user ID (guessable/enumerable) plus a valid or brute-forced six-digit TOTP code, and submit it WITHOUT first passing password authentication. What makes this practical pre-patch is the total absence of a failed-attempt limit and the lack of any requirement for a prior password-authenticated pending session (2fa_pending_user_id), which the 4.1.6 patch introduces along with a 5-attempt cap. The main limiting factor is the TOTP brute-force cost within the code's rolling validity window (hence AC:H) and the requirement that the target account actually uses 2FA; no user interaction and no attacker authentication are needed.

This is a genuine high-priority vulnerability for anyone running phpMyFAQ 3.2.0-4.1.5 with 2FA enabled. The CVSS vector (AV:N/AC:H/PR:N/UI:N/C:H/I:H/A:H, base 8.1) describes an unauthenticated, network-reachable account-takeover flaw with full confidentiality/integrity/availability impact, which is corroborated by the description (takeover of any 2FA-enabled account including administrators) and by the source-code evidence in the patch commits. The AC:H rating is well-justified: the pre-patch flow required a valid OR brute-forced six-digit TOTP, and although the numeric user ID is easy to guess, the TOTP space (10^6) is what raises attack complexity - critically, the pre-patch code had NO failed-attempt limiting (the patch adds a 5-attempt cap), so offline-style rapid brute force of the 30-second-window TOTP was feasible against a valid or currently-authenticating window. No EPSS score, no CISA KEV listing, and no public POC were provided, so this is not confirmed as actively exploited; however, the fix commits are public and clearly reveal the vulnerable logic (submitting userId + token without a password-authenticated pending session), which lowers the bar for exploit development. Signals are consistent rather than conflicting: high CVSS, a clear root cause, and a vendor advisory (GHSA-8gpw-xvpf-hvx5), tempered only by the AC:H brute-force requirement and the dependence on the target having 2FA enabled. Treat as a priority patch where 2FA is in use; where 2FA is not enabled on any account, exposure is effectively nil.

An unauthenticated attacker targets a phpMyFAQ instance where an administrator has enabled TOTP 2FA. The attacker submits the admin's numeric user ID together with a six-digit token directly to the public 2FA verification endpoint - skipping the password step entirely - and, because pre-patch code did not bind verification to a password-authenticated session or limit failed attempts, brute-forces or replays a valid TOTP to gain full control of the admin account. No public POC was identified, but the patch commits publicly disclose the vulnerable code path.