CVE-2026-56737: phpMyFAQ Authentication Bypass Vulnerability

CVE-2026-56737 Overview

CVE-2026-56737 is an authentication bypass vulnerability [CWE-287] in phpMyFAQ, an open source FAQ web application. Versions 3.2.0 through 4.1.5 contain a flaw in the public two-factor authentication (2FA) verification flow. An unauthenticated attacker can submit a numeric user ID along with a valid or brute-forced six-digit Time-based One-Time Password (TOTP) code without first supplying the account password. The flaw allows takeover of any 2FA-enabled account, including administrator accounts. Version 4.1.6 remediates the issue by binding TOTP verification to a session established after successful password authentication and by rate-limiting failed TOTP attempts.

Critical Impact
Unauthenticated remote attackers can bypass password authentication and take over any 2FA-enabled phpMyFAQ account, including administrator accounts, by brute-forcing a six-digit TOTP code.

Affected Products

phpMyFAQ versions 3.2.0 through 4.1.5
phpMyFAQ installations with two-factor authentication enabled on any account
Fixed in phpMyFAQ 4.1.6

Discovery Timeline

2026-09-24 - CVE-2026-56737 published to the National Vulnerability Database (NVD)
2026-09-29 - Last updated in NVD database

Technical Details for CVE-2026-56737

Vulnerability Analysis

The vulnerability resides in the frontend 2FA token verification handler within phpmyfaq/index.php. The handler accepts a user ID and a six-digit TOTP token from unauthenticated HTTP requests. It then calls TwoFactor::validateToken() without verifying that the request originated from a session that had already completed password authentication. Because user IDs are predictable numeric identifiers, an attacker can enumerate accounts and attempt TOTP codes directly against the token endpoint. The 2FA step was treated as a standalone authentication factor rather than the second step of a chained flow.

Root Cause

The root cause is a missing authentication state check between the password step and the TOTP step. The vulnerable code validated only the format of the token (strlen($token) === 6 and is_numeric($token)) and the existence of the user ID. No server-side session binding tied the TOTP submission to a prior successful password check. In addition, no counter restricted the number of failed token attempts, making brute force of the 10^6 TOTP keyspace practical during a single valid 30-second window across many parallel requests.

Attack Vector

An unauthenticated attacker sends a crafted HTTP request to the token verification endpoint with a target user-id parameter and a candidate six-digit token value. Repeated submissions brute-force the TOTP code without triggering lockout. A successful match authenticates the attacker as the targeted user, including administrators.

php

// Patch excerpt from phpmyfaq/index.php — binds the 2FA step to a prior password check
-if ($token !== '' && !is_null($userId)) {
-    if (strlen((string) $token) === 6 && is_numeric((string) $token)) {
+if ($token !== '' && $userId > 0) {
+    $session = $container->get('session');
+    $pendingUserId = $session->get('2fa_pending_user_id');
+
+    // The 2FA token step must follow a successful password authentication that
+    // is bound to this exact user-id. Without that pending state an attacker
+    // could log in using only a (brute-forceable) token, bypassing the password.
+    if ($pendingUserId === null || (int) $pendingUserId !== $userId) {
+        $error = Translation::get(key: 'msgTwofactorErrorToken');
+        $action = 'login';
+    } elseif ($session->get('2fa_failed_attempts', 0) >= 5) {
+        $session->remove('2fa_pending_user_id');
+        $session->remove('2fa_failed_attempts');
+        $error = Translation::get(key: 'msgTwofactorErrorToken');
+        $action = 'login';
+    } elseif (strlen((string) $token) === 6 && is_numeric((string) $token)) {
         $user = new CurrentUser($faqConfig);
         $user->getUserById($userId);
         $tfa = new TwoFactor($faqConfig, $user);
         $res = $tfa->validateToken($token, $userId);
         if (!$res) {
+            $session->set('2fa_failed_attempts', $session->get('2fa_failed_attempts', 0) + 1);
             $error = Translation::get(key: 'msgTwofactorErrorToken');
             $action = 'twofactor';

Source: GitHub Commit 410208b

Detection Methods for CVE-2026-56737

Indicators of Compromise

High volumes of POST requests to the phpMyFAQ 2FA token endpoint (for example /index.php?action=twofactor or /token?user-id=) from a single source IP.
Repeated token submissions for the same user-id parameter with sequential or randomized six-digit values.
Successful administrator sessions originating from IP addresses that never submitted a login form.
New or modified FAQ content, user accounts, or configuration changes performed by administrator accounts outside of normal hours.

Detection Strategies

Review web server access logs for requests to the token verification endpoint that are not preceded by a login POST from the same session identifier.
Alert on more than five failed 2FA submissions per user-id per minute on unpatched installations.
Correlate authentication events to identify sessions that reach the 2FA step without a prior password form submission.

Monitoring Recommendations

Enable verbose authentication logging in phpMyFAQ and forward logs to a centralized SIEM for correlation.
Monitor administrator account logins and flag any that occur without a corresponding password authentication event.
Track outbound HTTP activity from the phpMyFAQ host for signs of post-exploitation such as webshell callbacks.

How to Mitigate CVE-2026-56737

Immediate Actions Required

Upgrade all phpMyFAQ installations to version 4.1.6 or later without delay.
Audit administrator and user accounts for unauthorized logins, password resets, or configuration changes.
Rotate TOTP secrets for all 2FA-enabled accounts after upgrading, since valid codes may have been observed by attackers.
Restrict network exposure of the phpMyFAQ admin interface to trusted IP ranges where feasible.

Patch Information

The fix is delivered in phpMyFAQ 4.1.6. The core change binds the 2FA token step to a pending session established only after successful password authentication and enforces a maximum of five failed TOTP attempts per session. See GitHub Security Advisory GHSA-8gpw-xvpf-hvx5, commit 410208b, commit 6a69f6e, and commit 5097dff for implementation detail. The patch also adds the robthree/twofactorauth library at version 1.8.2 as a hardened TOTP dependency.

Workarounds

No official workaround is documented by the vendor; upgrading to 4.1.6 or later is the only supported remediation.
As a temporary compensating control, restrict access to the phpMyFAQ token verification endpoint using a reverse proxy or Web Application Firewall (WAF) rule that enforces rate limiting per source IP.
Consider temporarily disabling 2FA on exposed accounts until patching completes, since the vulnerable flow is reachable only when 2FA is enabled.

bash

# Example NGINX rate limit to blunt TOTP brute force on the token endpoint
limit_req_zone $binary_remote_addr zone=pmf_2fa:10m rate=5r/m;

location ~ ^/(index\.php|token) {
    limit_req zone=pmf_2fa burst=5 nodelay;
    proxy_pass http://phpmyfaq_upstream;
}