phpMyFAQ EUVD-2026-103336

Exploitation requires that the phpMyFAQ instance be configured to use Keycloak or Entra ID (Azure AD) SSO via OIDC AND that the targeted account has TOTP two-factor authentication enabled - the flaw lies in the SSO callbacks failing to enforce the TOTP step. The attacker must possess a valid or phished IdP identity that is already linked to the targeted 2FA-enabled phpMyFAQ account. Limiting factors: deployments not using Keycloak/Entra ID SSO, or not relying on TOTP 2FA, are unaffected; the attacker cannot succeed without first controlling a linked IdP identity (hence the UI:P/phishing element), which bounds this from mass, fully unauthenticated exploitation despite the network vector. Affected versions are 3.2.0-alpha before 4.1.9 and 4.2.0-alpha before 4.2.0-beta; upgrading to 4.1.9 or 4.2.0-beta removes the condition.

This is a genuine authentication-bypass issue (CWE-287) rather than a high-CVSS-but-low-real-risk flaw, though exploitation is gated by a meaningful prerequisite. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N) indicates a network-reachable, low-complexity attack with no app-level privileges required and high confidentiality/integrity impact - consistent with full session takeover, including administrator accounts. However, the description makes clear the attacker must already hold a valid or phished IdP identity that is linked to a 2FA-enabled phpMyFAQ account, so PR:N reflects that the first-factor IdP credential is treated as attacker-supplied input rather than pre-existing phpMyFAQ privilege. The UI:P (passive user interaction) element aligns with phishing to obtain the IdP identity. No EPSS score was provided, the CVE is NOT in CISA KEV, and no public POC is referenced - so there is no public exploit identified at time of analysis and no evidence of active or widespread exploitation. The practical risk is therefore real but conditional: it meaningfully affects only deployments that (a) use Keycloak or Entra ID SSO and (b) rely on phpMyFAQ's TOTP 2FA as a compensating control, since the vulnerability specifically defeats that second factor.

An attacker phishes or otherwise obtains a valid Keycloak or Entra ID identity that is linked to a 2FA-enabled phpMyFAQ account (potentially an administrator). The attacker completes the normal OIDC login flow through the SSO callback, and because the callback does not enforce the TOTP step, they receive a fully authenticated phpMyFAQ session without ever providing the one-time code. No public exploit code is referenced, so this would currently require the attacker to reproduce the callback flaw independently.